النسخ الاحتياطي السحابي وقاعدة 3-2-1: دليل عملي

لماذا تفشل النسخ الاحتياطية (وكيف تصلحها قاعدة 3-2-1)

معظم حوادث فقدان البيانات لا تنتج عن أعطال نادرة، بل عن الأمور الاعتيادية: أمر rm -rf في المجلد الخطأ، أو قاعدة بيانات تالفة بعد انقطاع التيار، أو برمجية فدية تشفّر كل ما تصل إليه، أو قرص واحد يتعطّل بصمت. القاسم المشترك أن «النسخة الاحتياطية» إما لم تكن موجودة أصلاً، أو كانت مخزّنة على الجهاز نفسه، أو لم يُجرَّب استرجاعها قط.

قاعدة 3-2-1 هي الإجابة المعيارية في القطاع، وهي بسيطة عن قصد:

• 3 نسخ من بياناتك (النسخة الحيّة بالإضافة إلى نسختين احتياطيتين)
• 2 نوعان مختلفان من وسائط أو تقنيات التخزين
• 1 نسخة واحدة محفوظة خارج الموقع

إذا التزمت بها بصدق، فلن يستطيع أي عطل منفرد — سواء كان عتاداً أو خطأً بشرياً أو برمجية خبيثة — أن يقضي على النسخ الثلاث دفعة واحدة. يوضّح هذا الدليل كيفية تطبيق قاعدة 3-2-1 على خوادم لينكس حقيقية باستخدام اللقطات (snapshots) والتخزين الكائني وأداة restic، مع التركيز على إبقاء نسختك الخارجية داخل المملكة العربية السعودية امتثالاً لمتطلبات إقامة البيانات في نظام حماية البيانات الشخصية (PDPL).

ربط قاعدة 3-2-1 ببنية تحتية واقعية

إليك توزيعاً ملموساً لتطبيق ويب نموذجي أو نظام بريد إلكتروني للأعمال:

هذا يحقق الأرقام الثلاثة جميعها: ثلاث نسخ، وتقنيتان متمايزتان (لقطة كتلية مقابل تخزين كائني)، ونسخة واحدة خارج الموقع. والأهم أن النسخة الخارجية تعيش في نظام تخزين مختلف، فلا يمكن لعطل في طبقة التخزين الكتلي للإنتاج أن يفسدها.

الخطوة 1: اللقطات — سريعة لكنها غير كافية

تلتقط اللقطة كامل وحدة تخزين الخادم في لحظة زمنية محددة، وهي أسرع وسيلة للتعافي من نشر فاشل أو ترقية متعثّرة لأنك تستطيع إرجاع الجهاز بالكامل خلال دقائق.

على خادم سحابي أو VPS من سكايلاين، يمكنك أخذ لقطة يدوية من لوحة التحكم قبل أي تغيير محفوف بالمخاطر، وجدولة لقطات تلقائية. لكن التحذير المهم: اللقطة المخزّنة لدى المزوّد نفسه هي النسخة رقم 2، وليست نسختك الخارجية. فهي تحميك من أخطائك، لا من حادثة على مستوى الحساب أو المنطقة. لا تعتمد على اللقطات بوصفها نسختك الاحتياطية الوحيدة.

الخطوة 2: نسخ قواعد البيانات المتسقة على مستوى التطبيق

اللقطات متسقة عند الأعطال (crash-consistent) لكنها ليست بالضرورة متسقة على مستوى التطبيق. بالنسبة لقواعد البيانات، خذ نسخة منطقية صحيحة كي تتمكن من استرجاع جدول واحد دون إرجاع الخادم بأكمله.

لـ MySQL/MariaDB:

mysqldump --single-transaction --quick --routines --triggers \
  --all-databases | gzip > /var/backups/db-$(date +%F).sql.gz

لـ PostgreSQL:

pg_dumpall -U postgres | gzip > /var/backups/pg-$(date +%F).sql.gz

يمنحك الخيار --single-transaction لقطة متسقة من جداول InnoDB دون قفل عمليات الكتابة. اكتب هذه النسخ في مجلد ستلتقطه مهمة النسخ الاحتياطي الخارجية.

الخطوة 3: النسخة الخارجية باستخدام restic والتخزين الكائني

هذه هي النسخة التي تجعل الاستراتيجية حقيقية. restic أداة نسخ احتياطي مفتوحة المصدر ممتازة: تزيل التكرار، وتضغط، وتشفّر من جهة العميل قبل أن يغادر أي شيء خادمك. هذه النقطة الأخيرة مهمة — تُشفَّر بياناتك قبل أن تلمس الشبكة، فلا يرى مزوّد التخزين النص الصريح أبداً.

