اختبار النسخ الاحتياطي: ليش نسختك ممكن ما تشتغل

النسخة الاحتياطية التي لم تُختبر لا قيمة لها

37% من عمليات الاستعادة تفشل. الرقم صادم لكنه حقيقي. الشركات تنفق آلاف الريالات على أنظمة النسخ الاحتياطي ثم لا تختبرها أبداً. يكتشفون المشكلة في أسوأ وقت ممكن: عندما يحتاجون استعادة بياناتهم فعلاً.

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

أسباب فشل الاستعادة

1. تلف البيانات الصامت

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

2. نسخ ناقص

نظام النسخ يعمل لكنه لا ينسخ كل شيء. قاعدة بيانات مفتوحة لم يتم عمل dump لها. ملفات إعدادات خارج مسار النسخ. أذونات ملفات لم تُحفظ.

3. عدم توافق الإصدارات

نسخت البيانات من MySQL 8.0 وتحاول استعادتها على MySQL 5.7. أو نسخت إعدادات nginx لإصدار قديم. التوافق ليس مضموناً.

4. مشاكل التشفير

نسخة مشفرة بمفتاح فُقد أو انتهت صلاحيته. أو خوارزمية تشفير لم تعد مدعومة. التشفير ضروري لكنه يضيف نقطة فشل.

5. تجاوز سعة التخزين

مساحة التخزين امتلأت بدون إشعار. النسخ الجديدة لم تُكتمل. أو النسخ القديمة حُذفت قبل إنشاء بديل.

كيف تختبر النسخ الاحتياطي بشكل صحيح

اختبار السلامة (Integrity Test)

أبسط اختبار: تحقق من أن الملفات سليمة.

# التحقق من ملف مضغوط
gzip -t backup-2026-03-25.sql.gz

# التحقق من أرشيف tar
tar -tzf backup-2026-03-25.tar.gz > /dev/null

# مقارنة checksums
sha256sum -c backup-checksums.txt

اختبار الاستعادة الجزئي

استعد ملفاً أو جدولاً واحداً وتحقق من صحته:

# استعادة قاعدة بيانات واحدة في بيئة اختبار
mysql -u root test_restore < backup-db.sql

# التحقق من عدد السجلات
mysql -u root -e "SELECT COUNT(*) FROM test_restore.users;"

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

الاختبار الحقيقي: استعد كل شيء على سيرفر اختبار منفصل وشغّل التطبيق.

1. جهّز سيرفر اختبار بنفس المواصفات
2. استعد النظام بالكامل من النسخة الاحتياطية
3. شغّل التطبيق وتأكد من عمله
4. اختبر كل الوظائف الأساسية
5. سجّل الوقت المستغرق للاستعادة الكاملة

جدول الاختبار المُوصى به

نوع الاختبار	التكرار	المدة	المسؤول
اختبار سلامة (checksums)	يومياً (تلقائي)	دقائق	نظام تلقائي
استعادة جزئية (ملف/جدول)	أسبوعياً	30 دقيقة	مدير النظام
استعادة كاملة	شهرياً	2-4 ساعات	فريق تقني
محاكاة كارثة كاملة	ربع سنوي	يوم كامل	الفريق بالكامل

أتمتة الاختبارات

لا تعتمد على الذاكرة. أتمت كل ما يمكن أتمتته:

#!/bin/bash
# test-backup.sh - يعمل يومياً عبر cron

BACKUP_FILE="/backup/latest/db-backup.sql.gz"
TEST_DB="backup_test"
LOG="/var/log/backup-test.log"
DATE=$(date +%Y-%m-%d)

# اختبار سلامة الملف
gzip -t $BACKUP_FILE 2>> $LOG
if [ $? -ne 0 ]; then
 echo "[$DATE] INTEGRITY CHECK FAILED" >> $LOG
 # إرسال تنبيه
 exit 1
fi

# استعادة في قاعدة اختبار
zcat $BACKUP_FILE | mysql $TEST_DB 2>> $LOG
if [ $? -ne 0 ]; then
 echo "[$DATE] RESTORE TEST FAILED" >> $LOG
 exit 1
fi

# التحقق من عدد السجلات
COUNT=$(mysql -sN -e "SELECT COUNT(*) FROM $TEST_DB.users;")
if [ "$COUNT" -lt 1 ]; then
 echo "[$DATE] DATA VALIDATION FAILED" >> $LOG
 exit 1
fi

echo "[$DATE] ALL TESTS PASSED - $COUNT records verified" >> $LOG

# تنظيف
mysql -e "DROP DATABASE IF EXISTS $TEST_DB;"

مقاييس يجب تتبعها

المقياس	الهدف	لماذا
RTO (وقت الاستعادة)	أقل من 4 ساعات	كم تحتاج للعودة للعمل
RPO (نقطة الاستعادة)	أقل من 24 ساعة	كم بيانات تقبل خسارتها
نسبة نجاح الاختبارات	100%	أي فشل يحتاج تحقيق فوري
حجم النسخة مقابل المتوقع	فرق أقل من 10%	انخفاض مفاجئ يعني نسخ ناقص

تجربة كلاود في النسخ الاحتياطي

كلاود يقدم خدمة نسخ احتياطي مُدارة مع مراقبة تلقائية لسلامة النسخ. عملاء الاستضافة المُدارة يحصلون على نسخ يومي وأسبوعي وشهري ضمن الباقة. عملاء الخوادم السحابية يمكنهم إضافة النسخ اليومي باحتفاظ 7 أيام مقابل بأسعار مناسبة — الأسعار والباقات، أو 30 يوماً مقابل بأسعار مناسبة — الأسعار والباقات.

الخلاصة

اختبر نسخك الاحتياطية بانتظام. اجعل الاختبار جزءاً من روتينك الشهري على الأقل. النسخة التي لا تُختبر هي وعد بلا ضمان. والبيانات المفقودة لا تعود.

---

ابدأ الآن

تبي بيئة آمنة لتطبيقاتك؟ اختر سيرفر محمي بحماية DDoS وجدار ناري متقدم. راجع اتفاقية مستوى الخدمة وسياسة الخصوصية.