Restic বনাম BorgBackup: কোনটি ব্যবহার করবেন?

Restic বনাম BorgBackup, এক অনুচ্ছেদে

Restic এবং BorgBackup উভয়ই Linux server-এর একই মূল কাজ করে: deduplicated, encrypted এবং incremental backup তৈরি করে। কোনটি বেছে নেবেন, তা নির্ধারণ করে backup কোথায় সংরক্ষিত হবে। Restic স্থানীয়ভাবে S3 এবং অন্যান্য object storage API সমর্থন করে। তাই দূরের প্রান্তে কিছু install না করেই একটি bucket সরাসরি target হিসেবে ব্যবহার করা যায়। যে machine-এ repository রাখা হবে, সেখানে Borg-এর borg program install করতে হয়। কারণ Borg repository কোনো filesystem বা API নয়; এটি একটি process দ্বারা পরিবেশিত হয়। আপনার target যদি object storage হয়, তাহলে এটিই সিদ্ধান্তের উত্তর। আর target যদি আপনার নিয়ন্ত্রণে থাকা দ্বিতীয় একটি Linux box হয়, তাহলে Borg ব্যবহার করা যায় এবং এটি প্রায়ই দ্রুততর।

অন্য সব পার্থক্য তুলনামূলকভাবে ছোট। উভয়ই content-defined chunking ব্যবহার করে file-কে ভাগ করে। তাই 40 GB-এর একটি directory-তে 200 MB পরিবর্তন হলে প্রায় 200 MB upload হয়। উভয়ই client side-এ encryption করে। উভয় ক্ষেত্রেই FUSE (filesystem in userspace) দিয়ে snapshot mount করা যায়, যাতে সেখান থেকে একটি file copy করে নেওয়া সম্ভব হয়। July 2026 অনুযায়ী restic-এর version 0.19.1 এবং Borg-এর stable series 1.4, যার সর্বশেষ version 1.4.5। Borg 2.0 বহু বছর ধরে beta অবস্থায় আছে এবং এখনও শুধু testing-এর জন্য চিহ্নিত। তাই আজ deploy করার জন্য 1.4 ব্যবহার করা উচিত।

রিপোজিটরি মডেলই প্রকৃত পার্থক্য

একটি restic repository হলো ফাইলের একটি directory: config, keys/, snapshots/, index/ এবং data/। এগুলোতে pack file থাকে। এটি পড়ার জন্য অন্য কিছু প্রয়োজন হয় না। এই কারণে restic এত ধরনের backend ব্যবহার করতে পারে। যে কোনো store blob লিখতে, পড়তে, তালিকাভুক্ত করতে এবং মুছতে পারলে সেখানে restic repository রাখা যায়। এভাবেই একটি binary local path, SFTP, নিজস্ব REST server, S3, Backblaze B2, Azure, Google Cloud Storage এবং rclone যে কোনো reachable storage সমর্থন করতে পারে।

Borg repository-ও disk-এ থাকা ফাইলের সমষ্টি। তবে Borg কখনো সরল transport-এর মাধ্যমে এর সঙ্গে যোগাযোগ করে না। Remote repository-এর ক্ষেত্রে Borg SSH ব্যবহার করে অপর প্রান্তে borg serve চালায় এবং সেই process-এর সঙ্গে নিজস্ব protocol-এ যোগাযোগ করে। Server side বাস্তব কাজ সম্পন্ন করে: এটি repository ধরে রাখে, transaction প্রয়োগ করে এবং index-সংক্রান্ত প্রশ্নের উত্তর দেয়। এই কারণে Borg-এর কোনো S3 backend নেই এবং project-টি এমন 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

Encryption: এর মধ্যে একটি বন্ধ করা যায়

Restic সবসময় encrypted থাকে। Unencrypted mode নেই। restic init একটি password চায়, scrypt ব্যবহার করে password থেকে key তৈরি করে, এবং এরপর লেখা প্রতিটি pack file encrypted ও authenticated থাকে। Password হারালে data-ও হারাবে, কারণ নকশা অনুযায়ী recovery path নেই।

