Restic للـ VM: النسخة الاحتياطية لا تكفي بدون Restore Drill

لو عندك VM عليها PostgreSQL وملفات uploads، هتخرج من المقال بخطة نسخ احتياطي قابلة للاسترجاع، مش مجرد فولدر محفوظ ومحدش جربه.

مستوى القارئ: متوسط

المشكلة باختصار

الطريقة الشائعة بتفشل في لحظة الحقيقة: سكربت يعمل backup كل ليلة، يرفع ملف إلى storage، وبعدين الفريق يكتشف وقت العطل إن الملف ناقص أو كلمة المرور مش متوثقة أو الاسترجاع بياخد 40 دقيقة بدل 10.

الافتراض هنا إن عندك VM واحدة أو اتنين، قاعدة PostgreSQL صغيرة إلى متوسطة، وملفات uploads أقل من 200GB. لو عندك Kubernetes كبير أو عشرات قواعد البيانات، هتحتاج orchestration أوسع.

ليه Restic مناسب للحالة دي

Restic بيعمل ثلاث حاجات مهمة: تشفير قبل الرفع، deduplication عشان مايرفعش نفس البيانات كل مرة، وsnapshots تقدر ترجع منها لنقطة زمنية محددة. ركز: قيمة الأداة مش في أمر backup فقط، القيمة في إن restore يبقى قابل للتكرار.

مثال بسيط: لو عندك فولدر uploads فيه 80GB، وأنت بتضيف 2GB يوميًا، أول نسخة ممكن تاخد وقتًا طويلًا. بعد كده Restic يرفع التغييرات فقط. المكسب إن التخزين والوقت يقلوا. الـ trade-off هنا إنك لازم تحافظ على password وrepository config، ولو ضاعوا فالنسخ المشفرة مش هتنفعك.

إعداد عملي قابل للنسخ

ثبت Restic على السيرفر، واستخدم S3-compatible storage مثل AWS S3 أو Backblaze B2 أو MinIO. المثال التالي مبني على S3. غيّر القيم حسب بيئتك.

# 1) متغيرات الاتصال
export AWS_ACCESS_KEY_ID="CHANGE_ME"
export AWS_SECRET_ACCESS_KEY="CHANGE_ME"
export RESTIC_PASSWORD_FILE="/root/.restic-password"
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/my-company-vm-backups/prod-vm-01"

# 2) أول تهيئة للـ repository
restic init

# 3) dump لقاعدة PostgreSQL قبل النسخ
mkdir -p /var/backups/app
sudo -u postgres pg_dump -Fc app_db > /var/backups/app/app_db.dump

# 4) نسخة للـ dump والـ uploads
restic backup /var/backups/app/app_db.dump /var/www/app/uploads

# 5) احتفاظ عملي: يومي 7 أيام، أسبوعي 4 أسابيع، شهري 6 شهور
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

أفضل طريقة تشغّل ده بملف systemd timer بدل cron لو السيرفر عندك systemd. هتكسب logs أوضح وexit status ظاهر. هتخسر بس شوية إعدادات زيادة.

اختبار الاسترجاع هو الجزء المهم

النسخة الاحتياطية من غير restore drill هي وعد غير مختبر. اعمل test شهري على staging أو VM مؤقتة. الهدف مش إنك تسترجع كل شيء كل يوم، الهدف إنك تعرف RTO حقيقي: كام دقيقة لحد ما الخدمة ترجع.

# اعرض آخر snapshots
restic snapshots

# استرجع آخر snapshot في مسار مؤقت
mkdir -p /tmp/restore-test
restic restore latest --target /tmp/restore-test

# جرّب استرجاع PostgreSQL على قاعدة staging
createdb app_restore_test
pg_restore -d app_restore_test /tmp/restore-test/var/backups/app/app_db.dump

# تحقق من عدد الجداول أو سجلات مهمة
psql app_restore_test -c "select count(*) from users;"

في سيناريو موقع عليه 50K زائر يوميًا، وكان عندك dump بحجم 6GB وuploads بحجم 80GB، ممكن تكتشف إن الاسترجاع الكامل بياخد 40 دقيقة. بعد توثيق الخطوات وتجهيز VM staging بنفس الإصدارات، الرقم ممكن ينزل إلى 12 دقيقة. الرقم هنا تقديري، لكنه قابل للقياس عندك بنفس الأوامر.

تشغيل يومي بـ systemd timer

اعمل service صغير يشغل السكربت. خلي السكربت يفشل بصراحة لو pg_dump فشل، بدل ما يرفع نسخة ناقصة.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic backup for app VM

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/app.env
ExecStart=/usr/local/bin/app-restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run Restic backup daily

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

Trade-offs وما يجب الانتباه له

• التشفير: يحميك لو storage اتكشف، لكن فقدان password يعني فقدان النسخ.
• deduplication: يقلل حجم الرفع، لكن أول backup قد يكون بطيئًا.
• Object Storage: رخيص ومتين، لكن egress وقت الاسترجاع ممكن يكلفك.
• pg_dump: بسيط ومناسب لقواعد صغيرة ومتوسطة، لكنه ليس بديلًا دائمًا عن replication أو PITR لقواعد كبيرة.

متى لا تستخدم هذه الطريقة

لا تعتمد على هذا التصميم وحده لو عندك قاعدة أكبر من 200GB وتتطلب استرجاعًا خلال دقائق قليلة. لا تستخدمه كبديل عن high availability. ولا تستخدم pg_dump فقط لو محتاج point-in-time recovery بالدقيقة؛ هنا فكر في WAL archiving أو managed database backups.

مصادر

• Restic Documentation
• Restic forget and retention policy
• PostgreSQL pg_dump documentation
• PostgreSQL pg_restore documentation
• systemd timer documentation

الخطوة التالية

الخطوة التالية: شغّل `restic restore latest --target /tmp/restore-test` هذا الأسبوع، واكتب الرقم الحقيقي لزمن الاسترجاع في README التشغيل. لو الرقم أكبر من RTO المقبول، أصلح الخطة قبل أول عطل.