فقدان بياناتك هو العلّة الوحيدة التي لا يمكن إصلاحها

أنت مهووس بجودة الشيفرة. تراجع طلبات الدمج، وتكتب الاختبارات، وتتجادل في التسميات.

والآن أجب عن سؤال واحد بصدق. متى آخر مرّة استعدت قاعدة بياناتك من نسخة احتياطية وشاهدت التطبيق يعود للعمل؟ أغلب المؤسّسين لم يفعلوها قط.

الشيفرة تنكسر، والبيانات تختفي

العلّة في شيفرتك يوم سيّئ. أحدهم يبلّغ عنها، وتعيد إنتاجها، وتدفع الإصلاح. مؤلم، لكنه محتمَل ومعتاد.

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

وهذا الاختلال هو الحجّة كلّها.

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

ما اختبار الاستعادة

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

اختبار الاستعادة الحقيقي صغير وممل.

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

والخطوة الأخيرة هي ما يسقط فيه أول اختبار عادةً. الفرق تأخذ نسخة من PostgreSQL وتنسى الصور في المجلّد المجاور لها.

قاعدة 3-2-1

ثلاث نسخ من بياناتك، على نوعين مختلفين من التخزين، وواحدة منها في مكان آخر.

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

RPO و RTO بكلام بسيط

مصطلحان يستحقّان المعرفة، لأنهما يحوّلان قلقاً غامضاً إلى رقم تستطيع أن تقرّره.

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

RTO، أي هدف زمن التعافي، هو كم تحتمل أن تبقى متوقّفاً بينما تستعيد. وهو لا يُقدَّر تخميناً، بل يُقاس، واختبار الاستعادة هو القياس.

كل كم مرّة تأخذ نسخة

الوتيرة	ما يكلّفه العطل	الحكم
يومياً	ما يصل إلى يوم من البيانات	افعلها إن استطعت
أسبوعياً	ما يصل إلى أسبوع من البيانات	أقلّ ما ينبغي أن تقبله
أقلّ من أسبوعياً	بيانات لن تستردّها	مقامرة

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

للقانون رأي في الأمر

بموجب قوانين مثل PDPL السعودي (نظام حماية البيانات الشخصية) و DPDP Act الهندي (قانون حماية البيانات الشخصية الرقمية)، فقدان البيانات بسبب تخطّي الضمانات الأساسية ليس إخفاقاً تشغيلياً فحسب. بل يمكن أن يُعدّ مخالفة امتثال بذاته، منفصلة عن أي اختراق. وكلا القانونين يستحقّ مقالاً خاصاً به، وسيناله.

نصف الخطر فقط

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

النسخة الاحتياطية التي لم تستعدها يوماً تخمين، لا شبكة أمان.

فأيّهما لديك — استعادة مختبَرة، أم أمل بأن النسخة تعمل؟