هذا الاختبار ليس الفحص الآلي: ما الذي يضيفه
يصف الدليل الخاص باستراتيجية 3-2-1 مع Restic وS3 فحصاً آلياً: ملف حارس يُستعاد كل أسبوع وينبّه عند انقطاع سلسلة النسخ. هذا مفيد ويجب الإبقاء عليه. لكنه يجيب عن سؤال «هل يمكن قراءة المستودع؟» لا عن «هل يعود موقع العميل للعمل وبعد كم من الوقت؟». استعادة ملف من بضعة بايتات لا تقول شيئاً عن قاعدة البيانات أو الملفات المرفوعة أو إصدار PHP المطلوب أو الأسرار المفقودة.
يستعيد تمرين هذا الدليل موقعاً كاملاً، يدوياً، على جهاز جديد، ويستخلص ثلاثة قياسات: مدة، وعمر البيانات، وقائمة بالملاحظات. الآليتان لا تتنافسان. الفحص الآلي يكشف العطل كل أسبوع، والتمرين الفصلي يثبت الاستعادة بتوقيع وتاريخ. وهذا هو الدليل الذي ينتهي العميل أو المناقصة أو التدقيق إلى طلبه.
ولا ينبغي خلطه كذلك بفحص الاستعادة الوارد في قائمة التدقيق الأمني الشهري لخادم VPS خاص بعميل: ذاك يتحقق كل شهر من استعادة ملف أو قاعدة بيانات، بينما يعيد التمرين الفصلي في هذا الدليل تشغيل موقع كامل والمؤقت في اليد.
ما يثبته التمرين ولا تثبته النسخة وحدها
- المستودع يُقرأ دون الخادم الأصلي — تنطلق الاستعادة من المستودع البعيد وبأسرار محفوظة في مكان آخر، وليس من قرص الموقع أبداً.
- الموقع يعمل فعلاً — الصفحة الرئيسية وتسجيل الدخول إلى الإدارة وآخر محتوى في قاعدة البيانات تستجيب على الجهاز الجديد.
- RTO يُقاس ولا يُفترض — مدة مرصودة تحل محل التقدير «نحو ساعة».
- RPO يفي بوعده — الفارق بين الحادث المحاكى واللقطة المستعادة يُقارن بما يعلنه العقد.
- الصلاحيات في أيدٍ أمينة — يكشف الاختبار من يملك فعلاً كلمة مرور المستودع ومفاتيحه.
- يوجد دليل — سجل مؤرخ وموقّع يُسلَّم للعميل يعمل حجة بيع وحماية عند أي نزاع.
التحضير للاختبار: النطاق والجهاز المؤقت والجهد
اختر موقعاً واحداً لكل عميل في كل فصل مع تنويع النماذج: موقع يعتمد على قاعدة بيانات، وآخر بملفات مرفوعة كبيرة، وثالث بمهام مجدولة. قبل البدء اجمع ثلاثة عناصر خارج خادم الموقع: صلاحية الوصول إلى المستودع، وكلمة المرور أو المفتاح الذي يفتحه، وقائمة أسرار التطبيق.
ثم استأجر خادم VPS تجريبياً مؤقتاً بنفس نظام الإنتاج، واعزم على حذفه في نهاية الجلسة. أما الجهد، فاحسب كرتبة قدر تحريرية نصف يوم لكل فصل لموقع نموذجي، وأكثر لمستودع كبير، وأقل حين يصبح الإجراء معتاداً. دوّن ساعة البدء قبل أول أمر، وليس بعده.
الإجراء في تسع خطوات
تحديد الحادث المحاكى
دوّن الساعة الدقيقة للحادث المحاكى، مثل آخر كتابة معروفة على الموقع، ونطاق الاستعادة: ملفات وقاعدة بيانات وإعدادات. تُستخدم هذه الساعة في حساب RPO.
إنشاء خادم VPS التجريبي
أنشئ جهازاً جديداً بنظام التشغيل نفسه المستخدم في الإنتاج. لا يصل إليه أي ملف من القرص الأصلي. دوّن ساعة البدء: فهي نقطة انطلاق مؤقت RTO.
تثبيت الأداة وفتح المستودع
ثبّت أداة النسخ الاحتياطي ومكدس الموقع فقط (خادم الويب وPHP وقاعدة البيانات). استرجع بيانات الدخول من خزنة كلمات المرور، وليس من الخادم المنكوب. يجب أن يعرض الأمر
restic -r <repository> snapshotsنقاط الاستعادة.اختيار اللقطة
اختر آخر لقطة سابقة للحادث المحاكى ودوّن معرّفها وطابعها الزمني. هي التي تحدد RPO المرصود.
استعادة الملفات
restic -r <repository> restore <id> --target /srv/restore
ثم انقل المحتوى إلى مجلد الويب. مع Borg انتقل أولاً إلى المجلد الهدف لأن الاستخراج يكتب في المجلد الحالي:cd /srv/restore && borg extract <repository>::<archive>.استعادة قاعدة البيانات
pg_restore --create --dbname=postgres backup.dump
وللتفريغ النصيpsql -f backup.sql. بعد ذلك عُدّ صفوف جدول شاهد (SELECT count(*) FROM orders;) وقارنها بالقيمة المقروءة في الإنتاج قبل الاختبار.إعادة بناء الإعدادات
أعد وضع ملف
.envوالأسرار وملف vhost والمهام المجدولة انطلاقاً من الخزنة، ثم طابق إصداري PHP وقاعدة البيانات مع الإنتاج.التحقق من التطبيق
افتح الصفحة الرئيسية وسجّل الدخول إلى الإدارة وابحث عن آخر طلب أو مقال في قاعدة البيانات. دون لمس DNS:
curl -k --resolve your-domain.com:443:<TEST_VPS_IP> https://your-domain.com/.إيقاف المؤقت وحذف الجهاز
أوقف المؤقت عند أول طلب ناجح إلى التطبيق، وليس عند انتهاء أمر الاستعادة. احسب RTO وRPO واملأ السجل، ثم احذف خادم VPS التجريبي.
المؤقت: RTO وRPO المرصودان
RTO المرصود هو ساعة انتهاء الاستعادة الموثقة ناقص ساعة بدء الاختبار. أما RPO المرصود فهو الفارق بين ساعة الحادث المحاكى والطابع الزمني للقطة المستعادة. خذ مثالاً افتراضياً: حادث محاكى عند 14:00، وآخر لقطة التُقطت عند 03:00 في اليوم نفسه، أي 11 ساعة من البيانات المفقودة. إن وعد العقد بـ 24 ساعة فالنتيجة مطابقة، وإن وعد بـ 4 فهي غير مطابقة، ويجب أن يكتب السجل ذلك كما هو.
يبقى RTO المقيس في اختبار حداً أدنى متفائلاً: جهاز جديد ولا أحد ينتظر ولا ضغط. ومع ذلك فهو أفضل من حساب تقريبي، خاصة مع مستودع كبير: فمع سرعة اتصال متواضعة يكفي زمن التنزيل ليجعل RTO النظري غير واقعي. قِس السرعة الفعلية أثناء الاستعادة ودوّنها في السجل.
سجل الاختبار: الحقول المطلوب ملؤها
مرّر الجدول أفقيًا
| الحقل | ما يُدوَّن | مثال |
|---|---|---|
| التاريخ والموقع | يوم الاختبار وموقع العميل المستعاد | DD/MM/YYYY، موقع تجريبي |
| الأداة واللقطة | أداة النسخ ومعرّف اللقطة وطابعها الزمني | Restic، معرّف قصير، طابع زمني كامل |
| المدة وRTO | ساعة البدء وساعة الانتهاء الموثقة والمدة المرصودة | البدء 09:00، الانتهاء 10:40، RTO 1 h 40 |
| RPO المرصود | الفارق بين الحادث المحاكى واللقطة مقارناً بالهدف | 11 ساعة مرصودة مقابل 24 ساعة موعودة |
| الملاحظات | كل ما عطّل الاستعادة أو أبطأها | مجلد الملفات المرفوعة خارج النطاق |
| التصحيح والأجل | الإجراء والمسؤول وتاريخ التنفيذ | إضافة المجلد إلى المستودع قبل الاختبار القادم |
| الموقِّع | الشخص الذي يشهد على الاختبار | الاسم والصفة والتوقيع |
| خارج النطاق | ما لم يُختبر | البريد وDNS والشهادات والخدمات الخارجية |
أوامر مرجعية لكل أداة
مرّر الجدول أفقيًا
| الأداة | عرض نقاط الاستعادة | الاستعادة والتحقق |
|---|---|---|
| Restic | `restic -r <repository> snapshots` | `restic -r <repository> restore <id> --target /srv/restore` |
| Restic، سلامة المستودع | `restic -r <repository> check` | يتحقق `check` من البنية؛ ويعيد `--read-data` قراءة المستودع كاملاً، و`--read-data-subset=10%` جزءاً عشوائياً منه |
| Borg | `borg list <repository>` ثم `borg list <repository>::<archive>` | `borg extract --list <repository>::<archive>` من المجلد الهدف؛ ويقرأ `--dry-run` ويتحقق دون كتابة |
| PostgreSQL، تفريغ custom | `pg_restore --list backup.dump` | `pg_restore --create --dbname=postgres backup.dump` ثم عدّ جدول شاهد |
| PostgreSQL، تفريغ نصي | التحقق من حجم الملف وتاريخه | `psql -f backup.sql` ثم عدّ جدول شاهد |
| الملفات المرفوعة | مقارنة عدد ملفات المستودع بالإنتاج | `find /srv/restore -type f | wc -l` ثم فتح ثلاثة ملفات عشوائياً |
فخاخ الاستعادة وأعراضها
- مفتاح المستودع مخزَّن على الخادم المنكوب — لا يفتح الجهاز الجديد المستودع ويعرض
wrong password or no key found؛ احتفظ بالمفتاح في خزنة منفصلة مع حاملَين له. - قاعدة البيانات مستعادة والملفات المرفوعة غائبة — يظهر الموقع لكن الصور والمرفقات تعيد 404؛ كان النطاق يشمل القاعدة وحدها أو الشيفرة وحدها.
- إصدار PHP أو قاعدة البيانات مختلف — صفحة بيضاء أو خطأ في الصياغة أو الترحيل؛ دوّن في السجل إصدارات كل موقع.
- الأسرار وملف
.envبلا نسخة — يعمل التطبيق لكنه لا يصل إلى قاعدة البيانات ولا خادم البريد ولا واجهات الأطراف الخارجية. - مستودع أكبر من سعة النطاق الترددي — يبدو RTO النظري جيداً ويتجاوز الحقيقي الوعد؛ قِس السرعة قبل أن تعد.
- تفريغ مبتور — لا يطابق عدد صفوف الجدول الشاهد الإنتاج؛ أعد النسخ وتحقق من حجمه.
- مهام مجدولة لم تُنشأ من جديد — يستجيب الموقع لكنه لم يعد يرسل رسائل أو تذكيرات؛ احصِ مهام cron قبل الاختبار.
استكشاف الأخطاء: أخطاء شوهدت أثناء التمرين
Fatal: wrong password or no key found — لا يجد Restic مفتاحاً يُفتح بكلمة المرور المقدمة. الأسباب الشائعة التي ينبغي استبعادها واحداً واحداً: كلمة مرور بأحرف خاصة غيّرها الـ shell، أو كلمة مرور قُرئت من الدخل القياسي، أو عنوان مستودع S3 بنمط خاطئ، أو ملف مفتاح تالف. جرّب --password-file أو المتغير RESTIC_PASSWORD، وتحقق من عنوان المستودع ثم نفّذ restic key list. وإن ضاعت كلمة المرور فعلاً، ضاعت معها بيانات المستودع: سجّل ذلك كملاحظة حرجة.
لا توجد نقطة استعادة حديثة — لا يعرض restic snapshots أي شيء من الأسبوع الأخير: مهمة النسخ تتوقف بصمت. أصلح المؤقت وأضف تنبيهاً.
ينتهي pg_restore مع أخطاء متجاهَلة — يتابع افتراضياً ويعرض عدّاداً في النهاية. أعد التنفيذ بالخيار --exit-on-error ليتوقف عند أول خطأ، واقرأه قبل إعلان نجاح الاختبار.
الملفات موجودة لكن الموقع يعيد 403 — ترك التنفيذ بصلاحيات root الملفات لمالك خاطئ. أعدها إلى مستخدم خادم الويب.
كلمة مرور المستودع لا تعيش وحدها على الخادم
احتفظ بها في خزنة الفريق مع نسخة مختومة لدى مسؤول ثانٍ. يبدأ التمرين بفتح المستودع من تلك الخزنة: إن اضطر أحدهم إلى الدخول إلى خادم الموقع ليجد كلمة المرور، فقد فشل الاختبار فعلاً، وهذه أنفع ملاحظة يمكن أن يكشفها.
السجل المسلَّم للعميل: صفحة واحدة وما لم يُختبر
يتسع السجل لصفحة واحدة: ترويسة بالعميل والموقع والتاريخ؛ وجدول الحقول الثمانية؛ وخلاصة في جملة واحدة، مطابقة أو غير مطابقة لهدفي RPO وRTO؛ وخطة تصحيحية مؤرخة؛ وتوقيع. خصص في الأخير إطاراً بعنوان «لم يُختبر في هذا التمرين»: صناديق البريد وقابلية التسليم، وDNS والتفويض، وشهادات TLS، والخدمات الخارجية كالدفع أو نظام CRM، وأي موقع آخر في الحساب.
السجل الذي لا يكتب حدوده يُقرأ على أنه «كل شيء منسوخ احتياطياً»، وهذا وعد لا يستطيع أحد الوفاء به. احتفظ بسجلات كل فصل: اختبار واحد يثبت يوماً واحداً، وسلسلة اختبارات تثبت ممارسة. دوّن أيضاً إصدار PHP لكل موقع كما في الدليل الخاص بجرد الإصدارات في محفظة العملاء: إنه الفخ الأكثر تكراراً عند إعادة الاستعادة.
من جهة العقد: ما يجب أن يسمّيه بند النسخ الاحتياطي
يسمّي البند المفيد سبع نقاط: النطاق (الملفات وقواعد البيانات والإعدادات)، والتكرار، ومدة الاحتفاظ، وهدفي RPO وRTO، وتكرار الاختبارات ودليلها، والمسؤولية إذا فشلت الاستعادة، وصاحب صلاحيات الوصول إلى المستودع. هذا ليس استشارة قانونية: اعرض النص على محامٍ. ولا تَعِد أبداً بما لا تضمنه البنية التحتية الأساسية.
وفي هذه النقطة، نسخ ServOrbit.com الاحتياطية أسبوعية في الفئة الأولى، ويومية في Pro وفي جميع عروض استضافة الموزعين. ويُستنتج الحد الأدنى لـ RPO من هذا التكرار: حتى سبعة أيام مع نسخة أسبوعية، وحتى يوم واحد مع نسخة يومية. لذلك يتطلب RPO أقل من يوم نسخة تطبيقية خاصة بالوكالة إضافة إلى ذلك. أما مدة الاستعادة فلا يُستنتج أي التزام من التكرار: إنها تُقاس، بالتمرين الوارد أعلاه.
جعل الاختبار قابلاً للفوترة: حجة بيع لا عبء
الاعتراض معروف: العميل لا يطلبه والوقت غير مفوتر. هناك جوابان. أدرج في عقد الصيانة بنداً «اختبار استعادة فصلي مع تسليم السجل»، أو افوتر نصف اليوم على حدة. وعامل السجل كمخرَج: بعد الحادث يبين ما اختُبر وصُحّح، وأثناء البيع يجيب عن «أثبتوا ذلك» قبل أن يُطرح السؤال.
للحفاظ على الإيقاع في محفظة مواقع، خطط لتناوب: موقع واحد لكل عميل في كل فصل، وجدول يُحدَّد في بداية السنة. يُستأجر خادم VPS التجريبي ويُحذف عند الطلب؛ وشروطه في صفحة العرض.
