نسخ restic الاحتياطية: أخرج بياناتك من VPS

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

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

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

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

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

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

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

التشفير افتراضيًا. مستودع 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، بلا صَدَفة دخول) في كل تثبيت، لذا يفشل الأمر 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 النموذج والأذونات وكيفية إبطال مفتاح لاحقًا.

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

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

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

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

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

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

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

كل لقطة تُظهر معرِّفًا ووقتًا والمسارات التي تحتويها. تلك المعرّفات هي ما تستعيد منه.

تشغيل ليلي بمؤقت 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 موعد التشغيلة القادمة. يمكنك أيضًا توليد زوج ملفات الوحدة (unit files) بدل كتابتهما:

النموذج الكامل خلف هذين الملفين، بما فيه صياغة التقويم وتوجيهات التحصين التي قد تحملها خدمة ما، موجود في تشغيل برنامج كخدمة 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%

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

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

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

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

الاحتفاظ: forget زائد prune

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

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

قواعد البيانات: استخرج تفريغًا (dump) أولًا، ثم انسخ التفريغ احتياطيًا

ينسخ 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 أن يسجّل كلمة مرور ثانية للمستودع نفسه، وهذا يمنحك نسخة احتياطية من كلمة المرور نفسها.