Restic أم BorgBackup: أيهما تختار للنسخ الاحتياطي؟

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

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

أما الفروق الأخرى فهي أصغر. يقسم كلا البرنامجين الملفات باستخدام تجزئة تحددها المحتويات، ولذلك فإن دليلاً حجمه 40 GB تغير منه 200 MB سيرفع نحو 200 MB. ويشفر كلاهما البيانات على جهاز العميل. كما يتيح كلاهما تحميل لقطة باستخدام FUSE (filesystem في مساحة المستخدم)، بحيث يمكنك نسخ ملف واحد منها. اعتباراً من July 2026، إصدار restic هو 0.19.1، والسلسلة المستقرة من Borg هي 1.4، وبالتحديد 1.4.5. ظل Borg 2.0 في مرحلة beta لسنوات، ولا يزال موسوماً بأنه للاختبار فقط، ولذلك يجب أن تنشر الإصدار 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 فيطبّق خوارزمية استدلالية على كل كتلة، لذلك لا يُضغط المحتوى المضغوط مسبقًا مرة ثانية.

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 إلى بيانات اعتماد في البيئة، ولا يحتاج إلى تشغيل أي شيء آخر في أي مكان. ويعمل النمط نفسه مع حاوية تستضيفها بنفسك. وهذا اقتران شائع: شغّل 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 الخاص به، إذ يدعم وضع الإضافة فقط. أما مع S3 العادي، فتحصل على النتيجة نفسها باستخدام سياسة الحاوية أو قفل الكائنات. وهذه مسؤولية موفر الخدمة وليست مسؤولية restic. أمّن قناة النقل أيضًا، لأن جانب SSH هنا يحتاج إلى العناية نفسها التي يحتاج إليها أي تسجيل دخول آخر: طبّق SSH باستخدام المفاتيح فقط مع إدخال مقيد في authorized_keys على حساب النسخ الاحتياطي.

السرعة: ما الذي يترتب على كل تصميم

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

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

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

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

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

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

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

الاحتفاظ: النسيان ثم التشذيب، مقابل التشذيب ثم الضغط

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

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 التي تنفذ التشذيب ولا تنفذ الضغط مستودعًا يزداد حجمه باستمرار، بينما تبقى قائمة الأرشيفات قصيرة. في restic، يؤدي تشغيل forget من دون --prune إلى إسقاط مراجع اللقطات فقط، وتبقى البيانات حتى تنفيذ التشذيب.

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

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

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

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 أي شيء ولا يستخرج شيئًا، من دون ظهور خطأ يوضح السبب. تكتب عملية الاستخراج الملفات أيضًا في دليل العمل الحالي، لذلك انتقل أولًا إلى دليل مؤقت، وإلا فستستبدل الملفات الحية بملفات قديمة.

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

أيهما يفوز في كل مهمة

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

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

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

FAQ

أيهما أسرع، restic أم BorgBackup؟

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

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

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

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

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

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

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

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

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