نسخ VPS احتياطياً باستخدام Restic إلى خادم آخر

لماذا لا تُعدّ النسخة الاحتياطية الموجودة على الخادم نفسه نسخة احتياطية

Restic أداة مجانية ومفتوحة المصدر للنسخ الاحتياطي. ترسل لقطات مشفّرة ومزالة التكرار من ملفاتك إلى مستودع موجود في مكان آخر: VPS ثانٍ، أو جهاز في المنزل، أو وحدة تخزين كائنات متوافقة مع S3. يشرح هذا الدليل إعدادها على Ubuntu 24.04، بدءاً من التثبيت وإنشاء مستودع عبر SFTP، ثم إجراء أول نسخة احتياطية، وإنشاء مؤقّت systemd ليعمل كل ليلة، وتحديد سياسة الاحتفاظ، وتنفيذ اختبار الاستعادة الذي يثبت أن العملية كاملة تعمل. يجب أن تكون الوجهة جهازاً آخر، لأن النسخة الموجودة على الخادم نفسه ستتوقف مع توقف الخادم.

يحميك وجود دليل backup/ على الخادم الذي تُنسخ ملفاته احتياطياً من شيء واحد فقط: حذف ملف عن طريق الخطأ. لا ينجو هذا الدليل من تعطل القرص، لأنه موجود على القرص نفسه. ولا ينجو من مهاجم يملك صلاحيات root، لأن المهاجم يحذف النسخ أولاً. كما لا ينجو من خطأ في الحساب يؤدي إلى حذف VPS نفسه. تمزح أقل مركز بيانات كفاءة في العالم بشأن ملف tarball باسم backup_final_v2_REAL موجود على المصفوفة نفسها التي تحتوي على البيانات، وتنجح النكتة لأن كثيراً منا نفّذ ذلك فعلاً. القاعدة هي إبقاء النسخة خارج الخادم، وRestic هي الطريقة الأقل إزعاجاً لتطبيقها.

Restic في أربع أفكار

المستودع. المكان الذي يكتب فيه restic. وهو دليل بالتنسيق الخاص بـrestic، ومليء بالبيانات الثنائية المشفّرة، ولا يستطيع قراءته إلا restic. لا تعدّله يدوياً أبداً؛ تعامل معه من خلال أوامر restic وعنوان -r.

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

إزالة التكرار. يقسّم restic الملفات إلى أجزاء محددة المحتوى، ولا يرفع إلا الأجزاء التي لم يرها المستودع من قبل. ترفع النسخة الاحتياطية الأولى كل شيء؛ أما كل تشغيل لاحق فيرفع تقريباً ما تغيّر فقط. إذا تغيّر 50 MB من لقطة ليلية حجمها 20 GB، فستكلّف نحو 50 MB، ولهذا يكون الاحتفاظ بعشرات اللقطات منخفض التكلفة.

التشفير افتراضياً. يكون مستودع restic مشفّراً دائماً باستخدام AES-256، ويحتاج كل أمر إلى كلمة مرور المستودع. لا يرى خادم النسخ الاحتياطي أو موفّر التخزين إلا بيانات ثنائية مشفّرة. والنتيجة الحاسمة هي أن فقدان كلمة المرور يعني فقدان البيانات نهائياً، وهذا مقصود في تصميم النظام. احتفظ بنسخة من كلمة المرور في مكان لا يوجد على هذا الخادم. هذه النقطة مهمة بما يكفي لنتناولها مرتين إضافيتين أدناه.

تثبيت restic على Ubuntu 24.04

sudo apt update && sudo apt install -y restic
restic version

في Ubuntu 24.04، يثبّت هذا الإصدار restic 0.16.4، بينما الإصدار الحالي من المشروع الأصلي هو 0.19.1. يعود هذا الفرق إلى أن إصدار LTS (الدعم طويل الأمد) يثبّت إصدارات حزم البرامج، ولا يشكّل ذلك مشكلة هنا؛ إذ ينفّذ 0.16.4 كل ما يرد في هذا الدليل. إذا أردت أحدث إصدار للاستفادة من تحسينات السرعة، فنزّل الإصدار الرسمي أحادي الملف التنفيذي من صفحة إصدارات restic على GitHub، وفكّ حزمه باستخدام bunzip2، ثم ثبّته في /usr/local/bin/restic؛ لا توجد خطوات أخرى لتثبيت restic.

إنشاء المستودع على خادم آخر عبر SFTP

