Restic أم BorgBackup: أيهما تشغّل؟

Restic مقابل BorgBackup، في فقرة واحدة

ينفّذ Restic وBorgBackup المهمة الأساسية نفسها: إنشاء نسخ احتياطية متزايدة ومشفّرة تعتمد على إزالة التكرار لخادم Linux. والاختلاف الحاسم في الاختيار هو مكان تخزين النسخة الاحتياطية. يتعامل Restic أصلاً مع S3 وواجهات برمجة تطبيقات تخزين الكائنات الأخرى، لذلك تكون bucket هدفاً أساسياً من دون تثبيت أي شيء على الطرف الآخر. أما Borg فيحتاج إلى تثبيت برنامج borg على الجهاز الذي يحتوي على المستودع، لأن مستودع Borg يقدّمه process، وليس filesystem أو API. إذا كان هدفك هو تخزين الكائنات، فهذا يحسم الاختيار. وإذا كان هدفك جهاز Linux ثانياً تملكه وتديره، فيمكنك استخدام Borg، وغالباً سيكون أسرع.

أما الفروق الأخرى فأصغر. يقسّم كلا البرنامجين الملفات باستخدام content-defined chunking، لذلك إذا تغيّر 200 MB من مجلد حجمه 40 GB، فسيُرفع نحو 200 MB فقط. ويشفّر كلاهما البيانات على العميل. كما يتيح كلاهما تركيب snapshot باستخدام FUSE (filesystem in userspace)، لكي تتمكن من نسخ ملف واحد منها. اعتباراً من July 2026، إصدار restic هو 0.19.1، والسلسلة المستقرة من Borg هي 1.4، وتحديداً 1.4.5. ظل Borg 2.0 في المرحلة التجريبية لسنوات، وما يزال مصنّفاً للاختبار فقط، لذلك ينبغي أن تنشر الإصدار 1.4 اليوم.

نموذج المستودع هو الفرق الفعلي

مستودع restic هو مجلد من الملفات: config وkeys/ وsnapshots/ وindex/ وdata/، ويحتوي على عدد كبير من ملفات الحزم. لا تحتاج إلى أي شيء آخر لقراءته. لذلك يستطيع restic التعامل مع هذا العدد الكبير من الواجهات الخلفية. فأي مخزن يمكنه وضع الكتل الثنائية واستردادها وسردها وحذفها يمكنه استضافة مستودع restic. ولهذا يدعم ملف تنفيذي واحد المسارات المحلية وSFTP وخادم REST الخاص به وS3 وBackblaze B2 وAzure وGoogle Cloud Storage وكل ما يمكن لـrclone الوصول إليه.

يتكون مستودع Borg أيضاً من ملفات على القرص، لكن Borg لا يتعامل معه عبر ناقل بسيط. بالنسبة إلى المستودع البعيد، يشغّل Borg borg serve في الطرف البعيد عبر SSH، ويتحدث وفق بروتوكوله الخاص مع تلك العملية. ينفّذ جانب الخادم عملاً فعلياً: فهو يحتفظ بالمستودع، ويطبّق المعاملة، ويجيب عن استعلامات الفهرس. ولهذا لا يوفّر Borg واجهة S3 خلفية، كما أن المشروع لم يضف واحدة. فلا توجد عملية يمكن تشغيلها داخل حاوية التخزين.

ينتج عن هذه الحقيقة التصميمية الواحدة معظم الفروق العملية الواردة أدناه.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

التشفير: يمكنك تعطيل أحدهما

يشفّر Restic البيانات دائماً. ولا يوفّر وضعاً غير مشفّر. يطلب restic init كلمة مرور، ويشتق منها مفتاحاً باستخدام scrypt، ثم يشفّر كل ملف pack يُكتب بعد ذلك ويصادق عليه. إذا فقدت كلمة المرور، فقدت البيانات، لأن التصميم لا يوفّر مساراً للاسترداد.

يجعل Borg التشفير خياراً عند إنشاء المستودع، ويصبح هذا الاختيار دائماً. يحتفظ borg init --encryption=repokey بالمفتاح المشفّر داخل المستودع، ولذلك تكفي عبارة المرور للاستعادة. أما --encryption=keyfile فيحتفظ بالمفتاح على العميل داخل ~/.config/borg/keys/، ولذلك لا يستطيع من يسرق المستودع بأكمله فعل شيء بالمحتوى. لكن يجب عليك نسخ ملف المفتاح احتياطياً بشكل منفصل، وإلا فلن تتمكن من قراءة أرشيفاتك. يوفّر كل وضع أيضاً صيغة -blake2، وهي تستخدم BLAKE2b للمصادقة بدلاً من HMAC-SHA256، وتكون أسرع على العتاد الذي لا يوفّر تسريعاً لـSHA. ويتوفر --encryption=none أيضاً، وهو خيار فعلي عندما يكون المستودع موجوداً على قرص مشفّر تملكه.

