> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # أي أداة نسخ احتياطي Backup تناسب سيرفرك؟ - URL: https://arabroot.io/articles/restic-أم-borg-أم-kopia/ - Published: 2026-10-08T07:15:00.000Z - Updated: 2026-10-09T13:02:39.000Z - Description: مقارنة عملية لأشهر أدوات النسخ الاحتياطي مفتوحة المصدر على البيانات نفسها في الوقت والحجم والذاكرة، لتعرف أيها يناسب سيرفرك. - Author: فريق عرب رووت - Tags: الأدلة التقنية, DevOps والتشغيل, التشغيل والنسخ الاحتياطي, الاستضافة الذاتية في [النسخ الاحتياطي بقاعدة 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/) شرحنا ال RPO وال RTO وحماية النسخ من برامج الفدية Ransomware واختبار الاستعادة، واستخدمنا في التجربة restic، ولكن من يبحث عن أداة نسخ احتياطي مفتوحة المصدر لسيرفر Linux سوف يجد ثلاثة أسماء تتكرر في كل نقاش: restic وBorg وKopia، والثلاث تشفر النسخ وتزيل التكرار Deduplication وتحتفظ بنسخ كثيرة في مساحة صغيرة، فما الفرق الحقيقي بينها؟ والإجابة لا تأتي من جداول المزايا على مواقعها، وإنما من تشغيلها على البيانات نفسها وقياس ما يحدث. [![](https://arabroot.io/content/images/2026/10/backup-321-cover-cover.webp)دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/) وسوف نناقش في هذا المقال ما يلي: - الفكرة المشتركة بين الأدوات الثلاث: التقسيم بحسب المحتوى وإزالة التكرار والتشفير. - أين تحفظ كل أداة مستودعها، وهذا غالباً ما يحسم الاختيار. - تجربة عملية على مجموعة بيانات واحدة من 572 ميجابايت: النسخة الأولى، والنسخة دون تغيير، والنسخة بعد تغيير حقيقي، ونسخة مجلد مكرر، والاستعادة، والفحص الكامل، بالوقت والذاكرة وحجم المستودع. - كل أداة على حدة: التثبيت والأوامر الأساسية ونقاط القوة ونقاط الضعف والرخصة. - التشفير والحماية من الحذف في كل أداة، ثم أي أداة تختار لكل حالة. ## الفكرة المشتركة: الملف أجزاء، وكل جزء يحفظ مرة واحدة الأدوات الثلاث لا تنسخ الملفات كما هي، وإنما تقسم كل ملف إلى أجزاء Chunks بطول متغير، وتحسب لكل جزء بصمة Hash، ثم تحفظ في المستودع Repository كل جزء لم تره من قبل، أما الجزء الذي تعرفه بصمته فتكتفي بالإشارة إليه. والنقطة المهمة أن حدود الأجزاء تتحدد بحسب محتوى الملف وليس كل عدد ثابت من البايتات، وهذا ما نسميه التقسيم بحسب المحتوى Content-Defined Chunking، والصورة التالية تبين لماذا يهم ذلك: ![ثلاثة صفوف من الأجزاء: ملف shop.sql يوم الاثنين مقسوم إلى ستة أجزاء خضراء A إلى F، ويوم الثلاثاء بعد إضافة عشرة آلاف سطر في الوسط يتغير جزء واحد فقط C إلى C برتقالي والباقي رمادي معروف، ونسخة مطابقة من المجلد كلها رمادية لا تضيف شيئاً، والمستودع في اليمين يحفظ كل جزء مرة واحدة](https://arabroot.io/content/images/2026/10/backup-tools-compare-01-chunking.webp) الإضافة في وسط الملف تغير جزءاً واحداً، والنسخة المطابقة لا تضيف شيئاً لو كانت الأجزاء بطول ثابت، لكانت إضافة سطر واحد في بداية الملف تزيح كل الأجزاء بعده فتبدو كلها جديدة، أما مع التقسيم بحسب المحتوى فلا يتغير إلا الجزء الذي وقعت فيه الإضافة، وهذا ما يجعل نسخة يومية لقاعدة بيانات كبيرة لا تضيف إلا قليلاً. وفوق ذلك تشفر الأدوات الثلاث الأجزاء قبل أن تخرج من السيرفر، فالمخزن الذي تحفظ فيه، سواء كان قرصاً أو S3 أو سيرفراً عند مزود، لا يرى إلا بيانات مشفرة. ## أين تحفظ كل أداة مستودعها؟ الفرق الأكبر بين الأدوات ليس في طريقة إزالة التكرار، وإنما في المكان الذي تستطيع أن تكتب فيه، كما تبين الصورة التالية: ![ثلاثة أعمدة: restic بلغة Go برخصة BSD-2-Clause تكتب إلى مجلد محلي وSFTP وREST server وS3 وB2 وAzure وGCS وأي مخزن عبر rclone دون سيرفر على الهدف، وBorg 1.4 بلغة Python وC برخصة BSD-3-Clause تكتب إلى مجلد محلي أو عبر SSH مع borg serve على الهدف، وKopia بلغة Go برخصة Apache-2.0 مع واجهة سطر أوامر وواجهة مكتبية وويب تكتب إلى مجلد وSFTP وS3 مع Object Lock وB2 وAzure وGCS وGoogle Drive وWebDAV وrclone وسيرفر Kopia](https://arabroot.io/content/images/2026/10/backup-tools-compare-02-tools.webp) restic وKopia تكتبان إلى خدمات تخزين كثيرة مباشرة، وBorg 1.4 يحتاج مجلداً محلياً أو Borg يعمل على السيرفر الهدف في الصورة أعلاه لاحظ التالي: - **restic** تدعم بحسب [توثيق إنشاء المستودع](https://restic.readthedocs.io/en/stable/030%5Fpreparing%5Fa%5Fnew%5Frepo.html?ref=arabroot.io) المجلد المحلي وSFTP وREST Server وS3 والمخازن المتوافقة معه وBackblaze B2 وAzure وGoogle Cloud Storage، وأي خدمة أخرى عبر rclone، ولا تحتاج أن تثبت شيئاً على المخزن. - **Borg 1.4** يكتب إلى مجلد محلي، أو إلى سيرفر آخر عبر SSH بشرط أن يكون Borg مثبتاً عليه كما في [دليل البداية](https://borgbackup.readthedocs.io/en/stable/quickstart.html?ref=arabroot.io)، فلا يكتب إلى S3 مباشرة، ومن يريد ذلك ينسخ المستودع بأداة أخرى مثل rclone، أو يستخدم مزوداً يقدم Borg عبر SSH. - **Kopia** تدعم بحسب [صفحة المستودعات](https://kopia.io/docs/repositories/?ref=arabroot.io) المجلد المحلي أو الشبكي وSFTP وS3 والمتوافق معه وAzure وB2 وGoogle Cloud Storage وGoogle Drive وWebDAV وrclone، ولها سيرفر خاص بها يتصل به أكثر من جهاز. ## كيف قمنا بالمقارنة شغلنا الأدوات الثلاث داخل Container واحد من Debian 13، على الجهاز نفسه، وعلى البيانات نفسها، وفي كل مرحلة شغلنا الأدوات واحدة بعد الأخرى على الحالة نفسها من البيانات، فالأرقام التالية للمقارنة بين الأدوات على هذا الجهاز فقط، وليست أرقاماً تتوقعها على سيرفرك. والجهاز معالج Intel Core i7-7700K بثماني أنوية منطقية Logical Cores و32 جيجابايت ذاكرة داخل WSL2، والمستودعات على قرص محلي، أي أنه لا توجد شبكة بين الأداة والمستودع. ثبتنا الأدوات من ملفاتها الرسمية على GitHub، ولكل أداة قسم فيه أمر التثبيت لاحقاً: ```text restic 0.19.1 compiled with go1.26.4 on linux/amd64 borg 1.4.5 0.23.1 build: 72ec08fd8edb86c67ed27099bf1b955e1f308ffa from: kopia/kopia ``` ومجموعة البيانات تشبه سيرفر تطبيق حقيقياً، 5117 ملفاً بحجم 572 ميجابايت: - **كود مصدري:** مجلد Python-3.13.7 من [موقع Python الرسمي](https://www.python.org/downloads/source/?ref=arabroot.io)، آلاف الملفات النصية الصغيرة، قرابة 115 ميجابايت. - **تفريغ قاعدة بيانات:** ملف `shop.sql` بصيغة SQL نصية من PostgreSQL 18.6، فيه 202 ألف طلب و1.5 مليون حدث، بحجم 143.5 ميجابايت. - **صور:** 300 ملف بيانات عشوائية بأحجام بين 300 و1800 كيلوبايت، قرابة 308 ميجابايت، وهي لا تضغط مثل صور JPEG الحقيقية. والسكربت التالي هو ما شغلناه في كل مرحلة، حيث يقيس الوقت وأعلى استهلاك للذاكرة بالأداة `/usr/bin/time`، ويقرأ الملفات كلها قبل كل أداة حتى تكون في ذاكرة النظام Page Cache للجميع: ```bash #!/usr/bin/env bash # Same dataset, same machine, one tool after the other at every stage set -uo pipefail export RESTIC_REPOSITORY=/repos/restic RESTIC_PASSWORD=bench-pass-123 export BORG_REPO=/repos/borg BORG_PASSPHRASE=bench-pass-123 export KOPIA_PASSWORD=bench-pass-123 KOPIA_CHECK_FOR_UPDATES=false T() { /usr/bin/time -f "%e s, peak RAM %M KB" "$@"; } size() { du -sm /repos/$1 | cut -f1; } warm() { find /src -type f -exec cat {} + > /dev/null; } run() { # $1 = label for tool in restic borg kopia; do warm case $tool in restic) out=$( { T restic backup --quiet /src; } 2>&1 | tail -1 );; borg) out=$( { T borg create /repos/borg::"$1" /src; } 2>&1 | tail -1 );; kopia) out=$( { T kopia snapshot create /src >/dev/null; } 2>&1 | tail -1 );; esac printf "%-10s %-7s %-32s repo %5s MiB\n" "$1" "$tool" "$out" "$(size $tool)" done } case "${1:-}" in init) restic init >/dev/null && echo "restic: repository created" borg init --encryption=repokey /repos/borg && echo "borg: repository created" kopia repository create filesystem --path /repos/kopia >/dev/null 2>&1 && echo "kopia: repository created" ;; *) run "$1";; esac ``` في السكربت أعلاه لاحظ التالي: - كل أداة بإعداداتها الافتراضية مع التشفير: restic تشفر دائماً، وBorg بالوضع `repokey` الذي يوصي به [توثيق borg init](https://borgbackup.readthedocs.io/en/stable/usage/init.html?ref=arabroot.io) كقاعدة عامة، وKopia بخوارزميتها الافتراضية. - كلمات المرور في متغيرات البيئة للتجربة فقط، أما على السيرفر فاقرأها من ملف صلاحياته `600` بالمتغيرات `RESTIC_PASSWORD_FILE` و`BORG_PASSCOMMAND` و`KOPIA_PASSWORD` من مدير الأسرار. ## النتائج ### النسخة الأولى، ثم نسخة دون أي تغيير ```bash bench.sh init bench.sh first bench.sh unchanged bench.sh unchanged2 ``` والمخرج سوف يكون كما يلي: ```text first restic 36.74 s, peak RAM 320180 KB repo 381 MiB first borg 32.74 s, peak RAM 91672 KB repo 424 MiB first kopia 9.79 s, peak RAM 262332 KB repo 547 MiB unchanged restic 1.29 s, peak RAM 65936 KB repo 381 MiB unchanged borg 15.20 s, peak RAM 91476 KB repo 424 MiB unchanged kopia 0.88 s, peak RAM 132520 KB repo 547 MiB unchanged2 restic 1.57 s, peak RAM 67116 KB repo 381 MiB unchanged2 borg 6.19 s, peak RAM 91676 KB repo 424 MiB unchanged2 kopia 1.14 s, peak RAM 130876 KB repo 547 MiB ``` في المخرج أعلاه لاحظ التالي: - **Kopia أسرع بكثير في النسخة الأولى** ولكن مستودعها أكبر، والسبب أن الضغط Compression فيها معطل بشكل افتراضي، فالأمر `kopia policy show --global` يعرض السطر `Compression disabled.`، أما restic فتضغط بشكل افتراضي بالمستوى `auto` كما في [توثيق الضبط](https://restic.readthedocs.io/en/stable/047%5Ftuning%5Fparameters.html?ref=arabroot.io)، وBorg يضغط ب lz4 بشكل افتراضي. - هل سرعة Kopia سببها غياب الضغط فقط؟ لا، فقد أنشأنا مستودعاً آخر لها مع `kopia policy set --global --compression=zstd` ونسخنا البيانات كلها في نهاية التجربة، وهي أكبر من البداية، فأخذت 9.80 ثانية وأصبح المستودع 390 ميجابايت، أي قريباً من restic في الحجم مع بقاء السرعة. - **Borg بطيء في النسخة دون تغيير:** 15.2 ثانية ثم 6.19 مقابل ثانية واحدة تقريباً للأخريين، والسبب الذي وجدناه في [أسئلة Borg الشائعة](https://borgbackup.readthedocs.io/en/stable/faq.html?ref=arabroot.io) أن ذاكرة الملفات Files Cache تستثني عمداً الملفات التي لها أحدث وقت تغيير في الأرشيف، وفي بياناتنا هذا هو ملف التفريغ نفسه بحجم 143 ميجابايت، فيعيد Borg تقسيمه في كل مرة دون أن يضيف بيانات جديدة. ويقترح التوثيق نفسه أن تنشئ ملفاً صغيراً قبل كل نسخة حتى يكون هو الأحدث. - **الذاكرة:** Borg ثابت عند 92 ميجابايت تقريباً في كل العمليات، وrestic وKopia تستهلكان أكثر في النسخة الأولى، وهذا مهم على VPS صغير بذاكرة 1 جيجابايت. ### نسخة بعد تغيير حقيقي، ثم مجلد مكرر الآن نغير البيانات كما يحدث في يوم عمل: نضيف عشرة آلاف سطر في وسط ملف التفريغ، وعشر صور جديدة بحجم 1 ميجابايت لكل منها، ونعدل خمسين ملف Python: ```bash cd /src L=$(wc -l < db/shop.sql); H=$((L/2)) { head -n $H db/shop.sql; seq 1 10000 | sed "s/^/-- inserted line /"; tail -n +$((H+1)) db/shop.sql; } > /tmp/new.sql cat /tmp/new.sql > db/shop.sql for i in $(seq 301 310); do head -c 1048576 /dev/urandom > media/IMG_$i.jpg; done find code -name "*.py" | head -50 | while read f; do echo "# edited" >> "$f"; done bench.sh changed cp -a /src/media /src/media-copy bench.sh duplicate ``` والمخرج سوف يكون كما يلي: ```text changed restic 5.10 s, peak RAM 218468 KB repo 391 MiB changed borg 12.56 s, peak RAM 91728 KB repo 440 MiB changed kopia 6.37 s, peak RAM 157572 KB repo 579 MiB duplicate restic 3.10 s, peak RAM 98248 KB repo 391 MiB duplicate borg 8.95 s, peak RAM 91736 KB repo 440 MiB duplicate kopia 1.29 s, peak RAM 142484 KB repo 579 MiB ``` في المخرج أعلاه لاحظ التالي: - البيانات الجديدة فعلاً قرابة 10 ميجابايت من الصور وبضعة ميجابايتات من الأسطر المضافة، فزاد مستودع restic بمقدار 10 ميجابايت، وBorg بمقدار 16، وKopia بمقدار 32، والفرق في Kopia يأتي من غياب الضغط ومن حجم الأجزاء، فالمستودع يعرض `Splitter: DYNAMIC-4M-BUZHASH` أي أجزاء متوسطها 4 ميجابايت، فتغيير صغير يعيد حفظ جزء أكبر. - نسخ مجلد الصور كاملاً، أي 318 ميجابايت إضافية، لم يزد أي مستودع ولا ميجابايت واحداً، وهذه هي إزالة التكرار في أوضح صورها. ### الاستعادة والفحص الكامل استعدنا آخر نسخة، وهي الآن 5437 ملفاً بحجم 0.9 جيجابايت، بكل أداة إلى مجلد فارغ، ثم قارنا بصمة SHA-256 لكل الملفات مع الأصل، وبعد ذلك شغلنا الفحص الذي يقرأ كل البيانات في كل أداة: ```bash restic restore latest --target /restore/restic cd /restore/borg && borg extract ::duplicate kopia snapshot restore k0fc13146f4eaa7533708a486b5e20170 /restore/kopia restic check --read-data borg check --verify-data kopia snapshot verify --verify-files-percent=100 ``` والمخرج سوف يكون كما يلي، مع بصمة واحدة لكل مجلد مستعاد ثم بصمة الأصل: ```text restore restic: 14.79 s, peak RAM 156940 KB restore borg: 43.93 s, peak RAM 109416 KB restore kopia: 31.92 s, peak RAM 256640 KB 3fa352c06bf7bf41 3fa352c06bf7bf41 3fa352c06bf7bf41 3fa352c06bf7bf41 restic check --read-data: 5.95 s, peak RAM 79908 KB borg check --verify-data: 9.17 s, peak RAM 91700 KB kopia snapshot verify (100% files): 3.02 s, peak RAM 303748 KB ``` الأدوات الثلاث استعادت البيانات مطابقة تماماً، ولكن لاحظ أن الاستعادة أبطأ من النسخ في Borg وKopia على هذا الجهاز، فBorg أخذ قرابة ثلاثة أضعاف وقت restic. وتذكر أن هذا الرقم هو ما يحدد ال RTO، فقس الاستعادة على بياناتك ولا تكتف بقياس النسخ. ### النتائج في جدول واحد | المقياس | restic 0.19.1 | Borg 1.4.5 | Kopia 0.23.1 | | ------------------------------ | ------------------ | ------------------- | ------------------ | | النسخة الأولى (572 MB) | 36.7 ثانية | 32.7 ثانية | 9.8 ثانية | | حجم المستودع بعد النسخة الأولى | 381 MiB | 424 MiB | 547 MiB (دون ضغط) | | نسخة دون تغيير | 1.3 إلى 1.6 ثانية | 6.2 إلى 15.2 ثانية | 0.9 إلى 1.1 ثانية | | نسخة بعد التغيير | 5.1 ثانية، +10 MiB | 12.6 ثانية، +16 MiB | 6.4 ثانية، +32 MiB | | مجلد مكرر 318 MB | +0 MiB | +0 MiB | +0 MiB | | حجم المستودع النهائي (5 نسخ) | 391 MiB | 440 MiB | 579 MiB | | استعادة 0.9 GB | 14.8 ثانية | 43.9 ثانية | 31.9 ثانية | | الفحص الكامل للبيانات | 6.0 ثوان | 9.2 ثوان | 3.0 ثوان | | أعلى استهلاك للذاكرة | 320 MB | 110 MB | 304 MB | وقد يتساءل البعض: إذن Kopia هي الأسرع وrestic هي الأصغر، فلماذا لا يكفي الجدول للاختيار؟ والإجابة أن الفرق بين 10 ثوان و37 ثانية لا يهمك في نسخة ليلية، أما ما يهمك فهو أين تستطيع أن تكتب، وهل تستطيع أن تحمي النسخ من الحذف، ومن في فريقك يستطيع أن يستعيد ملفاً وحده، وهذا ما تجيب عنه الأقسام التالية. ## restic [restic](https://github.com/restic/restic?ref=arabroot.io) مكتوبة بلغة Go وتأتي كملف تنفيذي واحد، برخصة BSD-2-Clause كما في [ملف الرخصة](https://github.com/restic/restic/blob/master/LICENSE?ref=arabroot.io)، وآخر إصدار عند كتابة المقال [0.19.1](https://github.com/restic/restic/releases/tag/v0.19.1?ref=arabroot.io). وتثبيتها من الملف الرسمي مع التحقق من البصمة كما يلي: ```bash curl -sSLO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2 curl -sSLO https://github.com/restic/restic/releases/download/v0.19.1/SHA256SUMS grep linux_amd64.bz2 SHA256SUMS | sha256sum -c bunzip2 restic_0.19.1_linux_amd64.bz2 sudo install restic_0.19.1_linux_amd64 /usr/local/bin/restic ``` ```text restic_0.19.1_linux_amd64.bz2: OK ``` والأوامر اليومية أربعة: `restic init` لإنشاء المستودع، و`restic backup` للنسخ، و`restic forget --prune` لتطبيق سياسة الاحتفاظ، و`restic restore` للاستعادة، وقد شرحناها كلها مع مخرجاتها في [تجربة 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/#lab). **نقاط القوة:** تكتب إلى أنواع كثيرة من المخازن دون أن تثبت شيئاً عليها، وأصغر مستودع في تجربتنا وأسرع استعادة، ولها rest-server بوضع الإضافة فقط ضد برامج الفدية، وتوثيقها واضح في الفحص والإصلاح، فقد رأينا في تجربة 3-2-1 كيف اكتشفت التلف واقترحت أمر الإصلاح بنفسها. **نقاط الضعف:** لا توجد جدولة ولا سياسة احتفاظ داخل الأداة، فأنت تكتب السكربت ومؤقت systemd أو cron بنفسك، ولا توجد واجهة رسومية رسمية، وهناك واجهات من مشاريع أخرى مثل [Backrest](https://github.com/garethgeorge/backrest?ref=arabroot.io) برخصة GPL-3.0، واستهلاك الذاكرة أعلى من Borg. ## Borg [BorgBackup](https://github.com/borgbackup/borg?ref=arabroot.io) أقدم الأدوات الثلاث، مكتوب بلغة Python مع أجزاء بلغة C، برخصة BSD من ثلاثة بنود كما في [ملف الرخصة](https://github.com/borgbackup/borg/blob/1.4-maint/LICENSE?ref=arabroot.io)، والإصدار المستقر [1.4.5](https://github.com/borgbackup/borg/releases/tag/1.4.5?ref=arabroot.io). أما Borg 2 فما زال تجريبياً Beta، وملف README في فرعه الرئيسي يقول بوضوح `DO NOT USE BORG2 FOR YOUR PRODUCTION BACKUPS!`، لذلك اعتمدنا 1.4\. وتثبيته من الملف التنفيذي الرسمي كما يلي، أو من حزمة التوزيعة إن كان إصدارها حديثاً: ```bash sudo curl -sSLo /usr/local/bin/borg \ https://github.com/borgbackup/borg/releases/download/1.4.5/borg-linux-glibc235-x86_64-gh sudo chmod +x /usr/local/bin/borg borg --version ``` ```text borg 1.4.5 ``` وعند إنشاء المستودع يطبع Borg تذكيراً يستحق أن تقرأه: ```text IMPORTANT: you will need both KEY AND PASSPHRASE to access this repo! Key storage location depends on the mode: - repokey modes: key is stored in the repository directory. - keyfile modes: key is stored in the home directory of this user. For any mode, you should: 1. Export the borg key and store the result at a safe place: borg key export REPOSITORY encrypted-key-backup borg key export --paper REPOSITORY encrypted-key-backup.txt borg key export --qr-html REPOSITORY encrypted-key-backup.html 2. Write down the borg key passphrase and store it at safe place. ``` والأوامر اليومية: `borg create` للنسخ باسم لكل أرشيف، و`borg prune` ثم `borg compact` لسياسة الاحتفاظ وتحرير المساحة، و`borg extract` أو `borg mount` للاستعادة. ومعظم من يستخدمه على السيرفرات يضع فوقه [borgmatic](https://torsion.org/borgmatic/?ref=arabroot.io)، وهو ملف إعداد YAML واحد للمصادر والمستودعات وسياسة الاحتفاظ والفحص، أما على سطح المكتب فهناك واجهة [Vorta](https://github.com/borgbase/vorta?ref=arabroot.io) برخصة GPL-3.0. **نقاط القوة:** ناضج ومستقر منذ سنوات، وأقل استهلاك للذاكرة في تجربتنا وثابت في كل العمليات، ووضع الإضافة فقط مع `borg serve` عبر SSH يمنع السيرفر المخترق من حذف النسخ نهائياً كما في [ملاحظات الاستخدام](https://borgbackup.readthedocs.io/en/stable/usage/notes.html?ref=arabroot.io)، وأداة borgmatic تجعل الإعداد سهلاً. **نقاط الضعف:** لا يكتب إلى S3 ولا إلى أي خدمة تخزين كائنات مباشرة، والسيرفر الهدف يجب أن يشغل Borg، والاستعادة كانت الأبطأ في تجربتنا، وذاكرة الملفات تعيد تقسيم الملف الأحدث في كل نسخة كما رأينا. ولاحظ أن وضع الإضافة فقط فيه لا يمنع أمر `prune` ولكنه يمنع الحذف الفعلي من ملفات المستودع، ويحترمه Borg وحده، فالأمر `rm` على السيرفر الهدف ما زال يعمل، لذلك يجب أن يصل العميل إلى المستودع عبر `borg serve` فقط. ## Kopia [Kopia](https://github.com/kopia/kopia?ref=arabroot.io) مكتوبة بلغة Go برخصة Apache-2.0 كما في [ملف الرخصة](https://github.com/kopia/kopia/blob/master/LICENSE?ref=arabroot.io)، والإصدار المستخدم [0.23.1](https://github.com/kopia/kopia/releases/tag/v0.23.1?ref=arabroot.io)، وتأتي بسطر أوامر وبتطبيق مكتبي KopiaUI وبسيرفر له واجهة ويب. وتثبيتها كما في [صفحة التثبيت](https://kopia.io/docs/installation/?ref=arabroot.io) من مستودع الحزم الرسمي، أو من الملف المضغوط كما فعلنا: ```bash curl -sSLO https://github.com/kopia/kopia/releases/download/v0.23.1/kopia-0.23.1-linux-x64.tar.gz tar xzf kopia-0.23.1-linux-x64.tar.gz sudo install kopia-0.23.1-linux-x64/kopia /usr/local/bin/ kopia repository create filesystem --path /repos/kopia kopia repository status ``` والجزء المهم من مخرج الأمر الأخير: ```text Hash: BLAKE2B-256-128 Encryption: AES256-GCM-HMAC-SHA256 Splitter: DYNAMIC-4M-BUZHASH Format version: 3 ``` والفرق الأوضح عن الأداتين الأخريين أن Kopia تحفظ السياسات Policies داخل المستودع: الاحتفاظ والضغط والملفات المستثناة والجدولة، فالأمر `kopia policy show --global` عرض في تجربتنا هذه القيم الافتراضية: ```text Retention: Annual snapshots: 3 (defined for this target) Monthly snapshots: 24 (defined for this target) Weekly snapshots: 4 (defined for this target) Daily snapshots: 7 (defined for this target) Hourly snapshots: 48 (defined for this target) Latest snapshots: 10 (defined for this target) ``` وكذلك الصيانة، فبحسب [صفحة الصيانة](https://kopia.io/docs/advanced/maintenance/?ref=arabroot.io) تعمل الصيانة السريعة تلقائياً كل ساعة تقريباً، والكاملة التي تحذف البيانات غير المستخدمة كل 24 ساعة، ويقوم بها مستخدم واحد مسؤول عن المستودع. ولأن Kopia لها واجهة رسومية، شغلنا سيرفرها على المستودع نفسه بالأمر التالي، ونشرنا منفذه على `127.0.0.1` فقط: ```bash kopia server start --insecure --address=0.0.0.0:51515 \ --server-username=admin --server-password=ui-pass-456 ``` والصورة التالية تبين صفحة النسخ في واجهة الويب، ولاحظ أن عمود Retention يبين لماذا تبقى كل نسخة بحسب السياسة: ![واجهة ويب Kopia تعرض نسخ المسار root@bench:/src في المستودع /repos/kopia، ثلاث نسخ بأحجام 0.9 GB و582.8 MB و572.1 MB وعدد الملفات 5437 و5127 و5117، وبجانب كل نسخة وسوم الاحتفاظ مثل latest-1 وhourly-1 وdaily-1 وweekly-1 وmonthly-1 وannual-1](https://arabroot.io/content/images/2026/10/backup-tools-compare-04-kopia-snapshots.webp) نسخ تجربتنا في واجهة Kopia مع سبب الاحتفاظ بكل نسخة والصورة التالية تبين صفحة السياسة لنفس المسار، حيث تضبط الاحتفاظ والملفات والضغط والجدولة من المتصفح: ![صفحة سياسة المسار root@bench:/src في Kopia فيها أقسام Snapshot Retention وFiles وError Handling وCompression وScheduling، والقسم الأخير مفتوح ويعرض تكرار النسخ وأوقات اليوم وتعبيرات Cron، وكل قيمة موروثة من السياسة العامة Global Policy](https://arabroot.io/content/images/2026/10/backup-tools-compare-05-kopia-policy.webp) السياسات في Kopia تضبط من الواجهة وتورث من السياسة العامة ⚠️ الخيار `--insecure` يعني أن السيرفر يعمل دون TLS، وقد استخدمناه في التجربة فقط لأن المنفذ على `127.0.0.1`، أما إذا فتحت الواجهة على الشبكة فشغلها بشهادة أو خلف Reverse Proxy مع HTTPS، والسبب أن كلمة مرور الواجهة تعطي من يملكها القدرة على قراءة نسخك واستعادتها. **نقاط القوة:** أسرع نسخ أولى في تجربتنا، وتكتب إلى أنواع كثيرة من المخازن، وتدعم Object Lock في S3 ضد برامج الفدية كما في [صفحة الحماية من برامج الفدية](https://kopia.io/docs/advanced/ransomware-protection/?ref=arabroot.io)، والسياسات والجدولة والصيانة داخل الأداة، ولها واجهة رسومية رسمية يستطيع أن يستعيد منها شخص لا يحب سطر الأوامر. **نقاط الضعف:** الضغط معطل افتراضياً فيكبر المستودع حتى تفعله بنفسك، والأجزاء الكبيرة تجعل التغييرات الصغيرة تضيف أكثر، واستهلاك الذاكرة أعلى، والصيانة التلقائية تعني أن عليك أن تفهم من يملكها قبل أن تشغل أكثر من جهاز على المستودع نفسه. ## التشفير والحماية من الحذف | | restic | Borg 1.4 | Kopia | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- | | التشفير | AES-256 في وضع CTR مع Poly1305-AES ([التصميم](https://github.com/restic/restic/blob/master/doc/design.rst?ref=arabroot.io)) | AES-256-CTR مع HMAC-SHA256 في وضع repokey، أو BLAKE2b في repokey-blake2 ([borg init](https://borgbackup.readthedocs.io/en/stable/usage/init.html?ref=arabroot.io)) | AES256-GCM-HMAC-SHA256 افتراضياً ([التشفير](https://kopia.io/docs/advanced/encryption/?ref=arabroot.io)) | | الضغط الافتراضي | auto (zstd) | lz4 | معطل | | الحماية من سيرفر مخترق | rest-server أو rclone بوضع append-only | borg serve بوضع append-only عبر SSH | Object Lock في S3، ومفاتيح محدودة الصلاحيات | | الرخصة | BSD-2-Clause | BSD-3-Clause | Apache-2.0 | وفي الأدوات الثلاث المفتاح محفوظ داخل المستودع ومشفر بكلمة المرور، فضياع كلمة المرور يعني ضياع النسخ، لذلك احفظها خارج السيرفر كما ذكرنا في [ما الذي تنسخه](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/#what-to-backup)، ومع Borg صدر المفتاح نفسه أيضاً بالأمر `borg key export` كما ينصح عند الإنشاء. ## أي أداة تختار؟ - **اختر restic** إذا كانت نسختك الخارجية على S3 أو B2 أو أي خدمة تخزين كائنات، وتريد أداة واحدة بسيطة تكتبها في سكربت مع مؤقت systemd، وهذا ما يناسب أغلب السيرفرات، ولهذا استخدمناها في [دليل 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/). - **اختر Borg** إذا كان لديك سيرفر نسخ تصل إليه عبر SSH، أو تستخدم مزوداً يقدم Borg، وكانت الذاكرة محدودة، وتريد أداة ناضجة مع borgmatic، وانتظر Borg 2 حتى يصبح مستقراً قبل أن تنقل إليه. - **اختر Kopia** إذا كان في فريقك من يحتاج واجهة رسومية للنسخ والاستعادة، أو تريد السياسات والجدولة داخل الأداة، أو تريد Object Lock في S3، وفعل الضغط من البداية. وأياً كانت الأداة فالقواعد نفسها: نسخة خارج الموقع، ونسخة لا يحذفها السيرفر، وفحص يقرأ البيانات، واستعادة مجربة. ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - الأدوات الثلاث تقسم الملفات بحسب المحتوى وتحفظ كل جزء مرة واحدة وتشفر قبل الإرسال، فنسخ مجلد مكرر من 318 ميجابايت لم يضف إلى أي منها شيئاً. - على بياناتنا: Kopia الأسرع في النسخة الأولى ولكن دون ضغط افتراضياً، وrestic الأصغر مستودعاً والأسرع استعادة، وBorg الأقل ذاكرة والأبطأ استعادة. - الفرق الذي يحسم الاختيار غالباً هو مكان التخزين: restic وKopia إلى S3 وخدمات كثيرة مباشرة، وBorg 1.4 إلى مجلد محلي أو عبر SSH فقط. - لكل أداة طريقة لحماية النسخ من سيرفر مخترق، فلا تستخدم أياً منها بمفاتيح تستطيع الحذف من السيرفر نفسه. - أرقامنا للمقارنة على جهاز واحد، فقس النسخ والاستعادة على بياناتك قبل أن تعتمد عليها. وبقية مواضيع النسخ الاحتياطي، مثل مكان النسخة الخارجية ونسخ قواعد البيانات وProxmox Backup Server، مخطط لها في [مرحلة التشغيل والصيانة](https://arabroot.io/start/#stage-operate). [![](https://arabroot.io/content/images/2026/10/backup-321-cover-cover.webp)دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)[![](https://arabroot.io/content/images/2026/10/storage-types-cover-cover.webp)دليلأنواع التخزين وواجهة S3: أين تضع بيانات تطبيقك؟أين تضع قاعدة البيانات وملفات المستخدمين والنسخ الاحتياطية، ولماذا يناسب كلاً منها نوع مختلف من التخزين.](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%A7%D9%84%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-block-%D9%88-file-%D9%88-object-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/self-hosting-terms-cover-cover-1.webp)دليلمصطلحات الاستضافة الذاتية Self-hosting للمبتدئينمرجع مبسط لأهم المصطلحات التي سوف تقابلها في أدلة الاستضافة الذاتية، بأسمائها الإنجليزية كما تظهر في لوحات التحكم، مع شرح قصير لكل منها.](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9-%D8%A7%D9%84%D8%B0%D8%A7%D8%AA%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/docker-migrate-server-cover-cover.webp)دليلنقل Containers إلى خادم جديد دون فقدان البياناتكيف تنقل ال Containers مع بياناتها إلى سيرفر جديد، دفعة واحدة أو تطبيقاً بعد تطبيق، مع خطة للتراجع إذا تعثر النقل.](https://arabroot.io/articles/%D9%86%D9%82%D9%84-containers-%D8%A5%D9%84%D9%89-%D8%AE%D8%A7%D8%AF%D9%85-%D8%AC%D8%AF%D9%8A%D8%AF/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، ومقارنة restic 0.19.1 وBorg 1.4.5 وKopia 0.23.1 على مجموعة بيانات من 572 ميجابايت داخل Debian 13 في Docker، مع لقطات واجهة Kopia من تثبيتنا.