تحتاج إلى جهاز وجهة. عادةً ما يكون VPS صغيراً ثانياً هو الخيار المناسب، ويكفي أي جهاز يحتوي على خادم SSH ومساحة قرص متاحة. يتحدث Restic عبر SFTP (نقل الملفات عبر SSH)، لذلك لا يحتاج مضيف النسخ الاحتياطي إلى تثبيت أي شيء على الإطلاق. في هذا الدليل، مضيف النسخ الاحتياطي هو 10.0.0.12، والمستخدم اسمه restic. لا تسمِّ هذا المستخدم backup، لأن Ubuntu وDebian يتضمنان حساب نظام محجوزاً باسم backup (uid 34، ومن دون shell لتسجيل الدخول) في كل عملية تثبيت، لذلك يفشل adduser backup ويُنشئ ssh backup@... الملف في nologin.

ستعمل المهمة الليلية بصلاحيات root على الخادم الذي تُنسخ بياناته احتياطياً، لذلك يحتاج root إلى تسجيل الدخول باستخدام مفتاح إلى مضيف النسخ الاحتياطي. أنشئ مفتاحاً مخصصاً من دون عبارة مرور، لأنه لا يوجد شخص لكتابتها عند الساعة 3 صباحاً، ثم انسخه:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

إذا كانت مفاتيح SSH جديدة عليك، يشرح أساسيات إدارة مفاتيح SSH النموذج والصلاحيات وطريقة إبطال مفتاح لاحقاً.

بعد ذلك، كلمة مرور المستودع. أنشئ كلمة مرور قوية واحفظها في ملف لا يقرأه إلا root:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

انسخ كلمة المرور الآن إلى مدير كلمات المرور، قبل المتابعة. إذا تعطل VPS هذا، فسيعيد المستودع مع كلمة المرور كل شيء؛ أما المستودع من دون كلمة المرور فلن يعيد شيئاً.

هيّئ المستودع:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

الوجهة البديلة هي تخزين الكائنات المتوافق مع S3، وهو الخيار المناسب عندما لا تريد تشغيل جهاز ثانٍ. يعمل أي bucket متوافق مع S3 بالطريقة نفسها؛ ولا يتغير إلا العنوان ومتغيرا بيانات الاعتماد:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

كل ما يأتي بعد init متطابق مع الوجهتين. يعرض باقي هذا الدليل عنوان SFTP؛ استبدله بعنوانك.

النسخة الاحتياطية الأولى مع الاستثناءات

انسخ احتياطياً البيانات التي لا يمكنك إعادة تثبيتها، وليس نظام الملفات بالكامل. يعود نظام التشغيل عند إعادة تثبيته، أما إعداداتك وبياناتك فلا تعودان. في VPS نموذجي، يعني ذلك /etc و/home، وأي مسارات تحتفظ فيها تطبيقاتك بحالتها، مثل /srv أو /var/www. استبعد ذاكرات التخزين المؤقت، لأنها كبيرة وتتغير يومياً وتعيد التطبيقات إنشاءها تلقائياً:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

يرفع التشغيل الأول كل شيء، لذلك يستغرق بعض الوقت. شغّل الأمر نفسه مرة أخرى، وسينتهي خلال ثوانٍ، مع الإبلاغ عن تغيّر بعض الملفات وإضافة بضعة MiB، لأن إزالة التكرار ترفع المقاطع الجديدة فقط. اعرض النسخ الموجودة لديك:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

يعرض كل snapshot معرّفاً ووقتاً والمسارات التي يحتوي عليها. ستستخدم هذه المعرّفات لاستعادة البيانات.

تشغيل النسخ الاحتياطي ليلاً باستخدام مؤقّت systemd

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

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

يُشرح سطرا forget وcheck في القسمين التاليين. ننتقل الآن إلى الجدولة: خدمة oneshot تشغّل السكربت، ومؤقّت يشغّلها عند الساعة 03:00 كل ليلة. يتفوّق المؤقّت على سطر cron هنا لأن التنفيذ يُسجَّل في journal، ولأن Persistent=true يشغّل النسخة الاحتياطية الفائتة فور عودة الخادم بعد فترة التوقف.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

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

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

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

فعّل المؤقّت، ثم شغّل الخدمة مرة يدوياً وراقب تنفيذها:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

يعرض systemctl list-timers موعد التنفيذ التالي. ويمكنك أيضاً إنشاء زوج ملفات الوحدات بدلاً من كتابتهما:

يوضّح تشغيل برنامج كخدمة systemd على VPS النمط الكامل وراء هذين الملفين، بما في ذلك صيغة التقويم وتوجيهات التحصين التي يمكن أن تحملها الخدمة.

النسخة الاحتياطية مجرد ادعاء حتى تستعيدها

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

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

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

بما أن المجموعة الفرعية عشوائية في كل مرة، تغطي عمليات التشغيل الشهرية المستودع بأكمله تدريجياً من دون تحمّل تكلفة تنزيله كاملاً.