Borg repository তৈরির সময় encryption বেছে নেওয়ার সুযোগ দেয়, এবং এই পছন্দ স্থায়ী। borg init --encryption=repokey encrypted key repository-এর ভেতরে রাখে, তাই শুধু passphrase দিয়েই restore করা যায়। --encryption=keyfile key-টি client-এর ~/.config/borg/keys/-এ রাখে। ফলে কেউ পুরো repository চুরি করলেও তার কাছে key থাকে না। তবে সেই key file আলাদাভাবে backup করতে হবে, নইলে archive পড়া যাবে না। প্রতিটি mode-এর একটি -blake2 variant আছে, যেখানে HMAC-SHA256-এর পরিবর্তে BLAKE2b দিয়ে authentication করা হয়। SHA acceleration নেই এমন hardware-এ এটি দ্রুততর। --encryption=none-ও আছে, এবং repository আপনার মালিকানাধীন encrypted disk-এ থাকলে এটি একটি বাস্তবসম্মত পছন্দ।

ব্যবহারিক নিয়ম: সাধারণ server backup-এর জন্য repokey-blake2 ব্যবহার করুন, repository সম্পূর্ণভাবে বিশ্বস্ত নয় এমন জায়গায় থাকলে keyfile ব্যবহার করুন, এবং rented machine-এ কখনো none ব্যবহার করবেন না।

Compression এবং কেন restic-এ এটি দেরিতে এসেছে

Borg শুরু থেকেই compression সমর্থন করে। ডিফল্ট হলো lz4, যা যথেষ্ট দ্রুত হওয়ায় সব ক্ষেত্রেই চালু রাখা যায়। zstd 1 থেকে 22 পর্যন্ত level গ্রহণ করে এবং ডিফল্ট হিসেবে 3 ব্যবহার করে। zlib এবং lzma এমন পরিস্থিতির জন্য, যেখানে সময়ের চেয়ে byte কমানো বেশি গুরুত্বপূর্ণ। auto প্রতিটি chunk-এর জন্য একটি heuristic চালায়, তাই আগে থেকেই compressed data দ্বিতীয়বার অতিরিক্তভাবে সংকুচিত হয় না।

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

repository format 2 আসার আগে restic-এ কোনো compression ছিল না। এর জন্য restic 0.14.0 বা পরবর্তী সংস্করণ প্রয়োজন। বর্তমানে নতুন repository-এর জন্য format 2 ডিফল্ট, এবং --compression-এর মাধ্যমে auto, off অথবা max value সেট করে compression নির্ধারণ করা হয়। পুরোনো format 1 repository migrate না করা পর্যন্ত uncompressed থাকে। তাই আপনার restic repository যদি 0.14-এর আগের হয় এবং আপনি সেটি কখনও migrate না করে থাকেন, তাহলে text, log এবং database dump-এর জন্য এখনও সম্পূর্ণ size-এর storage ব্যবহার হচ্ছে।

দূরবর্তী target: S3 বনাম SSH

সাধারণত এখানেই সিদ্ধান্ত নেওয়া হয়।

Restic-এর S3-এ সংযোগের জন্য environment-এ credentials থাকা যথেষ্ট; অন্য কোথাও আর কোনো service চালু রাখার প্রয়োজন নেই। আপনি নিজে host করা bucket-এর ক্ষেত্রেও একই পদ্ধতি কাজ করে। এটি একটি প্রচলিত সমন্বয়: নিজের VPS-এ S3 API-এর জন্য MinIO চালান এবং 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-এর remote repository-তে সংযোগের জন্য SSH এবং remote প্রান্তে Borg install থাকা দরকার। সেখানে থাকা version-টি client-এর সঙ্গে compatible হওয়াও প্রয়োজন। remote প্রান্তটি আপনার নিয়ন্ত্রণে না থাকলে এটি অতিরিক্ত জটিলতা তৈরি করে। কিন্তু remote প্রান্তটি আপনার পরিচালিত দ্বিতীয় server হলে এতে কোনো সমস্যা নেই। বরং ransomware-এর বিরুদ্ধে এটি যেকোনো tool-এর মধ্যে সবচেয়ে শক্তিশালী নিয়ন্ত্রণ দেয়: একটি append-only SSH key। Key-টিকে borg serve চালানোর জন্য সীমাবদ্ধ করুন। তাহলে client archive যোগ করতে পারবে, কিন্তু সেগুলো delete করতে পারবে না। ফলে কোনো breached machine নিজের backup history মুছে ফেলতে পারবে না।

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

