Restic یا BorgBackup؛ کدام را اجرا کنیم؟

Restic در برابر BorgBackup، در یک پاراگراف

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

بقیه تفاوت‌ها جزئی‌تر هستند. هر دو ابزار فایل‌ها را با chunking مبتنی بر محتوا تقسیم می‌کنند؛ بنابراین اگر یک directory با اندازه 40 GB به‌اندازه 200 MB تغییر کند، تقریباً 200 MB بارگذاری می‌شود. هر دو ابزار داده‌ها را در سمت client رمزنگاری می‌کنند. هر دو یک snapshot را با FUSE (filesystem in userspace) mount می‌کنند تا بتوانید یک فایل را از آن خارج کنید. در July 2026، نسخه Restic برابر با 0.19.1 است و شاخه پایدار Borg نسخه 1.4، یعنی 1.4.5، است. Borg 2.0 چندین سال است که در مرحله beta قرار دارد و همچنان فقط برای testing علامت‌گذاری شده است؛ بنابراین امروز باید نسخه 1.4 را deploy کنید.

مدل مخزن تفاوت واقعی را ایجاد می‌کند

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

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

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

# 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 از آن یک کلید استخراج می‌کند و هر فایل بسته‌ای که پس از آن نوشته شود، رمزگذاری و احراز اصالت می‌شود. اگر گذرواژه را از دست بدهید، داده‌ها از بین می‌روند؛ زیرا طبق طراحی، هیچ مسیر بازیابی وجود ندارد.

در Borg، رمزگذاری هنگام ایجاد repository یک انتخاب است و این انتخاب دائمی است. borg init --encryption=repokey کلید رمزگذاری‌شده را داخل repository نگه می‌دارد؛ بنابراین فقط با عبارت عبور می‌توان آن را بازیابی کرد. --encryption=keyfile کلید را در سمت client و در ~/.config/borg/keys/ نگه می‌دارد؛ بنابراین کسی که کل repository را سرقت کند، همچنان به چیزی دسترسی ندارد. در این حالت باید از آن فایل کلید به‌صورت جداگانه نسخه پشتیبان تهیه کنید؛ در غیر این صورت، آرشیوهای شما خواندنی نخواهند بود. هر حالت، گونه‌ای با -blake2 نیز دارد که به‌جای HMAC-SHA256 با BLAKE2b احراز اصالت می‌کند. این گونه روی سخت‌افزاری که شتاب‌دهی SHA ندارد، سریع‌تر است. --encryption=none نیز وجود دارد و وقتی repository روی دیسک رمزگذاری‌شده‌ای قرار دارد که مالک آن هستید، انتخابی واقعی محسوب می‌شود.

قاعده عملی: برای پشتیبان‌گیری معمول از سرور از repokey-blake2 استفاده کنید؛ وقتی repository در مکانی قرار دارد که کاملاً به آن اعتماد ندارید، از 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 تا زمان ارائه repository format 2 هیچ فشرده‌سازی‌ای نداشت. استفاده از repository format 2 به restic 0.14.0 یا نسخه جدیدتر نیاز دارد. اکنون format 2 حالت پیش‌فرض برای یک repository جدید است و فشرده‌سازی با --compression و مقادیر auto، off یا max تنظیم می‌شود. یک repository قدیمی با format 1 تا زمانی که آن را migrate نکنید، بدون فشرده‌سازی باقی می‌ماند. بنابراین اگر repository مربوط به restic شما پیش از 0.14 ایجاد شده و هرگز آن را migrate نکرده‌اید، همچنان برای متن، logها و database dumpها حجم کامل را پرداخت می‌کنید.

اهداف راه دور: S3 در برابر SSH

معمولاً تصمیم در همین بخش گرفته می‌شود.

دسترسی restic به S3 به اعتبارنامه‌هایی در محیط اجرا نیاز دارد و هیچ مؤلفه دیگری لازم نیست که در جایی اجرا شود. همین الگو برای یک bucket که خودتان میزبانی می‌کنید نیز کار می‌کند. این ترکیب رایج است: 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 در آن سمت نیز باید با نسخه client سازگار باشد. اگر سمت مقابل متعلق به شما نباشد، این موضوع دردسرساز است. اگر سمت مقابل سرور دومی باشد که از قبل آن را مدیریت می‌کنید، مشکلی ایجاد نمی‌کند و در برابر باج‌افزار، قوی‌ترین کنترلی را فراهم می‌کند که هر یک از این دو ابزار ارائه می‌دهند: یک کلید SSH فقط برای افزودن. کلید را مجبور کنید borg serve را اجرا کند. در این حالت client می‌تواند archive اضافه کند، اما نمی‌تواند آن‌ها را حذف کند؛ بنابراین یک ماشین نفوذشده نمی‌تواند تاریخچه خودش را پاک کند.

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

restic فقط زمانی معادل این قابلیت را دارد که REST server خودش را اجرا کنید؛ این server از حالت فقط برای افزودن پشتیبانی می‌کند. در برابر S3 معمولی، همین نتیجه را با bucket policy یا object lock به دست می‌آورید. این قابلیت بر عهده provider است، نه restic. ارتباط انتقالی را نیز محدود کنید، زیرا بخش SSH این معماری به همان مراقبتی نیاز دارد که هر login دیگری نیاز دارد: SSH فقط با کلید و با یک ورودی محدود در authorized_keys را برای حساب backup اعمال کنید.

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

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

