الاستمرارية والاستعادة: النسخة الاحتياطية التي لم يختبرها أحد

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

لماذا علامة الاختيار تكذب

يبلغ برنامج النسخ الاحتياطية عن النجاح عندما ينتهي من كتابة البيانات إلى وجهة. لا يعرف ما إذا كانت تلك البيانات قابلة للاستخدام. يمكن أن يكتمل النسخ الاحتياطي من SQL Server بنظافة ولا يزال غير قابل للاستعادة لأن سلسلة السجل عاد انقطعت قبل ثلاثة أيام ولم يلاحظها أحد. قد تبدو لقطات VM جيدة في وحدة التحكم بينما فشل كاتب VSS الأساسي بصمت داخل نظام التشغيل الضيف، مما ينتج صورة متسقة للأعطال (وليست متسقة مع التطبيق).

يعرف مشغلو برامج الفدية هذا. مجموعات تشغيل أنماط تشبه Conti في الحوادث السابقة استهدفت بعمد البنية التحتية للنسخ الاحتياطية — حذف النسخ الظلية باستخدام vssadmin delete shadows /all /quiet، تعطيل مستودعات Veeam، تشفير أهداف النسخ الاحتياطية المستندة إلى NAS التي كانت قابلة للوصول عبر SMB. إذا كانت نسخك الاحتياطية تعيش على نفس جزء الشبكة مثل الإنتاج مع بيانات اعتماد المجال التي يمكنها لمسها، فإنها هدف، وليست شبكة أمان.

بناء كتيب استعادة، لا سياسة نسخ احتياطي

تحتاج خطة الاستمرارية إلى تعليمات استعادة خطوة بخطوة مكتوبة لشخص ليس الشخص الذي عادة ما يفعلها. اكتب:

• ترتيب الاسترجاع الدقيق (وحدات تحكم المجال و DNS أولاً، ثم التطبيقات الأساسية، ثم كل شيء آخر)
• حيث تعيش بيانات اعتماد وحدة تحكم النسخ الاحتياطية إذا كانت خزانة كلماتك المرور معطلة أيضاً
• أمر الاستعادة المحدد أو مسار وحدة التحكم، وليس "استخدم Veeam لاستعادة VM"
• المدة المتوقعة لكل نظام، بناءً على الاختبارات المقاسة الفعلية، وليس أرقام تسويق البائع

بالنسبة إلى Veeam Backup & Replication، يعني ذلك توثيق الخطوات الفعلية: افتح وحدة التحكم، انتقل إلى Backups > Disk، انقر بزر الماوس الأيمن على نقطة الاستعادة، اختر Instant VM Recovery أو Full VM Restore حسب السيناريو، وحدد المضيف الهدف بسعة مجانية كافية. إذا كان المضيف الأساسي مخترقاً أيضاً، فتحتاج إلى مضيف ثانٍ معزول بالفعل معرّف ومرخص.

اختبر الاستعادات حسب الجدول الزمني، وليس بناءً على الرغبة

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

بالنسبة لقواعد البيانات، لا تستعد فقط ملف .bak — تحقق من صحته:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

ثم قم بالفعل باستعادتها إلى مثيل اختبار وقم بتشغيل DBCC CHECKDB ضدها. يمكن أن يحتوي النسخ الاحتياطي الذي يمر عبر VERIFYONLY على تعطل منطقي يظهر فقط عندما تستعلم عنه.

بالنسبة لأنظمة Linux باستخدام شيء مثل Bacula أو restic، اختبر مسار الاستعادة الفعلي:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

ثم قم بـ diff ملفات الإعدادات المستعادة مقابل الإنتاج للتأكد من عدم حذف أي شيء بصمت.

النسخ غير القابلة للتغيير وقاعدة 3-2-1-1

تحتاج القاعدة 3-2-1 الكلاسيكية (ثلاث نسخ وسوطين من الوسائط واحدة خارج الموقع) إلى تحديث في عصر برامج الفدية: 3-2-1-1، حيث يكون "1" الإضافي نسخة غير قابلة للتغيير أو معزولة بالهواء. Object lock على التخزين المتوافق مع S3 (Wasabi أو Backblaze B2 أو AWS S3 مع تمكين Object Lock) يمنع الحذف أو التعديل لنافذة احتفاظ محددة، حتى من قبل حساب بصلاحيات إدارية. قم بتكوينها باستخدام:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

يعني وضع COMPLIANCE أن لا أحد، بما فيهم الحساب الجذري، يمكنه تقصير الاحتفاظ أو حذف الكائنات مبكراً. هذا يهم عندما يكون لدى المهاجم مسؤول المجال.

قياس RTO و RPO بأرقام حقيقية، ليس بتخمين

يبدو Recovery Time Objective و Recovery Point Objective مثل تمارين الأوراق حتى يسأل رئيس تنفيذي "كم بيانات نفقدها وكم من الوقت نكون معطلين." وقت آخر ثلاث استعادات اختبارية لديك. إذا كان هدف RPO الخاص بك ساعة واحدة لكن وظيفة النسخ الاحتياطية تعمل فقط كل ستة، فلديك فجوة موثقة، ومن الأفضل العثور على تلك الفجوة في تمرين على الطاولة بدلاً من حادثة تشفير فعلية في الساعة 2 صباحاً يوم السبت.

قم بتشغيل الاختبار واكتب الوقت الفعلي على مدار الساعة وقارنه بما وعدت به في وثيقة استعادة الكوارث. الفرق بين هذين الرقمين هو الحالة الحقيقية لخطة الاستمرارية لديك.

للحصول على مزيد من المعلومات حول تقوية الأنظمة التي تحميها وبناء سير عمل الاستجابة للحوادث، تحقق من أقسام Blue Team و Digital Forensics ذات الصلة على Korra Studio.