Restic-এ এর সমতুল্য ব্যবস্থা কেবল নিজস্ব REST server চালালে পাওয়া যায়; সেটি append-only mode সমর্থন করে। সাধারণ S3-এর ক্ষেত্রে bucket policy বা object lock ব্যবহার করে একই ফল পাওয়া যায়। এটি provider-এর দায়িত্ব, restic-এর নয়। Transport-ও যথেষ্ট সীমাবদ্ধ রাখুন। SSH-এর দিকটিও অন্য যেকোনো login-এর মতো একই সতর্কতা দাবি করে: backup account-এর জন্য সীমাবদ্ধ authorized_keys entry ব্যবহার করে কেবল key-ভিত্তিক SSH প্রয়োগ করুন।

গতি: প্রতিটি নকশার প্রভাব

কোনো প্রকল্পই আপনার নিজস্ব ডেটার জন্য নির্ভরযোগ্য benchmark প্রকাশ করে না। তাই ব্যবস্থাটির কার্যপ্রণালি থেকে সিদ্ধান্ত নিন।

latency বেশি এমন link-এ SSH-এর মাধ্যমে Borg দ্রুত, কারণ server side বুদ্ধিমানভাবে কাজ করে। client একটি প্রশ্ন পাঠায়, remote borg serve process repository index থেকে তার উত্তর দেয়, এবং transaction এক জায়গাতেই commit হয়। প্রতিটি ছোট file-এর জন্য chunk lookup-কে আলাদা network round trip-এ পরিণত হতে হয় না।

object storage-এ Restic-এর কোনো server side নেই। তাই HTTP-এর মাধ্যমে আনা index file ও pack file থেকে তাকে নিজের চিত্র তৈরি করতে হয়। request-এর সংখ্যা নিয়ন্ত্রণে রাখতে upload-এর আগে এটি অনেক ছোট chunk-কে বড় pack file-এ একত্র করে। পরবর্তী run-এ যাতে পুরো index আবার fetch করতে না হয়, সে জন্য ~/.cache/restic-এ একটি local cache রাখে। সেই cache মুছে দিলে পরবর্তী backup ধীর হবে, কারণ cache আবার তৈরি করতে হবে। latency বেশি এমন link-এ millions of ছোট file থাকলে একই data-তে Borg-এর তুলনায় restic ধীর মনে হওয়ার এটি সেই পরিস্থিতি।

local disk বা দ্রুত LAN-এ পার্থক্যটি বেশির ভাগই কমে যায়। তখন উভয় tool-এর গতি মূলত source কত দ্রুত পড়তে ও hash করতে পারে, তার ওপর সীমাবদ্ধ থাকে।

একাধিক মেশিন লক করা এবং ব্যাকআপ নেওয়া

Borg 1.4 পুরো অপারেশন চলাকালে repository-তে exclusive lock নেয়। একই সময়ে একটি repository-তে দুইটি client লিখতে পারে না: দ্বিতীয় client অপেক্ষা করে, তারপর lock timeout-এর কারণে ব্যর্থ হয়। সমর্থিত পদ্ধতি হলো প্রতিটি client-এর জন্য একটি করে repository ব্যবহার করা। এর মানে, deduplication শুধু একটি মেশিনের repository-এর ভেতরেই হয়। তাই প্রায় একই রকম দশটি server একই base system-এর দশটি কপি সংরক্ষণ করে।

Restic একই সময়ে একাধিক client-কে একটি repository-তে ব্যাকআপ নেওয়ার অনুমতি দেয়। কারণ ব্যাকআপ shared lock নেয়, আর শুধু prune-এর মতো maintenance কাজ exclusive lock নেয়। একই restic repository-তে নির্দেশিত দশটি একই ধরনের server একে অপরের ডেটার বিপরীতে deduplication করে। ফলে দ্বিতীয় server থেকে শুরু করে পরবর্তী server-গুলোর ডেটা প্রায় সংরক্ষণ নাও করতে পারে। এর বিনিময়ে blast radius বড় হয়: সবকিছু ধারণকারী একটি repository এবং একটি password থাকে। তাই password হারালে দশটি server-এর সব ব্যাকআপ হারাবেন।

