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

Restic أم BorgBackup: في فقرة واحدة

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

أما الفروق الأخرى فهي أقل أهمية. يقسّم كلا البرنامجين الملفات باستخدام chunking يحدده المحتوى، لذلك إذا تغيّر 200 MB من دليل حجمه 40 GB، فسيُرفع نحو 200 MB فقط. ويشفّر كلاهما البيانات على العميل. كما يتيح كلاهما mount لـsnapshot باستخدام FUSE ‏(filesystem in userspace)، بحيث يمكنك نسخ ملف واحد منه. اعتباراً من October 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 1.4 المستقرة خلفية S3. فلا توجد عملية يمكن تشغيلها داخل الحاوية. يغيّر Borg 2 ذلك؛ إذ ينقل التخزين إلى طبقة جديدة تُسمى borgstore، وتصف وثائقه عناوين مستودعات sftp:// وrclone:remote:path وs3: أو b2:. لكن Borg 2 لا يزال إصداراً تجريبياً، ويذكر المشروع أنه لا ينبغي استخدامه في بيئات الإنتاج. لذلك لا تزال فجوة 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، أو fastest، أو better، أو max. أُضيف النمطان fastest وbetter في restic 0.19.0، لذلك لا تقبل الإصدارات الأقدم إلا 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 على الطرف البعيد تجيب عن استعلامات الفهرس من دون رحلة ذهاب وإياب عبر الشبكة لكل جزء. ويميل restic إلى التفوق عندما يكون الهدف هو تخزين الكائنات، إذ لا يستطيع Borg المستقر العمل معه إطلاقاً.

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

ليس في السلسلة المستقرة 1.4. يخدم مستودع Borg 1.4 عبر عملية borg serve من خلال SSH، ولا تعمل مثل هذه العملية داخل حاوية تخزين. يضيف Borg 2 عناوين URL للمستودعات باستخدام s3: وb2: وrclone: عبر طبقة borgstore، لكن حتى October 2026 لا يزال Borg 2 في المرحلة التجريبية، ويقول المشروع إنه لا ينبغي استخدامه في بيئة الإنتاج. مع 1.4، يتجاوز المستخدمون هذه الفجوة بتركيب تخزين الكائنات كنظام ملفات باستخدام rclone. تحذّر الأسئلة الشائعة لـBorg من استخدام أنظمة الملفات الشبكية لتخزين المستودعات، وتنبه إلى أن FUSE وأنظمة الملفات الشبكية قد تسبب البطء أو التلف. إذا كنت تحتاج إلى تخزين الكائنات للنسخ الاحتياطية الإنتاجية اليوم، فاستخدم restic.

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

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

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

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

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

لا. حتى October 2026 لا يزال Borg 2.0 في المرحلة التجريبية، في الإصدار 2.0.0b25، الذي صدر في 27 September 2026، ويصنّفه المشروع للاختبار فقط. السلسلة المستقرة هي 1.4، والإصدار الحالي هو 1.4.5. ابدأ باستخدام 1.4 الآن. يغيّر Borg 2 تنسيق المستودع ويقدّم مسار ترقية موثقاً (borg transfer --from-borg1)، لذلك لن يؤدي البدء اليوم إلى حصر استخدامك في الإصدار الحالي. كما أن Borg 2 هو الإصدار الذي يضيف الدعم الأصلي لـS3 وB2 وrclone، بعد أن يصبح مستقراً.