تمارين استعادة النسخ الاحتياطية: دليل عملي لاختبار استعادة الملفات وقواعد MySQL/MariaDB وPostgreSQL

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

لماذا تستحق التمارين وقتك

اختبار الاستعادة ضابط معياري وليس إضافة اختيارية. فالمعيار NIST SP 800-53 (المراجعة 5) يتضمن تحسينات للضابط تقضي باختبار معلومات النسخ للتحقق من موثوقية الوسائط وسلامة المعلومات (CP-9(1))، وباستخدام عينة من النسخ لاستعادة وظائف مختارة من النظام ضمن اختبار خطة الطوارئ (CP-9(2)). وفي المملكة العربية السعودية تنص الضوابط الأساسية للأمن السيبراني الصادرة عن الهيئة الوطنية للأمن السيبراني (إصدار ECC-1:2018)، والمطبقة على الجهات الحكومية وعلى جهات القطاع الخاص التي تملك بنى تحتية وطنية حساسة أو تشغّلها أو تستضيفها، على الاختبار الدوري لمدى فعالية استعادة النسخ الاحتياطية ضمن متطلبات إدارة النسخ والاستعادة. وحتى إن لم ينطبق عليك أيٌّ منهما، فالتمرين هو الطريقة الوحيدة لقياس زمن التعافي الحقيقي لديك.

التحضير للتمرين

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

التمرين الأول: الملفات والإعدادات

استعد إلى مجلد فارغ وانظر إلى ما عاد فعلاً، لا إلى نجاح الأمر فحسب. مع restic مثلاً:

restic snapshots --latest 3
restic restore latest --target /srv/drill --include /var/www --include /etc/nginx
find /srv/drill/var/www -type f | wc -l
find /var/www -type f | wc -l
ls -l /srv/drill/etc/nginx/sites-enabled/

تحقق من أن أعداد الملفات ضمن المتوقع، وأن الملفات المهمة تُفتح، وأن الملكية والصلاحيات عادت كما كانت. ومع أرشيفات tar يعرض الأمر tar -tzf archive.tar.gz | head المحتويات قبل فكّها عبر tar -xzf archive.tar.gz -C /srv/drill. وتأكد من أن الأسرار والإعدادات الموجودة خارج مجلد الموقع، مثل ملفات .env ومفاتيح TLS ووحدات systemd، موجودة في النسخة أيضاً، فهي أكثر ما يُنسى.

التمرين الثاني: MySQL أو MariaDB

ثبّت على جهاز التمرين الإصدار الرئيسي نفسه المستخدم في الإنتاج، ثم حمّل ملف التصدير واستعلم منه:

sudo apt install mariadb-server
zcat shop-2026-10-31.sql.gz | sudo mariadb
sudo mariadb -e "SHOW DATABASES;"
sudo mariadb shop -e "SELECT COUNT(*), MAX(created_at) FROM orders;"

أحدث طابع زمني في جدول نشط يخبرك بنقطة الاستعادة التي حققتها فعلاً؛ فإن كان قبل يومين فنسختك «الليلية» لا تعمل كل ليلة. وإن كنت تستخدم النسخ الفيزيائي (mariadb-backup أو Percona XtraBackup) فيجب أن يشمل التمرين خطوة التحضير وتشغيل خادم على مجلد البيانات المستعاد، لأن النسخة غير المحضّرة لا تصلح للاستخدام. وإن كنت تعتمد على السجلات الثنائية للاستعادة إلى نقطة زمنية، فأعد تنفيذها حتى وقت تختاره مرة كل ربع سنة على الأقل.

التمرين الثالث: PostgreSQL

استعد العناصر العامة (الأدوار) أولاً، ثم قاعدة البيانات، ونفّذ استعلامات مماثلة:

sudo -u postgres psql -f globals-2026-10-31.sql
sudo -u postgres createdb shop_drill
sudo -u postgres pg_restore -d shop_drill -j 4 shop-2026-10-31.dump
sudo -u postgres psql -d shop_drill -c "SELECT count(*), max(created_at) FROM orders;"

الأخطاء المتعلقة بأدوار مفقودة تعني عادة أن العناصر العامة لم تُنسخ قط. ومع النسخ الفيزيائية شغّل pg_verifybackup على النسخة الأساسية ثم شغّل عنقوداً منها على جهاز التمرين، فدليل PostgreSQL ينبّه إلى أن التحقق لا يغني عن الاستعادة التجريبية. وإن كنت تؤرشف WAL فاستعد إلى recovery_target_time تختاره من حين لآخر.

التمرين الرابع: التطبيق

البيانات التي تُحمَّل بنجاح لا تعني خدمة تعمل. وجّه نسخة تجريبية من التطبيق إلى قاعدة البيانات والملفات المستعادة، وسجّل الدخول، وافتح سجلاً حديثاً، ونفّذ عملية اعتيادية واحدة؛ فهنا تظهر متغيرات البيئة ومفاتيح الواجهات البرمجية والملفات المرفوعة المفقودة.

ما الذي تسجّله

احتفظ بسجل قصير لكل تمرين، في المكان نفسه كل مرة:

قارن الأزمنة المقيسة بأهداف زمن التعافي ونقطة التعافي في خطة التعافي من الكوارث لديك؛ فإن استغرق التمرين ست ساعات والخطة تعد بساعتين، فإما أن تتغير الخطة أو يتغير تصميم النسخ.

كم مرة؟

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

ما الذي ينبغي فعله

1. جهّز جهاز تمرين معزولاً مع تعطيل البريد الصادر والمهام المجدولة.
2. دوّن معايير النجاح وأهداف التعافي التي تختبرها.
3. استعد الملفات وكل قاعدة بيانات والتطبيق، وافحص المحتوى لا رموز الخروج فقط.
4. سجّل الأزمنة وأحدث بيانات وُجدت وكل مشكلة، وحدّد مسؤولاً لكل متابعة.
5. كرّر التمرين شهرياً للعينات وربع سنوياً لإعادة البناء الكامل، وبعد كل تغيير في منظومة النسخ.

المصادر

• csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/SP800-53/rev5/json/NIST...
• nca.gov.sa/ecc-en.pdf
• restic.readthedocs.io/en/stable/050_restore.html
• restic.readthedocs.io/en/stable/045_working_with_repos.html
• github.com/restic/restic/blob/v0.19.1/cmd/restic/cmd_snapshots.go
• mariadb.com/docs/server/server-usage/backup-and-restore/mariadb-backup/full-backup-and-...
• mariadb.com/docs/server/mariadb-quickstart-guides/mariadb-restore-guide
• postgresql.org/docs/current/app-pgrestore.html
• postgresql.org/docs/current/app-pgverifybackup.html
• postgresql.org/docs/current/continuous-archiving.html
• cloud.alskyline.com/vps-saudi-arabia