Retention: forget ও prune বনাম prune ও compact

উভয় tool-ই “কী রাখা হবে তা নির্ধারণ” এবং “জায়গা পুনরুদ্ধার” আলাদা ধাপে করে, এবং উভয় ক্ষেত্রেই দ্বিতীয় ধাপটি আপনাকেই চালাতে হয়।

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

উভয় tool-এই একই ফাঁদ আছে, তাই বিষয়টি স্পষ্টভাবে বলা দরকার। Borg-এ borg prune archive সরিয়ে দেয়, কিন্তু নিজে থেকে disk space মুক্ত করে না। borg compact চলার পর space ফিরে আসে। তাই যে cron job prune চালায় কিন্তু কখনো compact করে না, সেটি এমন একটি repository রেখে যায় যা ক্রমেই বড় হতে থাকে, যদিও archive list ছোট থাকে। restic-এ forget চালিয়ে --prune না চালালে শুধু snapshot reference সরানো হয়; data থেকে যায়, যতক্ষণ না prune চালানো হয়।

Prune করার পরে restic check চালান। এটি repository structure যাচাই করে এবং কোনো ক্ষতি হয়েছে কি না জানায়। Restore-এর সময় সমস্যা আবিষ্কার করার চেয়ে এটি অনেক ভালো।

পুনরুদ্ধারই একমাত্র পরীক্ষা, যেটিই আসল

উভয় টুল snapshot mount করে, যাতে আপনি সেটি browse করতে পারেন। একটি ফাইল দ্রুত ফিরিয়ে আনার এটাই সবচেয়ে সহজ উপায়।

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-এ path-এর গঠনটি লক্ষ্য করুন। Archive-এর ভেতরের path-গুলো শুরুর slash ছাড়া সংরক্ষিত হয়। তাই etc/nginx সঠিক, কিন্তু /etc/nginx কোনো কিছুর সঙ্গে মেলে না এবং কিছুই extract করে না। কেন এমন হয়েছে, তা জানানোর জন্য কোনো error-ও দেখায় না। Extraction বর্তমান working directory-তে লেখে। তাই আগে একটি scratch directory-তে যান। তা না হলে পুরোনো ফাইল দিয়ে live file overwrite হয়ে যাবে।

কোনো error ছাড়া restore শেষ হলেও সেটিকে প্রমাণ হিসেবে ধরা যায় না। কারণ restore সম্পূর্ণ হয়েছে কি না, সে সম্পর্কে উপরের application-এর নিজস্ব প্রত্যাশা থাকে। যেমন, Postgres data directory-এর একটি copy থেকে পুনর্নির্মিত Immich server-এ disk-এ সব photo উপস্থিত থাকতে পারে, কিন্তু timeline-এ কিছুই দেখা নাও যেতে পারে। এই ব্যর্থতাই Immich backup ও restore-কে এড়াতে হয়।

আপনি যে tool-ই বেছে নিন, schedule কাজের অর্ধেক মাত্র। এমন একটি timer-এ scratch directory-তে restore চালান, যেটি আপনি বাস্তবে monitor করেন। VPS-এর restic backup guide-এর সম্পূর্ণ walkthrough-তেও systemd timer দিয়ে একইভাবে এটি করা হয়েছে।

কোন কাজের জন্য কোনটি উপযুক্ত

Target যদি object storage হয়, আপনি যদি একটি binary ব্যবহার করতে চান এবং দূরের প্রান্তে কোনো software ইনস্টল করতে না চান, একাধিক machine-এর backup যেন পরস্পরের সঙ্গে deduplicate হয়, অথবা restore করবেন এমন ব্যক্তি আপনি নাও হতে পারেন—তাহলে restic বেছে নিন। এটি repository-এর জন্য একটি URL-সহ একক static binary। Operational দিক থেকে এটিকে হারানো কঠিন।

Target যদি আপনার নিয়ন্ত্রণে থাকা একটি Linux box হয়, link-এ latency থাকে এবং dataset-এ লক্ষ লক্ষ ছোট file থাকে, ransomware-এর বিরুদ্ধে নিয়ন্ত্রণ হিসেবে append-only SSH key ব্যবহার করতে চান, অথবা প্রতিটি job-এর জন্য compression আলাদাভাবে নির্ধারণ করতে চান—তাহলে Borg বেছে নিন। এটি পুরোনো tool। এর stable series ধীরে পরিবর্তিত হয়। Backup software-এর ক্ষেত্রে এটি একটি সুবিধা।