القاعدة العملية: استخدم repokey-blake2 للنسخ الاحتياطي العادي لخادم، واستخدم keyfile عندما يكون المستودع موجوداً في مكان لا تثق به بالكامل، ولا تستخدم none أبداً على جهاز مستأجر.

الضغط، ولماذا تأخر restic في دعمه

يدعم Borg الضغط منذ البداية. الإعداد الافتراضي هو lz4، وقد اختير لأنه سريع بما يكفي لتركه مفعّلاً لكل شيء. يقبل zstd المستويات من 1 إلى 22، ويكون المستوى الافتراضي 3. يوجد zlib وlzma للحالات التي تكون فيها تقليل وحدات البايت أهم من تقليل الوقت. ويطبّق auto أسلوباً استدلالياً على كل chunk، حتى لا تُضغط البيانات المضغوطة مسبقاً مرة ثانية.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

لم يدعم restic الضغط إطلاقاً حتى الإصدار 2 من تنسيق المستودع، الذي يتطلب restic 0.14.0 أو إصداراً أحدث. أصبح التنسيق 2 هو الإعداد الافتراضي للمستودع الجديد، ويُضبط الضغط باستخدام --compression مع القيم auto أو off أو max. يظل المستودع القديم بالتنسيق 1 غير مضغوط حتى تنقله إلى التنسيق الجديد. لذلك، إذا كان مستودع restic لديك أقدم من 0.14 ولم تنقله، فأنت لا تزال تستهلك الحجم الكامل للنصوص والسجلات ونسخ قواعد البيانات الاحتياطية.

الوجهات البعيدة: S3 مقابل SSH

هنا يُحسم الاختيار عادةً.

يحتاج restic عند الوصول إلى S3 إلى بيانات اعتماد في البيئة، ولا يحتاج إلى تشغيل أي شيء آخر في أي مكان. ينطبق النمط نفسه عند استخدام bucket تستضيفه بنفسك، وهذا اقتران شائع: شغّل MinIO لتوفير واجهة S3 API على VPS تملكه، ثم وجّه restic إليه.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

يحتاج Borg عند الوصول إلى مستودع بعيد إلى SSH، وإلى تثبيت Borg على الطرف البعيد. كما يشترط توافق الإصدار هناك مع إصدار العميل. يسبب ذلك تعقيداً إذا لم تكن تدير الطرف البعيد. لكنه لا يسبب مشكلة إذا كان الطرف البعيد خادماً ثانياً تديره مسبقاً. وفي هذه الحالة تحصل على أقوى حماية من برمجيات الفدية يوفرها أي من الأداتين: مفتاح SSH يسمح بالإضافة فقط. أَجبر المفتاح على تشغيل borg serve، فيستطيع العميل إضافة الأرشيفات لكنه لا يستطيع حذفها. لذلك لا يستطيع جهاز مخترق محو سجله السابق.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

يوفر restic آلية مكافئة فقط عند تشغيل REST server الخاص به، إذ يدعم وضع الإضافة فقط. أما مع S3 العادي، فتحصل على التأثير نفسه باستخدام سياسة bucket أو object lock. هذه مسؤولية مزود الخدمة وليست مسؤولية restic. أمّن قناة النقل أيضاً، لأن جانب SSH هنا يحتاج إلى العناية نفسها التي يحتاج إليها أي تسجيل دخول آخر: طبّق استخدام SSH بالمفاتيح فقط مع تقييد إدخال authorized_keys على حساب النسخ الاحتياطي.

السرعة: ما الذي يعنيه كل تصميم

لا ينشر أي من المشروعين معيار أداء يمكنك الوثوق به لبياناتك أنت، لذلك استنتج الأداء من الآلية بدلاً من ذلك.

يكون Borg عبر SSH سريعاً على اتصال ذي زمن استجابة مرتفع لأن جانب الخادم يتولى المعالجة بذكاء. يرسل العميل استعلاماً، وتجيب عملية borg serve البعيدة عنه باستخدام فهرس المستودع، ثم تُثبَّت المعاملة في مكان واحد. ولا تتحول عمليات البحث عن القطع إلى جولات ذهاب وإياب عبر الشبكة لكل ملف صغير.

لا يحتوي restic على جانب خادم عند استخدام تخزين الكائنات، لذلك يبني صورته من ملفات الفهرس وملفات الحزم التي يجلبها عبر HTTP. وللحفاظ على عدد الطلبات ضمن حدود معقولة، يجمع العديد من القطع الصغيرة في ملفات حزم أكبر قبل رفعها، ويحتفظ بذاكرة تخزين مؤقت محلية في ~/.cache/restic حتى لا يعيد التشغيل التالي جلب الفهرس بأكمله. إذا حذفت ذاكرة التخزين المؤقت، فستكون عملية النسخ الاحتياطي التالية بطيئة أثناء إعادة بنائها. على اتصال ذي زمن استجابة مرتفع ومع ملايين الملفات الصغيرة، يكون هذا هو السيناريو الذي يبدو فيه restic أبطأ من Borg عند استخدام البيانات نفسها.

