استراتيجية النسخ الاحتياطي 3-2-1 لحسابات الاستضافة

قاعدة 3-2-1 تعني أن تحتفظ بثلاث نسخ من بياناتك، على نوعين مختلفين من التخزين، وأن تكون نسخة واحدة منها على الأقل خارج الخادم وخارج مركز البيانات. في حساب الاستضافة يعني ذلك: البيانات الحية على الخادم، ونسخة احتياطية محلية أو على خادم نسخ مستقل، ونسخة مشفرة في تخزين متوافق مع S3 لدى مزود آخر. لكن القاعدة وحدها لا تكفي؛ النسخة التي لم تُختبر استعادتها افتراض لا ضمان.

ماذا تعني الأرقام 3 و2 و1 عمليًا؟

• 3 نسخ: النسخة الأصلية ونسختان احتياطيتان. نسخة احتياطية واحدة تعني أن فشلها يتزامن غالبًا مع حاجتك إليها.
• 2 وسيطان: لا تضع النسختين على القرص نفسه أو المصفوفة نفسها. قرص منفصل أو خادم نسخ أو تخزين كائنات، المهم ألا يُسقطهما عطل واحد.
• 1 خارج الموقع: نسخة في مركز بيانات آخر، ويفضَّل لدى مزود آخر وبحساب مختلف. حريق أو تعليق حساب أو اختراق لوحة المزود لا يجب أن يصل إليها.

ماذا تنسخ في حساب الاستضافة؟

الخطأ الشائع أن تُنسخ الملفات وقواعد البيانات فقط، ثم يُكتشف عند الاستعادة أن البريد وإعدادات DNS ضاعت. القائمة الكاملة لحساب استضافة:

النسخة الكاملة للحساب في cPanel، عبر معالج النسخ الاحتياطي، تجمع أغلب هذه العناصر في أرشيف واحد. لكن إن كنت تبني نسختك بأدوات مثل rsync وmysqldump فاكتب قائمة صريحة وراجعها. وقبل أي نقل خذ نسخة كاملة واختبرها، كما نشرح في الاستعداد للنقل من cPanel دون توقف.

نسخة كاملة أم تزايدية؟

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

القاعدة العملية: نسخة كاملة دورية، أسبوعية مثلًا، وتزايدية يومية بينها. أدوات مثل restic تحل جزءًا من المشكلة بإزالة التكرار (deduplication)، فكل لقطة تبدو كاملة عند الاستعادة وإن خُزّنت الأجزاء المتغيرة فقط. ومع rsync يمكن استخدام --link-dest لصنع لقطات بروابط صلبة للملفات غير المتغيرة.

كيف تأخذ نسخة متسقة من قاعدة البيانات؟

نسخ ملفات MySQL من القرص بينما الخادم يعمل يعطيك غالبًا نسخة تالفة. صدّر قاعدة البيانات بأداة تفهم المعاملات. مع جداول InnoDB يأخذ الخيار --single-transaction لقطة متسقة دون قفل الجداول:

set -o pipefail
mysqldump --single-transaction --quick --routines --triggers --events \
  example_db | gzip > /backup/db/example_db-$(date +%F).sql.gz

set -o pipefail يجعل فشل mysqldump يظهر في حالة الخروج بدل أن يخفيه نجاح gzip. انتبه إلى أن --single-transaction لا يضمن الاتساق لجداول MyISAM؛ حوّلها إلى InnoDB أو اقبل قفل الجداول أثناء التصدير. وللقواعد الكبيرة تصبح أدوات النسخ الفيزيائي الساخن، مثل mariabackup، أنسب من التصدير النصي. التفاصيل في توثيق mysqldump الرسمي.

كيف ترسل النسخة خارج الخادم إلى تخزين متوافق مع S3؟

التخزين المتوافق مع S3 متاح لدى مزودين كثيرين، ومنهم من يملك مناطق في الخليج. أداة مثل rclone أو restic ترفع إليه مباشرة:

export RESTIC_REPOSITORY="s3:https://s3.example-provider.com/acme-backups/server01"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic backup /home/example /backup/db --tag daily

قاعدتان أمنيتان هنا:

1. صلاحيات الرفع فقط: المفاتيح على الخادم تسمح بالكتابة لا بالحذف. إذا اختُرق الخادم لا يستطيع المهاجم مسح النسخ بالمفاتيح نفسها. نفّذ الحذف وفق سياسة الاحتفاظ من جهاز آخر أو عبر قواعد دورة الحياة (lifecycle) في الـ bucket (حيز التخزين لدى المزود).
2. منطقة التخزين: النسخ الاحتياطية نسخ من بيانات شخصية. إذا كنت تخضع لنظام حماية البيانات الشخصية في السعودية، أو لقوانين حماية البيانات الشخصية في الإمارات وقطر والبحرين وعُمان، أو لتنظيمات حماية البيانات في الكويت، فاختيار منطقة التخزين قرار تنظيمي أيضًا؛ راجع مستشارك القانوني.

هل تكفي حماية المزود أم تشفّر بنفسك؟

شفّر قبل الرفع. التشفير من جهة المزود يحميك من سرقة الأقراص لديه، لكن المزود يملك المفتاح. التشفير من جهتك يعني أن أي شخص يصل إلى الـ bucket يرى بيانات لا يستطيع قراءتها. restic يشفّر افتراضيًا، ومع rclone استخدم طبقة crypt، أو شفّر الأرشيف بـ age أو gpg.

