النسخ الاحتياطي والتعافي من الكوارث

النسخ الاحتياطي لخادم لينكس باستخدام restic إلى تخزين كائنات متوافق مع S3

نسخ احتياطية مشفرة وخالية من التكرار عبر restic إلى حاوية متوافقة مع S3: إعداد المستودع، الاحتفاظ، فحص السلامة، الاستعادة والجدولة.

تاريخ النشر
مدة القراءة
7 دقائق
الكاتب
SKYLINE Engineering

أداة restic برنامج نسخ احتياطي مفتوح المصدر يشفّر البيانات على الخادم نفسه قبل رفعها، ويحفظ لقطات (snapshots) خالية من التكرار داخل مستودع يمكن أن يكون أي حاوية متوافقة مع S3. يشرح هذا الدليل تثبيت restic على خادم Debian أو Ubuntu، وتنفيذ أول نسخة، وضبط سياسة الاحتفاظ وفحص السلامة، واختبار الاستعادة، ثم أتمتة العملية بمؤقت systemd.

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

قبل البدء

  • حاوية ومفتاح وصول لدى مزوّد تخزين الكائنات، ويُفضّل مفتاح صلاحياته مقصورة على هذه الحاوية وحدها لا على الحساب كله.
  • عنوان نقطة الاتصال الخاص بالمزوّد، مثل https://s3.example.com.
  • إصدار معروف من restic. أحدث إصدار من المشروع هو 0.19.1 (5 يوليو 2026)، بينما يوفّر أرشيف Debian الإصدار 0.18.0 في Debian 13 (trixie) والإصدار 0.14.0 في Debian 12 (bookworm). الأوامر أدناه أساسية ومأخوذة من التوثيق الحالي، فإن كان إصدارك أقدم فتحقق من الخيارات عبر restic help <command>. الملفات التنفيذية الرسمية تُحدَّث بالأمر restic self-update، أما الحزمة المثبتة عبر apt فتُحدَّث عبر apt.
sudo apt update
sudo apt install restic
restic version

احفظ الأسرار بطريقة صحيحة

يحتاج restic إلى سرّين: كلمة مرور المستودع التي تُشفَّر بها البيانات، وبيانات اعتماد الحاوية. احفظهما في ملفات لا يقرؤها إلا المستخدم root، لا في سجل الأوامر ولا داخل السكربتات. والتوثيق صريح في أمر كلمة المرور: ضياعها يعني ضياع البيانات بلا رجعة، فاحتفظ بنسخة منها في مدير كلمات المرور أو في مكان آمن خارج الخادم.

sudo install -d -m 700 /etc/restic
sudo sh -c 'head -c 32 /dev/urandom | base64 > /etc/restic/password'
sudo chmod 600 /etc/restic/password

بعد ذلك أنشئ الملف /etc/restic/env بصلاحية 600 يتضمن موقع المستودع وبيانات الاعتماد؛ إذ يقرأ restic المتغيرين RESTIC_REPOSITORY وRESTIC_PASSWORD_FILE، وتقرأ واجهة S3 المتغيرين المعتادين AWS_ACCESS_KEY_ID وAWS_SECRET_ACCESS_KEY:

RESTIC_REPOSITORY=s3:https://s3.example.com/my-server-backups
RESTIC_PASSWORD_FILE=/etc/restic/password
AWS_ACCESS_KEY_ID=your-access-key
AWS_SECRET_ACCESS_KEY=your-secret-key

مع نقاط الاتصال غير التابعة لأمازون يستخدم restic أسلوب المسار (path-style) افتراضياً. وإذا تطلّب المزوّد تحديد منطقة فاضبط AWS_DEFAULT_REGION أو مرّر -o s3.region=...، وإلا افترض restic المنطقة us-east-1.

إنشاء المستودع وتنفيذ أول نسخة

حمّل الملف في جلسة root وأنشئ المستودع مرة واحدة:

sudo -i
set -a; . /etc/restic/env; set +a
restic init
restic backup --one-file-system --exclude-caches /etc /home /var/www /var/backups
restic snapshots

الخيار --one-file-system يمنع restic من الدخول إلى أنظمة ملفات أخرى مركّبة، والخيار --exclude-caches يتجاوز المجلدات التي تحمل الملف CACHEDIR.TAG، ويمكنك إضافة --exclude-file=/etc/restic/excludes لأنماط الاستبعاد الخاصة بك. التشغيل الأول يرفع كل شيء، والتشغيلات التالية ترفع ما تغيّر فقط.

لا تعتمد على نسخ مجلد البيانات الحي لـ MySQL أو MariaDB أو PostgreSQL، بل صدّر قواعد البيانات إلى ملف أولاً (في /var/backups مثلاً) ودع restic ينسخ ملف التصدير. وانتبه لرمز الخروج: يعيد restic القيمة 0 عند النجاح و1 عند الفشل و3 حين يتعذر عليه قراءة بعض بيانات المصدر، أي أن اللقطة ناقصة.

