النسخ الاحتياطي والاسترجاع

النسخ الاحتياطي والاسترجاع

النسخة الاحتياطية ليست ملفاً موجوداً فقط. هي قدرة مثبتة على الاسترجاع. قبل migration أو حذف أو تعديل واسع، يجب أن تعرف أين النسخة وكيف تعود منها. في SQLite، النسخ يحتاج انتباهاً إذا كانت القاعدة نشطة وWAL مستخدم.

لا تنفذ تغييرات إنتاجية خطرة بناءً على ثقة عامة. خذ نسخة، تحقق من حجمها، وسجل وقتها، واعرف أمر الاسترجاع. هذه عادات تشغيلية لا تقل أهمية عن SQL نفسه.

أوامر النسخ الاحتياطي الحقيقية

الطريقة 1 — .backup عبر sqlite3 CLI (تعمل على أي إصدار):

sqlite3 production.db ".backup '/backups/$(date +%Y%m%d).db'"

هذا الأمر يأخذ نسخة آمنة من قاعدة بيانات نشطة لأنه يستخدم SQLite backup API الداخلية التي تتعامل مع WAL بشكل صحيح.

الطريقة 2 — VACUUM INTO (SQLite 3.27+ / 2019):

sqlite3 production.db "VACUUM INTO '/backups/$(date +%Y%m%d).db'"

ينتج ملفاً مضغوطاً ومنظفاً. مفيد لتقليص حجم النسخة. يعمل أيضاً على قواعد البيانات النشطة.

الطريقة 3 — نسخ الملف مباشرة (خطرة بدون checkpoint):

# احرص أولاً على دمج WAL في الملف الرئيسي
sqlite3 production.db "PRAGMA wal_checkpoint(TRUNCATE);"

# الآن يمكن نسخ الملف بأمان
cp production.db /backups/backup-$(date +%Y%m%d).db

لماذا الـ checkpoint ضروري؟ في وضع WAL، التغييرات تُكتب في ملف مؤقت (production.db-wal). نسخ .db وحده بدون WAL يعني نسخة ناقصة لا تحتوي الكتابات الأخيرة.

تحقق من النسخة واختبر الاسترجاع

# تحقق من سلامة النسخة
sqlite3 /backups/20260503.db "PRAGMA integrity_check;"
# يجب أن يُرجع: ok

# تدريب الاسترجاع (في بيئة اختبار):
# 1. أعِد تسمية النسخة كاسم قاعدة البيانات الأصلية
# 2. أعِد تشغيل التطبيق
# 3. تحقق من سلامة البيانات

القاعدة بسيطة: نسخة قبل تغيير غير قابل للتراجع بسهولة.

لا تختبر الاسترجاع أول مرة وقت الأزمة

الاسترجاع يجب أن يكون معروفاً قبل الحادث. النسخة التي لم تُختبر قد تكون وهماً.