مقایسه Restic و BorgBackup برای بکاپ‌گیری لینوکس

مقایسه Restic و BorgBackup در یک پاراگراف

هر دو ابزار Restic و BorgBackup وظیفه اصلی یکسانی دارند: تهیه نسخه پشتیبان افزایشی، رمزنگاری‌شده و دارای deduplication از یک سرور لینوکسی. تفاوت تعیین‌کننده در انتخاب بین این دو، محل ذخیره‌سازی نسخه پشتیبان است. Restic به‌صورت بومی از S3 و سایر APIهای ذخیره‌سازی شیء (object storage) پشتیبانی می‌کند، بنابراین یک bucket یک مقصد درجه‌یک محسوب می‌شود که نیازی به نصب هیچ نرم‌افزاری در سمت مقصد ندارد. در مقابل، Borg نیاز دارد که برنامه borg روی ماشینی که مخزن (repository) را میزبانی می‌کند نصب باشد، زیرا یک مخزن Borg توسط یک پردازش سرویس‌دهی می‌شود، نه توسط یک سیستم فایل یا API. اگر مقصد شما ذخیره‌سازی شیء است، پاسخ مشخص است. اگر مقصد یک سرور لینوکسی دیگر است که کنترل آن را در دست دارید، Borg گزینه مناسبی است و اغلب سرعت بالاتری دارد.

سایر تفاوت‌ها جزئی هستند. هر دو ابزار فایل‌ها را با استفاده از content defined chunking قطعه‌بندی می‌کنند، بنابراین یک دایرکتوری 40 گیگابایتی که 200 مگابایت تغییر داشته، تقریباً همان 200 مگابایت را آپلود می‌کند. هر دو در سمت کلاینت رمزنگاری را انجام می‌دهند. هر دو امکان mount کردن یک snapshot را با استفاده از FUSE (سیستم فایل در فضای کاربر) فراهم می‌کنند تا بتوانید یک فایل خاص را بازیابی کنید. تا ژوئیه 2026، نسخه Restic برابر با 0.19.1 و سری پایدار Borg نسخه 1.4.5 است. نسخه 2.0 از Borg سال‌هاست که در مرحله بتا قرار دارد و همچنان به‌عنوان نسخه آزمایشی شناخته می‌شود، بنابراین نسخه 1.4 گزینه‌ای است که باید امروز مستقر کنید.

مدل مخزن، تفاوت اصلی است

یک مخزن restic مجموعه‌ای از فایل‌هاست: config، keys/، snapshots/، index/ و data/ که پر از فایل‌های pack هستند. برای خواندن آن به هیچ چیز دیگری نیاز نیست. به همین دلیل است که restic می‌تواند از بسیاری از backendها پشتیبانی کند. هر فضای ذخیره‌سازی که بتواند blobها را قرار دهد (put)، دریافت کند (get)، لیست کند (list) و حذف نماید (delete)، می‌تواند میزبان یک مخزن restic باشد. این همان روشی است که یک فایل اجرایی واحد از مسیرهای محلی، SFTP، سرور REST اختصاصی خود، S3، Backblaze B2، Azure، Google Cloud Storage و هر چیزی که rclone به آن دسترسی دارد، پشتیبانی می‌کند.

مخزن Borg نیز شامل فایل‌هایی روی دیسک است، اما Borg هرگز از طریق یک انتقال‌دهنده ساده (dumb transport) با آن ارتباط برقرار نمی‌کند. برای یک مخزن از راه دور، Borg برنامه borg serve را در سمت مقصد از طریق SSH اجرا کرده و با آن پردازش، پروتکل اختصاصی خود را صحبت می‌کند. سمت سرور کار واقعی انجام می‌دهد: مخزن را نگه می‌دارد، تراکنش را اعمال می‌کند و به پرسش‌های مربوط به ایندکس پاسخ می‌دهد. به همین دلیل است که Borg فاقد backend برای S3 است و پروژه نیز تا به حال آن را اضافه نکرده است. هیچ پردازشی برای اجرا در داخل یک bucket وجود ندارد.

