المستوى المطلوب: متوسط. لازم تكون مرتاح مع bash و GitHub Actions و PostgreSQL، ومش لازم تكون عملت Disaster Recovery قبل كده.
لو عندك نسخة backup يومية بتترفع على S3 من 18 شهر ومش عارف فعلاً لو هتقدر ترجّعها أو لأ، انت في خطر أكبر من اللي معندوش backup أصلاً. السبب إنك بتاخد قرارات مبنية على وهم. هذا المقال هيوريك ازاي تأتمت اختبار الاسترجاع كل ليلة في 75 سطر، وتشوف نتيجة كل اختبار قبل ما تصحى الصبح.
ليه نسختك الاحتياطية ميتة لحد ما تجرّب ترجّعها
المشكلة باختصار: Schrödinger's Backup
في مقولة شهيرة بين مهندسي البنية التحتية: "حالة أي backup غير معروفة لحد ما تجرّبه — هي في نفس الوقت بتشتغل وما بتشتغلش". الرقم اللي بيخوّف: استطلاع Veeam Data Protection Trends 2024 لاقى إن 76% من الشركات حصلها حادثة فقد بيانات في آخر سنتين، و 43% من محاولات الاسترجاع فشلت كليًا أو جزئيًا.
المسبّب الأساسي مش إن النسخة بتتلف فيزيائيًا. المسبّب إن سكربت الـ backup بيكتب ملف، بس محدش بيتأكد إن الملف ده فيه فعلاً البيانات الصح وقابل للاسترجاع. ده اللي بيتسمّى silent corruption: السكربت بيرجّع exit 0 بسعادة، والملف على S3 وزنه 12 بايت لأن الـ disk اتملا في النص.
مثال للمبتدئ: العجلة الاحتياطية في عربيتك
تخيّل إنك بتشتري عربية، الشركة بتقولك "في عجلة احتياطية في الشنطة". انت موافق وراضي ومش بتفتح الشنطة لمدة 3 سنين. يوم ما يبوظ كاوتش وانت في الصحرا الساعة 11 بالليل، تفتح الشنطة وتلاقي العجلة موجودة، بس فاضية هوا، أو الـ jack مش معاها، أو البلوغة مش بتفك من الكاوتش الأصلي.
الـ backup من غير اختبار استرجاع زي العجلة الاحتياطية اللي محدش طلّعها من الشنطة. موجودة، نعم. شغّالة، مش متأكد. والمكان الوحيد اللي هتعرف فيه هو لحظة الكارثة. اختبار الاسترجاع اليومي معناه إنك بتفتح الشنطة كل ليلة وتجرّب العجلة على الأرض قبل ما تحتاجها.
التعريف العلمي: Restore Verification و RTO و RPO
الفكرة الأكاديمية اللي بنبني عليها هنا اسمها Restore Verification، وهي جزء من إطار Disaster Recovery اللي بيعرّفه AWS Well-Architected Framework في الـ Reliability Pillar، ومايكروسوفت في Azure Architecture Center. كل أتمتة استرجاع لازم تقيس 4 مقاييس صريحة:
- RTO — Recovery Time Objective: أقصى زمن مسموح بيه قبل ما الخدمة ترجع. لو RTO = 4 ساعات والاسترجاع بياخد 6، انت فعليًا فاشل في عقدك مع المستخدمين.
- RPO — Recovery Point Objective: أقصى كم بيانات مسموح تخسره. لو بتاخد backup كل 24 ساعة، فالـ RPO بتاعك = 24h. لو دي مش مقبولة لشركتك، الحل replication مش backup أكتر.
- MTTR — Mean Time To Restore: المتوسط الفعلي لزمن الاسترجاع من بيانات حقيقية، مش تقديرات.
- Restore Success Rate: نسبة محاولات الاسترجاع الناجحة في فترة. الهدف الصناعي 99%+.
الافتراض في باقي المقال: عندك PostgreSQL واحد، حجمه أقل من 50GB، بتاخد كل ليلة وبترفعه على S3، وعندك runner GitHub Actions أو سيرفر صغير ينفذ الاختبار. لو حجمك أكبر من 200GB أو عندك streaming replication معقّد، تفصيلات السكربت هتحتاج تتعدل (هنشير لده تحت).
