اختبار الاستعادة: تحقق من نسخك الاحتياطية مسبقًا
كيف تُجري استعادة تجريبية، وما الذي تسجله كنتيجة، وما المفاجآت المعتادة التي لا تظهر إلا في التدريبات لا في كارثة حقيقية.
آخر تحديث 23 أغسطس 2026
النسخة الاحتياطية التي لم تستعد منها قط ليست نسخة احتياطية، بل أمل. الاستعادة التجريبية تستغرق ساعة واحدة مرة كل ربع سنة، وتحوّل الأمل إلى حقيقة موثّقة.
ما يجب التحقق منه
ثلاثة أسئلة تحتاج إلى إجابات عنها قبل أي حادث:
- الاكتمال. هل تحتوي النسخة الاحتياطية على كل ما يلزم للتشغيل: البيانات، والإعدادات، والمفاتيح، والشهادات، والجدول الزمني.
- قابلية القراءة. هل يُفتح الأرشيف، وهل تُستعاد تفريغة قاعدة البيانات دون أخطاء.
- الوقت. كم ساعة ستستغرق الاستعادة الكاملة. تحتاج إلى معرفة هذا الرقم مسبقًا، لا أن تكتشفه تحت الضغط.
كيف تُجري التدريب
الخيار الأصدق هو على جهاز منفصل، لا على جهاز الإنتاج. اطلب VDS-1 لمدة شهر، واستعد إليه من الصفر، وقِس الوقت.
export RESTIC_REPOSITORY="sftp:backup@backup.example.com:/srv/restic"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic snapshots
restic restore latest --target /restore
ls -la /restore
استعد قاعدة البيانات:
docker compose up -d db
gunzip -c /restore/var/backups/db.sql.gz | docker compose exec -T db psql -U postgres app
docker compose exec -T db psql -U postgres app -c "select count(*) from users;"
شغّل التطبيق وافتحه في المتصفح، فهذه هي الخطوة الأخيرة. وإلى أن تُفتح الصفحة، لم تحدث الاستعادة.
هناك خيار أخف وهو مفيد أيضًا: استعد قاعدة البيانات فقط داخل حاوية منفصلة على الجهاز نفسه، وتأكد من أن البيانات موجودة وحديثة.
تحقق ليس فقط من نجاح فك الضغط، بل أيضًا من تاريخ البيانات. فالنسخة الاحتياطية التي تُنشأ بموثوقية لكنها توقفت عن تضمين المجلد المطلوب منذ شهر تبدو طبيعية تمامًا في قائمة اللقطات. قارن عدد السجلات في الجداول والطوابع الزمنية لأحدث الملفات.
ما يظهر عادةً
- نسيان ملف
.env. البيانات موجودة، لكن كلمات المرور الخاصة بها مفقودة. - نسيان الشهادات. يعمل الموقع لكنه لا يستجيب عبر HTTPS.
- نسيان الجدول الزمني. كل شيء يعمل، لكن النسخ الاحتياطية لم تعد تُنشأ، وتكتشف ذلك بعد شهر.
- عدم تدوين تسلسل التشغيل. يبدأ التطبيق قبل قاعدة البيانات فيتعطل.
- كلمة مرور المستودع كانت على الجهاز المفقود فقط. النسخ الاحتياطية موجودة، لكن لا سبيل إلى الوصول إليها.
- الاستعادة تستغرق عشر ساعات، لا ساعتين. عرض نطاق المستقبِل أو رف الأقراص، انظر سرعة القرص.
دوّن الترتيب
بناءً على التدريب، اكتب تعليمات قصيرة واحفظها خارج الجهاز:
- اطلب جهازًا من المستوى نفسه أو أعلى، فالتجهيز يستغرق نحو دقيقة.
- ثبّت Docker واستعد
/opt/myappمن النسخة الاحتياطية. - استعد تفريغة قاعدة البيانات، وتحقق من عدد السجلات.
- استعد
/etc/nginxوالشهادات، وشغّل خادم الويب. - وجّه النطاق إلى العنوان الجديد.
- استعد الجدول الزمني من
crontab.txt. - تحقق: يُفتح الموقع، ويعمل تسجيل الدخول، وتُنشأ النسخ الاحتياطية من جديد.
البند 5 هو الأكثر بخسًا للقدر. فسجلات DNS لا تُحدَّث فورًا، وعليك خفض مدة صلاحية السجل إلى 300 ثانية مسبقًا إن كنت تضع الانتقال في الحسبان أصلًا.
كم مرة
مرة كل ربع سنة لخدمات الإنتاج، ومرة كل ستة أشهر لكل ما عداها. إضافة إلى ذلك دائمًا بعد أي تغيير كبير: قاعدة بيانات جديدة، أو خدمة جديدة، أو نقل مجلدات. ضع التدريب في التقويم، وإلا فلن يحدث أبدًا.
ما ينبغي أن يكون في النسخة الاحتياطية — ما يجب نسخه احتياطيًا بالضبط. ومن أين تأخذها — النسخ الاحتياطية خارج الموقع. وإن كان الحادث قد وقع بالفعل — فقدان البيانات.