همین یک واقعیت در طراحی، اکثر تفاوت‌های عملی زیر را ایجاد می‌کند.

# 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 کلید رمزنگاری‌شده را درون مخزن نگه می‌دارد، بنابراین تنها با استفاده از عبارت عبور (passphrase) می‌توان داده‌ها را بازیابی کرد. --encryption=keyfile کلید را روی کلاینت در ~/.config/borg/keys/ نگه می‌دارد؛ در این حالت اگر کسی کل مخزن را سرقت کند، چیزی به دست نمی‌آورد، اما شما باید از آن فایل کلید به‌صورت جداگانه نسخه پشتیبان تهیه کنید، در غیر این صورت آرشیوهای شما غیرقابل خواندن خواهند بود. هر حالت یک نسخه -blake2 نیز دارد که به‌جای HMAC-SHA256 با BLAKE2b احراز هویت می‌کند؛ این روش روی سخت‌افزارهایی که شتاب‌دهنده SHA ندارند، سریع‌تر است. --encryption=none نیز وجود دارد و زمانی که مخزن روی یک دیسک رمزنگاری‌شده که مالک آن هستید قرار دارد، یک انتخاب واقعی محسوب می‌شود.

قانون کاربردی: برای پشتیبان‌گیری معمولی از سرور از repokey-blake2 استفاده کنید، زمانی که مخزن در جایی قرار دارد که کاملاً به آن اعتماد ندارید از keyfile استفاده کنید و هرگز روی یک ماشین اجاره‌ای از none استفاده نکنید.

فشرده‌سازی و دلیل تأخیر در پیاده‌سازی آن در restic