سجل احتفاظ معقول: forget ثم prune

حذف اللقطات القديمة في restic خطوتان: الأمر forget يحذف اللقطات وفق سياسة تحددها، والأمر prune يحذف البيانات التي لم تعد تشير إليها أي لقطة، والخيار --prune يجمع الخطوتين. جرّب السياسة أولاً مع --dry-run:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --dry-run
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

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

تأكد من أن البيانات موجودة فعلاً

الأمر restic check وحده يفحص بنية المستودع، لكنه لا ينزّل ملفات البيانات ويتحقق منها كلها إلا إذا طلبت ذلك، لأن هذا يعني قراءة المستودع بالكامل. والحل العملي أن تفحص جزءاً من البيانات كل أسبوع وتدور على الأجزاء كلها:

restic check
restic check --read-data-subset=1/5
# next week 2/5, then 3/5 ... 5/5

الاستعادة، والتدرّب عليها

اعرض اللقطات والملفات، ثم استعد إلى مجلد فارغ لا فوق النظام الحي:

restic snapshots
restic ls latest /etc/nginx
restic restore latest --target /tmp/restore-test --include /etc/nginx
restic restore latest --target /tmp/restore-test --dry-run --verbose=2

الخيار --delete في أمر الاستعادة يحذف من المجلد الهدف كل ملف غير موجود في اللقطة، فلا تستخدمه إلا بعد تجربة --dry-run، ولا توجّهه إلى مجلد حي دون تفكير.

الأتمتة بمؤقت systemd

الخدمة من نوع oneshot يمكنها تنفيذ عدة أسطر ExecStart= بالترتيب، وإذا فشل أحدها لا تُنفَّذ البقية وتُعَدّ الوحدة فاشلة، وهذا ما نريده هنا. أنشئ الملف /etc/systemd/system/restic-backup.service (وعدّل مسار restic بحسب ناتج command -v restic):

[Unit]
Description=restic backup to object storage
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
Nice=10
IOSchedulingClass=idle
ExecStart=/usr/bin/restic backup --one-file-system --exclude-caches /etc /home /var/www /var/backups
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

ثم الملف /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Daily restic backup

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

[Install]
WantedBy=timers.target

الإعداد Persistent=true يعوّض التشغيل الذي فات أثناء إطفاء الخادم. فعّل المؤقت، وشغّل الخدمة يدوياً مرة، ثم راجع السجل:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 50

اربط حالة الفشل بنظام التنبيه الذي تستخدمه؛ فمهمة نسخ تفشل بصمت شهراً كاملاً هي أكثر ما يخذل أصحاب هذه الإعدادات.

أخطاء شائعة

  • نسخة واحدة من كلمة المرور: إن كانت على الخادم وحده وفُقد الخادم، فُقدت النسخ معه.
  • بيانات اعتماد قادرة على حذف كل شيء: المفتاح الموجود على الخادم يستطيع حذف المستودع، وكذلك من يسيطر على الخادم. حيث يدعم المزوّد ذلك، يحدّ تفعيل الإصدارات (Versioning) أو قفل الكائنات (Object Lock)، أو نسخة ثانية يأخذها جهاز آخر، من هذا الخطر.
  • نسخ ملفات قواعد البيانات الحية بدلاً من ملفات التصدير.
  • عدم الاستعادة أبداً: نجاح check مؤشر جيد، لكن الاستعادة الفعلية وحدها تثبت أنك قادر على استرجاع بياناتك وإعداداتك.

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

  1. أنشئ حاوية مخصصة ومفتاحاً مقصوراً عليها، واحفظ كلمة مرور restic في مكانين آمنين.
  2. جهّز المستودع ونفّذ أول نسخة تشمل ملفات تصدير قواعد البيانات، وتحقق منها عبر restic snapshots.
  3. أضف سياسة احتفاظ عبر forget --prune بعد تجربتها مع --dry-run.
  4. جدول النسخ بمؤقت systemd واربط الفشل بالتنبيهات.
  5. شغّل restic check بانتظام، واستعد عينة من الملفات إلى مجلد تجريبي مرة في الشهر على الأقل.

المصادر

SKYLINE Engineering

@skyline

The engineering team at SKYLINE Industrial Solutions. We publish field-tested guides drawn from real KSA and GCC deployments.

صفحة الكاتب
SKYLINE engineering services

Need this implemented for you?

Reading is free — building it right takes a team. SKYLINE engineers ship Backup & Disaster Recovery for Aramco vendors, banks, hospitals and government agencies across Saudi Arabia. Talk to us before you start.

Aramco Approved Contractor ISO 9001 · ISO 27001 SAMA CSF aligned NCA ECC ready 247+ KSA clients

Comments

0 total · 0 threads
Be the first to leave a comment.