ثبّت الأداة وهيّئ المستودع مقابل حاوية تخزين كائني متوافقة مع S3:

# تثبيت restic (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y restic

# توجيه restic إلى حاوية التخزين الكائني داخل المملكة
export RESTIC_REPOSITORY="s3:https://objects.example-region.com/my-backup-bucket"
export AWS_ACCESS_KEY_ID="<مفتاح-الوصول>"
export AWS_SECRET_ACCESS_KEY="<المفتاح-السري>"
export RESTIC_PASSWORD="<عبارة-مرور-عشوائية-طويلة>"

# تهيئة المستودع مرة واحدة
restic init

الآن نفّذ أول نسخة احتياطية، شاملةً نسخ قاعدة البيانات وجذر الويب:

restic backup /var/www /etc /var/backups

يرفع restic الكتل المتغيّرة فقط بعد التشغيل الأول، فتصبح النسخ اللاحقة سريعة وقليلة التكلفة.

الأتمتة والتقليم

أضف مهمة cron يومية وسياسة احتفاظ كي لا ينمو المستودع إلى ما لا نهاية:

# /etc/cron.d/restic-backup
30 2 * * * root /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
# /usr/local/bin/restic-backup.sh
set -euo pipefail
source /root/.restic-env   # يصدّر المتغيرات أعلاه

restic backup /var/www /etc /var/backups --tag daily
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

يحتفظ هذا بـ 7 نقاط استرجاع يومية، و4 أسبوعية، و6 شهرية — قيمة افتراضية معقولة توازن بين التغطية وتكلفة التخزين الكائني.

الخطوة 4: التحصين ضد برمجيات الفدية

النسخة الاحتياطية التي يستطيع المهاجم حذفها ليست نسخة احتياطية. تستهدف برمجيات الفدية مستودعات النسخ الاحتياطي بشكل متزايد. هناك خطّان عمليان للدفاع:

• بيانات اعتماد منفصلة: يُفضَّل أن يكون مفتاح التخزين الكائني الذي يستخدمه الخادم للإضافة/الكتابة فقط، دون صلاحية الحذف. نفّذ restic prune من سياق منفصل وأكثر موثوقية.
• عدم القابلية للتعديل / قفل الكائنات: فعّل الاحتفاظ بنمط الكتابة مرة والقراءة عدة مرات (WORM) على الحاوية حيثما توفّر، كي لا يمكن استبدال النسخ أو حذفها قبل مدة محددة.

بهذا تتحول نسختك الخارجية إلى خط دفاع أخير حقيقي.

الخطوة 5: اختبار الاسترجاع — الخطوة التي يتخطّاها الجميع

النسخة الاحتياطية غير المُختبَرة أمنية لا خطة. جدول تمريناً دورياً للاسترجاع:

# عرض اللقطات المتاحة
restic snapshots

# استرجاع لقطة محددة إلى مجلد مؤقت
restic restore <snapshot-id> --target /tmp/restore-test

# التحقق من سلامة المستودع
restic check

تأكد من أن قاعدة البيانات المستعادة تُستورد فعلاً وأن التطبيق يبدأ التشغيل. ضع تذكيراً شهرياً للقيام بذلك. لا ينبغي أبداً أن تكون المرة الأولى التي تكتشف فيها تعذّر استرجاع نسخة احتياطية هي أثناء انقطاع حقيقي.

لماذا تهم الإقامة داخل المملكة

إذا كنت تعالج بيانات شخصية لأفراد في المملكة العربية السعودية، فإن نظام حماية البيانات الشخصية وإرشادات الهيئة الوطنية للأمن السيبراني تدفعك نحو إبقاء البيانات — بما فيها النسخ الاحتياطية — داخل المملكة ما لم يكن لديك أساس نظامي للنقل. نسختك الخارجية لا تزال بيانات شخصية. استضافتها على سكايلاين كلاود تمنحك إقامة البيانات داخل المملكة، وتخزيناً كائنياً متوافقاً مع S3 لأداة restic، ودعماً باللغة العربية حين تكون في خضمّ حادثة وتحتاج إلى إجابات سريعة.

ابدأ الآن

يمكنك إقامة منظومة 3-2-1 كاملة — خادم سحابي ولقطات وحاوية تخزين كائني داخل المملكة — خلال دقائق. أنشئ حساب سكايلاين كلاود وابنِ استراتيجية نسخ احتياطي يمكنك الاعتماد عليها فعلاً.