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

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

الجزء الأول: رقمان قبل أي أداة

قبل ما تختار أداة أو مزوّد، اتفق على رقمين. الأول: كم بيانات تتحمل تخسر؟ لو النسخ يومي الساعة ثلاث الفجر، وصار العطل الساعة خمس العصر، فأنت خسرت أربع عشرة ساعة من الطلبات والتسجيلات. هذا يسمونه RPO، أقصى فترة بيانات مقبول تضيع. الثاني: كم تتحمل النظام يبقى واقف؟ ساعة؟ يوم؟ هذا RTO، أقصى وقت مقبول للتوقف. متجر يبيع على مدار الساعة أرقامه غير نظام داخلي يستخدمه فريق صغير في وقت الدوام. والرقمين يحددون كل شي بعدهم: نسخ يومي يكفي، أو تحتاج استرجاعاً لنقطة زمنية محددة، مثل اللي توفره قواعد PostgreSQL عبر أرشفة سجلات المعاملات، بحيث ترجع القاعدة لحالتها قبل الخطأ بدقيقة. واكتب الرقمين في الخطة بوضوح، لأن كل رقم أصغر له تكلفة أعلى في التخزين والأدوات، والقرار هنا قرار عمل قبل ما يكون قرار تقني.

الجزء الثاني: الجرد، لأن القاعدة مو كل شي

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

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

والكود؟ وجوده في مستودع Git على GitHub أو غيره نسخة جيدة، لكن تأكد إن إعدادات البنية التحتية مكتوبة ومحفوظة كمان، مو مضبوطة بالضغط في لوحة تحكم ما يتذكرها أحد.

الجزء الثالث: المزامنة مو نسخة احتياطية

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

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

الجزء الرابع: 3-2-1، ونسخة ما يقدر أحد يمسحها

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

الجزء الخامس: الصفحة اللي تُقرأ وقت الأزمة

يوم الكارثة ما أحد يقدر يفكر بهدوء. فاكتب الآن ورقة تشغيل يقدر يتبعها شخص متوتر الساعة ثلاث الفجر:

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

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

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