ثانياً، اختبار الاستعادة. ابقَ في جلسة shell بصلاحيات root من الخطوات السابقة، واستعد دليلاً حقيقياً واحداً من أحدث snapshot إلى موقع مؤقت، ثم قارنه بالملفات الحالية:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

إن عدم طباعة diff لأي شيء يعني أن كل بايت استُعيد مطابقاً تماماً، وهذا هو الدليل الوحيد المهم. احذف /srv/restore-drill بعد ذلك. نفّذ هذا الاختبار شهرياً، ونفّذ الإصدار الكامل مرة أو مرتين سنوياً: استعد أحدث snapshot بالكامل إلى VPS مؤقت، وتحقق من أن تطبيقك يبدأ فعلياً منه. في اليوم الذي تحتاج فيه إلى نجاح هذه العملية تحت الضغط، يجب أن تكون قد نفّذتها مسبقاً حتى تصبح إجراءً روتينياً.

الاحتفاظ: النسيان ثم التنظيف

من دون سياسة، تتراكم اللقطات طوال الوقت ويستمر المستودع في النمو. يطبّق سطر forget في البرنامج النصي سياسة كل ليلة: يحتفظ --keep-daily 7 بلقطة واحدة لكل يوم من آخر سبعة أيام، و--keep-weekly 4 بلقطة واحدة لكل أسبوع لمدة أربعة أسابيع، و--keep-monthly 6 بلقطة واحدة لكل شهر لمدة ستة أشهر. تُنسى كل اللقطات التي لا تحميها قاعدة.

يؤدي forget وحده إلى إزالة سجلات اللقطات فقط؛ أما أجزاء البيانات فتبقى في المستودع إلى أن تحذفها عملية أخرى. هذا ما ينفذه --prune: يبحث عن أجزاء لا تشير إليها أي لقطة متبقية، ثم يحذفها. عندها فقط تستعيد مساحة القرص فعلياً. ينفّذ Prune عمليات فعلية على المستودع، لذلك يشغّل بعض المستخدمين forget كل ليلة و--prune أسبوعياً في المستودعات الكبيرة؛ أما في أحجام VPS المعتادة، فالتشغيل الليلي مناسب.

قواعد البيانات: أنشئ التفريغ أولاً، ثم انسخ التفريغ احتياطياً

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

بالنسبة إلى PostgreSQL، أضف سطر تفريغ في أعلى restic-backup.sh، قبل الأمر restic backup، وأدرج مجلد التفريغ ضمن مسارات النسخ الاحتياطي:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

يؤدي mysqldump الدور نفسه مع MariaDB وMySQL. يوضح قسم النسخ الاحتياطي لـNextcloud النمط كاملاً: يفعّل وضع الصيانة، وينشئ تفريغاً لـPostgres، ثم ينسخ الملفات كمجموعة متسقة واحدة، وهي بالضبط المجموعة التي ينبغي لـrestic إخراجها من الخادم كل ليلة. الفكرة نفسها تنطبق على SQLite باستخدام إجراء أبسط: يوقف دليل Vaultwarden الحاوية لبضع ثوانٍ لإنشاء نسخة باردة من db.sqlite3، ويكون ذلك الأرشيف هو ما ينقله restic خارج الخادم.

FAQ

هل تكون نسخ restic الاحتياطية مشفّرة؟

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

هل ينشئ restic نسخاً احتياطية تزايدية؟

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

كيف أستعيد الملفات من نسخة restic الاحتياطية؟

شغّل restic snapshots للعثور على معرّف اللقطة، ثم restic restore <id> --target /some/empty/dir لاستعادتها، مع إضافة --include /path لاستعادة جزء منها فقط. يعمل latest بدلاً من المعرّف. يعيد restic إنشاء بنية الأدلة الأصلية ضمن الهدف، لذلك تؤدي استعادة /etc/ssh إلى وضع الملفات في /some/empty/dir/etc/ssh. تدرّب على ذلك قبل أن تحتاج إليه، لأن النسخة الاحتياطية غير المختبرة مجرد ادعاء.

كم مرة ينبغي أن أشغّل restic backup؟

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

ماذا يحدث إذا فقدت كلمة مرور مستودع restic؟

تصبح النسخ الاحتياطية غير قابلة للاستعادة. لا يتضمن تشفير restic باباً خلفياً ولا يوفر إعادة تعيين، لذلك تساوي كلمة المرور النسخ الاحتياطية نفسها في الأهمية. احتفظ بنسخة منها في مدير كلمات المرور وفي مكان دائم آخر لا يكون هو الخادم الذي تُنسخ بياناته احتياطياً. ما دمت تملك إمكانية الوصول، يمكن لـrestic key add تسجيل كلمة مرور ثانية للمستودع نفسه، مما يمنحك نسخة احتياطية من كلمة المرور.