مقایسه 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ها را ذخیره، بازیابی، لیست و حذف کند، می‌تواند میزبان یک مخزن restic باشد. این همان دلیلی است که یک باینری واحد از مسیرهای محلی، SFTP، سرور REST اختصاصی خود، S3، Backblaze B2، Azure، Google Cloud Storage و هر چیزی که rclone به آن دسترسی دارد، پشتیبانی می‌کند.

یک مخزن Borg نیز شامل فایل‌هایی روی دیسک است، اما Borg هرگز از طریق یک انتقال‌دهنده ساده (dumb transport) با آن ارتباط برقرار نمی‌کند. برای یک مخزن راه دور، Borg برنامه borg serve را در سمت مقصد از طریق SSH اجرا کرده و با آن پردازش، پروتکل اختصاصی خود را صحبت می‌کند. سمت سرور کار واقعی انجام می‌دهد: مخزن را نگه می‌دارد، تراکنش‌ها را اعمال می‌کند و به پرسش‌های مربوط به ایندکس پاسخ می‌دهد. به همین دلیل است که سری پایدار Borg 1.4 فاقد backend برای S3 است. هیچ پردازشی برای اجرا در داخل یک bucket وجود ندارد. Borg 2 این وضعیت را تغییر می‌دهد: ذخیره‌سازی را به لایه جدیدی به نام borgstore منتقل می‌کند و مستندات آن، URLهای مخزن sftp://، rclone:remote:path و s3: یا b2: را توصیف می‌کنند. با این حال، Borg 2 هنوز در مرحله بتا است و تیم پروژه توصیه می‌کند از آن در محیط عملیاتی (production) استفاده نشود؛ بنابراین برای پشتیبان‌گیری‌های واقعی در حال حاضر، شکاف 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 کلید رمزنگاری‌شده را درون مخزن نگه می‌دارد، بنابراین تنها با استفاده از عبارت عبور (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 یک تحلیل اکتشافی روی هر قطعه (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 در نسخه 0.19.0 به restic اضافه شدند، بنابراین نسخه‌های قدیمی‌تر فقط مقادیر auto، off و max را می‌پذیرند. مخازن قدیمی با فرمت 1 تا زمانی که آن‌ها را مهاجرت (migrate) ندهید، بدون فشرده‌سازی باقی می‌مانند. بنابراین اگر مخزن 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 پشتیبان بگیرد؟

خیر، در سری پایدار 1.4 این امکان وجود ندارد. مخزن (repository) نسخه 1.4 توسط پردازش borg serve از طریق SSH سرویس‌دهی می‌شود و چنین پردازشی درون یک bucket اجرا نمی‌شود. Borg 2 از طریق لایه borgstore خود، URLهای مخزن s3:، b2: و rclone: را اضافه می‌کند، اما تا اکتبر 2026، نسخه Borg 2 همچنان در مرحله بتا است و پروژه توصیه می‌کند از آن در محیط عملیاتی (production) استفاده نشود. در نسخه 1.4، کاربران با mount کردن object storage به عنوان یک فایل‌سیستم توسط rclone، این محدودیت را دور می‌زنند. FAQ مربوط به Borg، استفاده از فایل‌سیستم‌های شبکه‌ای برای ذخیره‌سازی مخزن را توصیه نمی‌کند و هشدار می‌دهد که FUSE و فایل‌سیستم‌های شبکه‌ای می‌توانند باعث کندی یا خرابی داده‌ها شوند. اگر امروز برای پشتیبان‌گیری عملیاتی به object storage نیاز دارید، از restic استفاده کنید.

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

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

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

در هر دو ابزار، داده‌ها غیرقابل بازیابی خواهند بود. 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.0b25 (منتشرشده در 27 سپتامبر 2026) است و پروژه آن را فقط برای تست برچسب‌گذاری کرده است. سری پایدار، نسخه 1.4 است که در حال حاضر 1.4.5 می‌باشد. کار را همین حالا با 1.4 شروع کنید. Borg 2 فرمت مخزن را تغییر می‌دهد و یک مسیر ارتقای مستند (borg transfer --from-borg1) ارائه می‌دهد، بنابراین شروع کار از امروز شما را در بن‌بست قرار نمی‌دهد. همچنین، پشتیبانی بومی از S3، B2 و rclone زمانی که Borg 2 پایدار شود، در آن گنجانده شده است.