على قرص محلي أو شبكة LAN سريعة، يتقلص الفرق غالباً، وينتهي الأمر بالأداتين إلى الاعتماد على سرعة قراءة المصدر وحساب التجزئة له.

قفل عدة أجهزة وإجراء نسخ احتياطية لها

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

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

الاحتفاظ: forget ثم prune، مقابل prune ثم compact

تفصل الأداتان بين «تحديد ما يجب الاحتفاظ به» و«استعادة المساحة»، وتطلب كلتاهما منك تنفيذ الخطوة الثانية.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

المشكلة واحدة في الأداتين، ومن المهم توضيحها. في Borg، يزيل borg prune الأرشيفات، لكنه لا يحرر مساحة القرص بحد ذاته. تعود المساحة عند تشغيل borg compact. لذلك، تترك مهمة cron التي تنفّذ prune ولا تنفّذ compact مستودعاً يزداد حجمه باستمرار، بينما تبقى قائمة الأرشيفات قصيرة. في restic، يؤدي forget من دون --prune إلى حذف مراجع اللقطات فقط، وتبقى البيانات إلى أن تُشغّل prune.

شغّل restic check بعد pruning. يتحقق ذلك من بنى المستودع ويخبرك إذا كان شيء ما تالفاً. وهذا أفضل بكثير من اكتشاف التلف أثناء الاستعادة.

الاستعادة هي الاختبار الوحيد المعتمد

تتيح لك الأداتان تركيب لقطة حتى تتمكن من تصفحها. وهذه أسرع طريقة لاستعادة ملف واحد.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

انتبه إلى صيغة المسار في borg extract. تُخزَّن المسارات داخل الأرشيف من دون الشرطة المائلة الأولى، لذلك فإن etc/nginx صحيح، بينما لا يطابق /etc/nginx أي شيء ولا يستخرج شيئاً، من دون ظهور خطأ يوضح السبب. تكتب عملية الاستخراج أيضاً الملفات في دليل العمل الحالي، لذلك انتقل أولاً إلى دليل مؤقت، وإلا فستستبدل الملفات الحية بملفات قديمة.

لا تثبت الاستعادة التي تكتمل من دون خطأ نجاحها، لأن التطبيق نفسه يحدد ما تعنيه الاستعادة الكاملة. قد يعود خادم Immich أُعيد بناؤه من نسخة من دليل بيانات Postgres مع وجود جميع الصور على القرص، لكن من دون أي عناصر في المخطط الزمني. وهذا هو الفشل الذي يجب أن تتعامل معه نسخ Immich احتياطياً واستعادته.

أيّاً كانت الأداة التي تختارها، فالجدولة لا تمثل سوى نصف المهمة. نفّذ عملية استعادة في دليل مؤقت وفق مؤقت تراقبه فعلياً، بالطريقة نفسها التي يوضحها الدليل الكامل في دليل النسخ الاحتياطي باستخدام restic لخادم VPS عبر مؤقت systemd.

ما الأداة الأنسب لكل مهمة

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

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

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

FAQ

هل restic أسرع أم BorgBackup؟

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

هل يستطيع BorgBackup إجراء نسخ احتياطي إلى S3 أو Backblaze B2؟

ليس مباشرة. يقدّم عملية borg serve مستودع Borg عبر SSH، ولا تعمل مثل هذه العملية داخل bucket. يعالج بعض المستخدمين ذلك بتركيب تخزين الكائنات كنظام ملفات باستخدام rclone، لكن مشروع Borg لا يوصي بهذا الأسلوب، لأن mount ينقطع في منتصف معاملة قد يتسبب في تلف المستودع. إذا كنت تحتاج إلى تخزين الكائنات، فاستخدم restic.

هل يمكنني تشغيل الأداتين على البيانات نفسها؟

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

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

تصبح البيانات غير قابلة للاستعادة في كلتا الأداتين. يشتق restic مفتاحه من كلمة المرور باستخدام scrypt، ولا توجد طريقة لتجاوز ذلك. في وضع repokey، يخزّن Borg المفتاح المشفّر داخل المستودع، لذلك تكفي عبارة المرور للاستعادة، أما في وضع keyfile فتحتاج أيضاً إلى ملف المفتاح من ~/.config/borg/keys/. احتفظ بكلمة المرور في مدير كلمات مرور لا يوجد على الخادم الذي تجري له النسخ الاحتياطي، وصدّر مفتاح Borg باستخدام borg key export إذا كنت تستخدم keyfile.

هل ينبغي أن أنتظر Borg 2.0؟

لا. اعتباراً من July 2026، لا يزال Borg 2.0 في مرحلة beta، وتحديداً الإصدار 2.0.0b22، ويصنّفه المشروع للاختبار فقط. السلسلة المستقرة هي 1.4، والإصدار الحالي هو 1.4.5. ابدأ باستخدام 1.4 الآن. يغيّر Borg 2 تنسيق المستودع ويوفّر مسار ترقية موثقاً، لذلك لن يؤدي البدء اليوم إلى حصر استخدامك في الإصدار الحالي.