দুটিই সঠিক উত্তর। ভুল উত্তর হলো যেটি আপনি কখনো test করেননি। আপনি যদি ইতিমধ্যে application-level dump নেন, সেগুলো চালু রাখুন: database dump-সহ Nextcloud on Docker setup-এর পদ্ধতি উভয় tool-এর ক্ষেত্রেই প্রযোজ্য। কারণ এলোমেলো কোনো সময়ে live database file copy করলে সেটি database-এর backup হয় না।

FAQ

restic নাকি BorgBackup, কোনটি দ্রুত?

লোকাল disk বা দ্রুত LAN-এ দুটির গতি কাছাকাছি। উভয় ক্ষেত্রেই source-এর read speed এবং hash speed সীমাবদ্ধতা তৈরি করে। অনেক ছোট file থাকলে high-latency SSH link-এ Borg সাধারণত এগিয়ে থাকে। কারণ দূরের প্রান্তের borg serve process প্রতিটি chunk-এর জন্য network round trip ছাড়াই index-এর প্রশ্নের উত্তর দেয়। Target যদি object storage হয়, তাহলে restic সাধারণত এগিয়ে থাকে। Borg সরাসরি object storage-এ কাজ করতে পারে না।

BorgBackup কি S3 বা Backblaze B2-এ backup নিতে পারে?

সরাসরি পারে না। একটি Borg repository SSH-এর মাধ্যমে borg serve process দ্বারা পরিবেশিত হয়। Bucket-এর ভেতরে এ ধরনের কোনো process চলে না। কেউ কেউ rclone ব্যবহার করে object storage-কে filesystem হিসেবে mount করে এই সীমাবদ্ধতা এড়ানোর চেষ্টা করেন। Borg project এই পদ্ধতি সুপারিশ করে না। কারণ transaction চলাকালে mount সংযোগ বিচ্ছিন্ন হলে repository নষ্ট হতে পারে। Object storage প্রয়োজন হলে restic ব্যবহার করুন।

একই data-র বিরুদ্ধে কি আমি উভয় tool চালাতে পারি?

হ্যাঁ, এবং কেউ কেউ তা করেন। দ্রুত local restore-এর জন্য Borg দ্বিতীয় server-এ রাখা যায়। Offsite copy-এর জন্য restic object storage-এ রাখা যায়। তারা কোনো data বা metadata ভাগ করে না। তাই read এবং hash-এর খরচ দুবার হয়। নিরাপদে সংরক্ষণের জন্য দুটি password-ও লাগে। উভয় restore পরীক্ষা করে থাকলেই এই পদ্ধতি ব্যবহার করুন।

Repository password হারালে কী হয়?

উভয় tool-এই data পুনরুদ্ধার করা যায় না। Restic password থেকে scrypt ব্যবহার করে key তৈরি করে। এটি এড়ানোর কোনো উপায় নেই। Borg-এর repokey mode-এ encrypted key repository-র ভেতরে সংরক্ষিত থাকে। তাই passphrase থাকলেই restore করা যায়। keyfile mode-এ ~/.config/borg/keys/ থেকে key file-ও প্রয়োজন হয়। যে server-এর backup নেওয়া হচ্ছে, সেই server-এ password manager রাখবেন না। Password এমন একটি password manager-এ রাখুন, যা ওই server-এ নেই। keyfile ব্যবহার করলে borg key export দিয়ে Borg key export করুন।

Borg 2.0-এর জন্য কি অপেক্ষা করা উচিত?

না। July 2026 অনুযায়ী Borg 2.0 এখনও beta অবস্থায় আছে এবং version 2.0.0b22। Project এটিকে testing only হিসেবে চিহ্নিত করেছে। Stable series হলো 1.4, যার বর্তমান version 1.4.5। এখনই 1.4 দিয়ে শুরু করুন। Borg 2 repository format পরিবর্তন করে এবং documented upgrade path সরবরাহ করে। তাই আজ শুরু করলে ভবিষ্যতে আটকে পড়বেন না।