نرم‌افزار Borg از همان ابتدا از فشرده‌سازی پشتیبانی می‌کرد. مقدار پیش‌فرض lz4 است که به دلیل سرعت مناسب برای استفاده در تمامی سناریوها انتخاب شده است. zstd سطوح 1 تا 22 را می‌پذیرد و مقدار پیش‌فرض آن 3 است؛ zlib و lzma برای مواردی در نظر گرفته شده‌اند که حجم داده برای شما اولویت بیشتری نسبت به زمان صرف‌شده دارد و auto یک تحلیل اکتشافی (heuristic) روی هر تکه (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 نیازمند قرار دادن اعتبارنامه‌ها در محیط (environment) است و به هیچ پردازش دیگری در سمت مقصد نیاز ندارد. همین الگو برای باکتی که خودتان میزبانی می‌کنید نیز کارآمد است و ترکیب رایجی محسوب می‌شود: MinIO را برای داشتن API نوع S3 روی 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 در سمت مقصد است؛ همچنین نسخهٔ Borg در آن سمت باید با کلاینت سازگار باشد. اگر کنترل سمت مقصد در دست شما نباشد، این موضوع یک اصطکاک محسوب می‌شود. اما اگر مقصد سرور دومی باشد که خودتان مدیریت می‌کنید، این مسئله اهمیتی ندارد و در عوض، قوی‌ترین کنترل در برابر باج‌افزار را که هر یک از این دو ابزار ارائه می‌دهند، برایتان فراهم می‌کند: کلید SSH با دسترسی فقط-افزودنی (append-only). کلید را مجبور کنید که دستور borg serve را اجرا کند؛ در این صورت کلاینت می‌تواند آرشیوهای جدید اضافه کند اما قادر به حذف آن‌ها نیست. بنابراین، اگر دستگاهی مورد نفوذ قرار گیرد، نمی‌تواند تاریخچهٔ پشتیبان‌های خود را پاک کند.

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

Restic تنها زمانی معادل این قابلیت را دارد که سرور REST اختصاصی خود را اجرا کنید که از حالت فقط-افزودنی پشتیبانی می‌کند. در مواجهه با S3 معمولی، می‌توانید همین اثر را از طریق سیاست‌های باکت (bucket policy) یا قفل‌گذاری شیء (object lock) به دست آورید که وظیفهٔ ارائه‌دهندهٔ سرویس است، نه restic. مسیر انتقال داده را نیز محدود کنید، چرا که بخش SSH این فرآیند به همان اندازهٔ سایر ورودها نیازمند مراقبت است: برای حساب کاربری پشتیبان، SSH فقط با کلید و ورودی محدود در authorized_keys را اعمال کنید.

سرعت: هر طراحی چه پیامدهایی دارد

هیچ‌کدام از این دو پروژه بنچمارکی که بتوانید برای داده‌های خود به آن اعتماد کنید منتشر نمی‌کنند، بنابراین باید بر اساس مکانیزم عملکرد آن‌ها استدلال کنید.

استفاده از Borg روی SSH در لینک‌هایی که تأخیر (latency) دارند سریع است، زیرا سمت سرور هوشمند عمل می‌کند. کلاینت پرسشی مطرح می‌کند، پردازش borg serve در سمت ریموت پاسخ را از روی ایندکس مخزن (repository index) می‌دهد و تراکنش در یک نقطه نهایی می‌شود. جستجوی هر تکه (chunk) به رفت‌وبرگشت‌های شبکه برای تک‌تک فایل‌های کوچک تبدیل نمی‌شود.

Restic روی فضای ذخیره‌سازی شیءگرا (object storage) سمت سرور ندارد، بنابراین باید تصویر خود را از فایل‌های ایندکس و فایل‌های بسته‌بندی‌شده (pack files) که از طریق HTTP دریافت می‌کند، بسازد. برای اینکه تعداد درخواست‌ها در حد معقول باقی بماند، پیش از آپلود، بسیاری از تکه‌های کوچک را در فایل‌های pack بزرگ‌تر بسته‌بندی می‌کند و یک کش محلی در ~/.cache/restic نگه می‌دارد تا در اجرای بعدی، کل ایندکس دوباره دریافت نشود. اگر آن کش را حذف کنید، بک‌آپ بعدی به دلیل بازسازی ایندکس کند خواهد بود. در لینک‌هایی با تأخیر بالا و میلیون‌ها فایل کوچک، این همان حالتی است که restic نسبت به Borg روی داده‌های مشابه، کندتر به نظر می‌رسد.

روی دیسک محلی یا شبکه LAN سریع، این فاصله تا حد زیادی از بین می‌رود و هر دو ابزار در نهایت توسط سرعت خواندن و هش کردن منبع محدود می‌شوند.

قفل‌گذاری و پشتیبان‌گیری از چندین ماشین

نرم‌افزار Borg 1.4 در طول کل عملیات، یک قفل انحصاری (exclusive lock) روی مخزن (repository) اعمال می‌کند. نوشتن همزمان دو کلاینت در یک مخزن امکان‌پذیر نیست: کلاینت دوم منتظر می‌ماند و سپس با خطای lock timeout مواجه می‌شود. الگوی پشتیبانی‌شده، اختصاص یک مخزن به هر کلاینت است. این یعنی deduplication فقط در مخزنِ همان یک ماشین انجام می‌شود؛ بنابراین ده سرور تقریباً مشابه، ده نسخه از یک سیستم پایه را ذخیره می‌کنند.

نرم‌افزار Restic اجازه می‌دهد چندین کلاینت به‌طور همزمان در یک مخزن پشتیبان‌گیری کنند، زیرا عملیات پشتیبان‌گیری از یک قفل اشتراکی (shared lock) استفاده می‌کند و فقط کارهای نگهداری مانند prune به قفل انحصاری نیاز دارند. ده سرور مشابه که به یک مخزن Restic متصل هستند، داده‌ها را نسبت به یکدیگر deduplicate می‌کنند و سرور دوم به بعد، اغلب حجم بسیار کمی را ذخیره می‌کند. هزینه این کار، افزایش شعاع انفجار (blast radius) است: یک رمز عبور و یک مخزن که همه چیز را در خود نگه می‌دارد؛ بنابراین از دست دادن رمز عبور به معنای از دست رفتن داده‌های هر ده سرور است.

نگهداری: تفاوت 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 job که فقط prune می‌کند و هرگز compact نمی‌کند، مخزنی ایجاد می‌کند که حجم آن بی‌وقفه رشد می‌کند، در حالی که لیست آرشیوها کوتاه باقی می‌ماند. در restic، دستور forget بدون --prune فقط ارجاعات snapshot را حذف می‌کند و داده‌ها تا زمانی که یک prune اجرا نشود، باقی می‌مانند.

پس از prune، دستور restic check را اجرا کنید. این دستور ساختارهای مخزن را بررسی می‌کند و اگر چیزی آسیب دیده باشد به شما اطلاع می‌دهد؛ این کار بسیار بهتر از آن است که در زمان بازیابی (restore) متوجه خرابی شوید.

بازیابی، تنها آزمونی که اهمیت دارد

هر دو ابزار یک snapshot را mount می‌کنند تا بتوانید در آن جستجو کنید. این سریع‌ترین روش برای بازگرداندن یک فایل تکی است.

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 با هیچ‌چیز مطابقت ندارد و چیزی استخراج نمی‌کند، بدون اینکه خطایی برای دلیل آن به شما نمایش دهد. عملیات استخراج همچنین در دایرکتوری کاری فعلی می‌نویسد، پس ابتدا به یک دایرکتوری موقت (scratch) بروید، در غیر این صورت فایل‌های زنده را با فایل‌های قدیمی بازنویسی خواهید کرد.

بازیابی‌ای که بدون خطا به پایان می‌رسد هنوز اثبات‌کننده نیست، زیرا برنامه‌ای که روی آن اجرا می‌شود تصور خاص خود را از یک بازیابی کامل دارد: یک سرور Immich که از روی کپی دایرکتوری داده‌های Postgres بازسازی شده باشد، با تمام عکس‌های موجود روی دیسک بالا می‌آید اما تایم‌لاین آن چیزی را نشان نمی‌دهد؛ این دقیقاً همان شکستی است که پشتیبان‌گیری و بازیابی Immich باید برای آن چاره‌ای بیندیشد.

هر ابزاری که انتخاب می‌کنید، زمان‌بندی تنها نیمی از کار است. یک بازیابی را در یک دایرکتوری موقت و طبق زمان‌بندی منظمی که واقعاً آن را پایش می‌کنید اجرا کنید، همان‌طور که راهنمای کامل در راهنمای پشتیبان‌گیری restic برای VPS با استفاده از یک systemd timer انجام می‌دهد.

کدام ابزار برای چه کاری مناسب‌تر است

زمانی که مقصد ذخیره‌سازی شیء (object storage) است، زمانی که به یک فایل اجرایی واحد نیاز دارید و نمی‌خواهید روی سمت مقصد نرم‌افزاری نصب کنید، زمانی که چندین ماشین باید داده‌های تکراری خود را نسبت به یکدیگر حذف (deduplicate) کنند، یا زمانی که ممکن است فردی غیر از شما عملیات بازیابی را انجام دهد، restic را انتخاب کنید. این ابزار یک فایل اجرایی واحد و ایستا (static binary) است که با یک URL برای مخزن کار می‌کند و از نظر عملیاتی، شکست دادن آن دشوار است.

زمانی که مقصد یک سرور لینوکسی است که آن را کنترل می‌کنید، زمانی که لینک شبکه دارای تأخیر (latency) است و مجموعه داده شامل میلیون‌ها فایل کوچک است، زمانی که می‌خواهید از کلید SSH با دسترسی فقط-افزودنی (append-only) به عنوان محافظی در برابر باج‌افزار استفاده کنید، یا زمانی که می‌خواهید فشرده‌سازی را برای هر job به‌صورت جداگانه تنظیم کنید، Borg را انتخاب کنید. این ابزار قدیمی‌تر است، نسخه‌های پایدار آن با سرعت کمی تغییر می‌کنند و در دنیای نرم‌افزارهای پشتیبان‌گیری، این یک ویژگی مثبت محسوب می‌شود.

هر دو انتخاب درست هستند. پاسخ غلط، روشی است که هرگز آن را تست نمی‌کنید. اگر از قبل از سطح اپلیکیشن dump تهیه می‌کنید، آن‌ها را حفظ کنید: الگوی موجود در راهنمای Nextcloud روی Docker با dump دیتابیس برای هر دو ابزار صدق می‌کند، زیرا یک فایل دیتابیس زنده که در یک لحظه تصادفی کپی شده باشد، پشتیبان معتبری از دیتابیس نیست.

FAQ

آیا restic سریع‌تر است یا BorgBackup؟

روی دیسک محلی یا شبکه LAN پرسرعت، عملکرد هر دو نزدیک است و هر دو در نهایت با سرعت خواندن و هش کردن در منبع محدود می‌شوند. Borg معمولاً در لینک‌های SSH با تأخیر بالا و تعداد زیادی فایل کوچک برتری دارد، زیرا یک پردازش borg serve در سمت مقصد، پرس‌وجوهای مربوط به ایندکس را بدون نیاز به رفت‌وبرگشت شبکه برای هر قطعه (chunk) پاسخ می‌دهد. Restic معمولاً زمانی برتری دارد که مقصد، object storage باشد؛ جایی که Borg اصلاً امکان فعالیت ندارد.

آیا BorgBackup می‌تواند از S3 یا Backblaze B2 پشتیبان بگیرد؟

به‌طور مستقیم خیر. مخزن (repository) Borg توسط پردازش borg serve از طریق SSH سرویس‌دهی می‌شود و چنین پردازشی درون یک bucket اجرا نمی‌شود. برخی کاربران با mount کردن object storage به‌عنوان یک فایل‌سیستم توسط rclone این محدودیت را دور می‌زنند، اما پروژه Borg این کار را توصیه نمی‌کند؛ زیرا اگر mount در میانهٔ یک تراکنش قطع شود، ممکن است مخزن آسیب ببیند. اگر به object storage نیاز دارید، از restic استفاده کنید.

آیا می‌توانم هر دو ابزار را روی داده‌های یکسان اجرا کنم؟

بله، و برخی افراد این کار را انجام می‌دهند: Borg برای انتقال به سرور دوم جهت بازیابی سریع محلی، و restic برای انتقال به object storage جهت داشتن نسخه خارج از سایت (offsite). این دو هیچ منبع مشترکی ندارند، بنابراین هزینه خواندن و هش کردن را دو بار می‌پردازید و باید دو رمز عبور را به‌صورت امن نگهداری کنید. تنها در صورتی این کار را انجام دهید که بازیابی هر دو را تست کرده باشید.

اگر رمز عبور مخزن را گم کنم چه اتفاقی می‌افتد؟

در هر دو ابزار، داده‌ها غیرقابل بازیابی هستند. Restic کلید خود را با استفاده از scrypt از رمز عبور مشتق می‌کند و هیچ راه گریزی وجود ندارد. Borg در حالت repokey کلید رمزنگاری‌شده را درون مخزن ذخیره می‌کند، بنابراین تنها با داشتن رمز عبور (passphrase) می‌توانید بازیابی کنید؛ در حالت keyfile علاوه بر آن، به فایل کلید از ~/.config/borg/keys/ نیز نیاز دارید. رمز عبور را در یک مدیریت‌کننده رمز (password manager) که روی سرورِ در حال پشتیبان‌گیری قرار ندارد نگهداری کنید و اگر از keyfile استفاده می‌کنید، کلید Borg را با borg key export اکسپورت کنید.

آیا باید منتظر Borg 2.0 بمانم؟

خیر. تا ژوئیه 2026، نسخه Borg 2.0 همچنان در مرحله بتا و در نسخه 2.0.0b22 است و پروژه آن را فقط برای تست معرفی می‌کند. سری پایدار، 1.4 است که در حال حاضر نسخه 1.4.5 می‌باشد. از همین حالا با 1.4 شروع کنید. Borg 2 فرمت مخزن را تغییر می‌دهد و یک مسیر ارتقای مستند ارائه می‌کند، بنابراین شروع کار از امروز شما را در بن‌بست قرار نمی‌دهد.