المفتاح أهم من النسخة. إذا ضاع المفتاح ضاعت كل النسخ. احفظه في مدير أسرار، ونسخة منه مطبوعة أو في خزنة منفصلة، ولا تحفظه في الـ bucket نفسه.

كم نسخة تحتفظ بها ولأي مدة؟

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

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

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

كيف تحمي النسخ من برامج الفدية؟

برامج الفدية الحديثة تبحث عن النسخ الاحتياطية وتحذفها قبل التشفير. الحماية هي عدم القابلية للتعديل (immutability). في التخزين المتوافق مع S3 تقدم ميزة Object Lock ذلك: كل كائن يُكتب يُقفل حتى تاريخ محدد، ولا يمكن حذفه أو استبداله قبل ذلك التاريخ، حتى بمفاتيح المسؤول في وضع compliance. يتطلب ذلك عادة تفعيل versioning على الـ bucket، وبعض المزودين يشترطون تفعيل Object Lock عند إنشائه. تحقق من دعم مزودك قبل الاعتماد عليه، واجعل مدة القفل أطول من دورة الاحتفاظ اليومية على الأقل.

ما هو 3-2-1-1-0؟

امتداد للقاعدة يضيف رقمين:

• 1 نسخة غير متصلة أو غير قابلة للتعديل، مثل bucket مفعّل عليه Object Lock أو وسيط مفصول عن الشبكة.
• 0 أخطاء عند التحقق. أي أن النسخ تُفحص آليًا وتُختبر استعادتها، ولا تُقبل نسخة فيها خطأ.

الرقم الأخير هو الأهم، وهو ما يُهمل عادة.

لماذا اختبار الاستعادة هو الاختبار الحقيقي؟

لأن نجاح أمر النسخ لا يعني أن النسخة قابلة للاستعادة. ملف تصدير مقطوع، أو مفتاح تشفير خاطئ، أو قاعدة بيانات لم تُضمَّن في القائمة، كلها لا تظهر إلا عند الاستعادة. اجعل الاستعادة تمرينًا مجدولًا:

1. تحقق آلي أسبوعي من سلامة المستودع، مثل restic check --read-data-subset=5%.
2. تمرين استعادة شهري: اختر حسابًا عشوائيًا واستعده إلى بيئة معزولة، لا فوق الحساب الحي.
3. تحقق من النتيجة: افتح الموقع، وقارن عدد السجلات في جداول أساسية، وتأكد من وجود رسائل البريد وسجلات منطقة DNS ووظائف Cron.
4. سجّل الزمن: كم استغرقت الاستعادة من البداية حتى عمل الموقع؟ هذا رقمك الحقيقي، لا التقدير.
5. وثّق الخطوات حتى ينفذها أي شخص في الفريق تحت الضغط.

ما معنى RPO وRTO بلغة بسيطة؟

• RPO (أقصى فقد مقبول للبيانات): كم من العمل يمكنك أن تخسر؟ إذا كانت النسخة يومية فقد تخسر يومًا كاملًا من الطلبات والرسائل.
• RTO (أقصى زمن مقبول للتوقف): كم يمكن أن يبقى الموقع متوقفًا حتى يعود؟

حدد الرقمين لكل نوع موقع. موقع تعريفي ثابت يتحمل نسخة يومية واستعادة خلال ساعات. متجر إلكتروني يحتاج نسخًا أكثر تكرارًا لقاعدة البيانات، وربما سجلات binlog لاستعادة نقطة زمنية محددة. ثم قارن RTO المطلوب بالزمن الذي سجلته في تمرين الاستعادة؛ إن كان التمرين أبطأ فالخطة لا تحقق الهدف.

قائمة التحقق

• ثلاث نسخ، على وسيطين، وواحدة خارج الموقع لدى مزود آخر.
• النسخة تشمل الملفات وقواعد البيانات والبريد الإلكتروني ومنطقة DNS ووظائف Cron والإعدادات.
• تصدير قواعد البيانات متسق، وpipefail مفعّل، وحالة الخروج مراقبة بتنبيه.
• التشفير قبل الرفع، والمفتاح محفوظ في مكانين بعيدًا عن الـ bucket.
• مفاتيح الخادم للرفع فقط، والحذف يتم من مكان آخر.
• سياسة احتفاظ يومية وأسبوعية وشهرية مكتوبة.
• Object Lock أو نسخة غير متصلة ضد برامج الفدية.
• تمرين استعادة شهري مسجل الزمن والنتيجة.
• RPO وRTO محددان لكل نوع موقع ومقارنان بنتائج التمرين.

كيف يساعدك bPanel في النسخ الاحتياطي؟

يتيح bPanel النسخ الاحتياطي إلى تخزين متوافق مع S3 من داخل اللوحة، مع معاينة محتوى النسخة قبل الاستعادة، فترى الملفات وقواعد البيانات وحسابات البريد الإلكتروني التي ستُستعاد قبل أن تؤكد. جرّبه على خوادمك من ابدأ مع bPanel.

الخلاصة

• 3-2-1 نقطة البداية، و3-2-1-1-0 يضيف نسخة غير قابلة للتعديل وتحققًا بلا أخطاء.
• انسخ الحساب كاملًا، لا الملفات وقواعد البيانات فقط.
• شفّر من جهتك، وافصل صلاحية الرفع عن صلاحية الحذف.
• النسخة التي لم تُختبر استعادتها لا يُعتمد عليها، فاجعل الاستعادة تمرينًا مجدولًا.