Borg روی SSH در پیوندی با تأخیر زیاد سریع است، زیرا بخش سمت سرور هوشمند است. کلاینت یک پرسش ارسال می‌کند، فرایند remote borg serve پاسخ را از نمایه مخزن پیدا می‌کند و تراکنش در یک محل ثبت می‌شود. جست‌وجوی chunkها برای هر فایل کوچک به رفت‌وبرگشت شبکه تبدیل نمی‌شود.

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

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

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

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

Restic به چندین کلاینت اجازه می‌دهد هم‌زمان در یک مخزن پشتیبان‌گیری کنند، زیرا عملیات پشتیبان‌گیری یک قفل اشتراکی می‌گیرد و فقط عملیات نگهداری، مانند prune، به قفل انحصاری نیاز دارند. اگر ده سرور مشابه به یک مخزن restic متصل باشند، حذف داده‌های تکراری بین آن‌ها نیز انجام می‌شود و سرور دوم و سرورهای بعدی معمولاً حجم بسیار کمی ذخیره می‌کنند. هزینه این کار، بزرگ‌تر شدن دامنه آسیب است: یک گذرواژه و یک مخزن همه داده‌ها را در خود نگه می‌دارد؛ بنابراین از دست دادن گذرواژه، همه ده نسخه را از دسترس خارج می‌کند.

نگهداشت: فراموش‌کردن و سپس 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 توجه کنید. مسیرهای داخل archive بدون slash ابتدایی ذخیره می‌شوند؛ بنابراین etc/nginx درست است، اما /etc/nginx با هیچ‌چیز مطابقت ندارد و چیزی extract نمی‌کند، بدون اینکه خطایی نشان دهد تا علت را مشخص کند. عملیات extraction همچنین در current working directory می‌نویسد؛ بنابراین ابتدا وارد یک scratch directory شوید، در غیر این صورت فایل‌های فعال را با نسخه‌های قدیمی overwrite می‌کنید.

صرف‌نظر از اینکه کدام ابزار را انتخاب می‌کنید، schedule فقط نیمی از کار است. بازیابی را در یک scratch directory و با timerای اجرا کنید که واقعاً آن را monitor می‌کنید؛ همان‌طور که walkthrough کامل در راهنمای backup با restic برای VPS این کار را با یک systemd timer انجام می‌دهد.

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

وقتی مقصد، ذخیره‌سازی شیءگرا است، وقتی می‌خواهید فقط یک باینری داشته باشید و در سمت مقصد هیچ نرم‌افزاری نصب نشود، وقتی چند ماشین باید در برابر یکدیگر حذف‌سازی داده انجام دهند، یا وقتی ممکن است شخصی که بازیابی را انجام می‌دهد خودتان نباشید، restic را انتخاب کنید. این ابزار یک باینری ایستای منفرد است که برای مخزن خود یک URL دریافت می‌کند و از نظر عملیاتی به‌سختی می‌توان گزینه بهتری پیدا کرد.

وقتی مقصد یک سامانه Linux است که کنترل آن را در اختیار دارید، وقتی اتصال تأخیر دارد و مجموعه‌داده از میلیون‌ها فایل کوچک تشکیل شده است، وقتی می‌خواهید از کلید SSH با قابلیت فقط الحاق به‌عنوان کنترلی در برابر باج‌افزار استفاده کنید، یا وقتی می‌خواهید فشرده‌سازی را برای هر کار جداگانه تنظیم کنید، Borg را انتخاب کنید. این ابزار قدیمی‌تر است، سری پایدار آن به‌آرامی پیشرفت می‌کند و در نرم‌افزار پشتیبان‌گیری، این یک مزیت محسوب می‌شود.

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

FAQ

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

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

آیا BorgBackup می‌تواند در S3 یا Backblaze B2 نسخه پشتیبان ایجاد کند؟

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

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

بله، و برخی کاربران همین کار را انجام می‌دهند: استفاده از Borg برای یک سرور دوم به‌منظور restore سریع محلی، و استفاده از restic برای نگهداری یک کپی خارج از محل در object storage. این دو ابزار هیچ داده‌ای را با یکدیگر به اشتراک نمی‌گذارند؛ بنابراین هزینه خواندن و محاسبه hash را 2 بار پرداخت می‌کنید و باید 2 password را به‌صورت ایمن نگهداری کنید. فقط زمانی این کار را انجام دهید که هر دو restore را آزمایش کرده باشید.

اگر password مربوط به repository را از دست بدهم، چه اتفاقی می‌افتد؟

در هر دو ابزار، داده‌ها غیرقابل بازیابی می‌شوند. restic کلید خود را با استفاده از password و الگوریتم scrypt ایجاد می‌کند و هیچ راهی برای دور زدن آن وجود ندارد. Borg در حالت repokey، کلید رمزگذاری‌شده را داخل repository نگهداری می‌کند؛ بنابراین فقط passphrase برای restore کافی است. در حالت keyfile، به key file موجود در ~/.config/borg/keys/ نیز نیاز دارید. password را در password managerی نگهداری کنید که روی سروری که از آن backup می‌گیرید قرار نداشته باشد. اگر از keyfile استفاده می‌کنید، کلید Borg را با borg key export export کنید.

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

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