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

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

Restic এবং BorgBackup উভয়ই একই মূল কাজ করে: Linux server-এর deduplicated, encrypted, incremental backup তৈরি করে। পছন্দ নির্ধারণকারী মূল পার্থক্য হলো backup কোথায় সংরক্ষিত হবে। Restic নিজস্বভাবে S3 এবং অন্যান্য object storage API ব্যবহার করতে পারে। তাই দূরের প্রান্তে কিছু install না করেই একটি bucket সরাসরি target হিসেবে ব্যবহার করা যায়। Stable Borg-এর ক্ষেত্রে repository ধারণকারী machine-এ 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-এ data encrypt করে। উভয়ই FUSE (filesystem in userspace) ব্যবহার করে snapshot mount করে, যাতে সেখান থেকে একটি file copy করা যায়। October 2026 অনুযায়ী restic-এর version 0.19.1 এবং Borg-এর stable series 1.4; সর্বশেষ version 1.4.5। Borg 2.0 বহু বছর ধরে beta অবস্থায় আছে এবং এখনও testing only হিসেবে চিহ্নিত। তাই আজ 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 যে কোনো জায়গায় পৌঁছাতে পারে এমন অন্যান্য backend সমর্থন করে।

একটি Borg repository-ও disk-এ থাকা file-এর সমষ্টি। তবে Borg কখনো dumb transport-এর মাধ্যমে এটির সঙ্গে যোগাযোগ করে না। Remote repository-এর ক্ষেত্রে Borg SSH-এর মাধ্যমে অপর প্রান্তে borg serve চালু করে এবং সেই process-এর সঙ্গে নিজস্ব protocol-এ যোগাযোগ করে। Server side বাস্তব কাজ করে: এটি repository সংরক্ষণ করে, transaction প্রয়োগ করে এবং index-সংক্রান্ত প্রশ্নের উত্তর দেয়। এ কারণেই stable Borg 1.4 series-এ S3 backend নেই। Bucket-এর ভেতরে চালানোর মতো কোনো process নেই। Borg 2 এই নকশা পরিবর্তন করে: এটি storage-কে borgstore নামের একটি নতুন layer-এ সরিয়ে নেয়, এবং এর documentation-এ sftp://, rclone:remote:path এবং s3: অথবা b2: repository URL বর্ণনা করা হয়েছে। তবে Borg 2 এখনও beta পর্যায়ে আছে এবং project-এর নির্দেশনা অনুযায়ী এটি production-এ ব্যবহার করা উচিত নয়। তাই আজকের বাস্তব backup-এর ক্ষেত্রে 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

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 আবার অতিরিক্তভাবে compress না হয়।

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

Repository format 2 না আসা পর্যন্ত restic-এ কোনো compression ছিল না। এর জন্য restic 0.14.0 বা পরবর্তী version প্রয়োজন। নতুন repository-এর জন্য এখন format 2 ডিফল্ট, এবং --compression ব্যবহার করে পাঁচটি value-এর একটি নির্ধারণ করা যায়: auto (ডিফল্ট), off, fastest, better অথবা max। fastest এবং better mode restic 0.19.0-এ যুক্ত হয়েছে। তাই পুরোনো binary শুধু auto, off এবং max গ্রহণ করে। পুরোনো 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 ও hash speed-ই শেষ পর্যন্ত উভয়ের গতি সীমিত করে। অনেক ছোট file নিয়ে উচ্চ latency-র SSH link ব্যবহার করলে Borg সাধারণত এগিয়ে থাকে, কারণ দূরের প্রান্তে থাকা borg serve process প্রতিটি chunk-এর জন্য network round trip ছাড়াই index-সংক্রান্ত প্রশ্নের উত্তর দেয়। Target হিসেবে object storage ব্যবহার করলে restic সাধারণত এগিয়ে থাকে, কারণ stable Borg সেখানে একেবারেই চলতে পারে না।

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

Stable 1.4 series-এ পারে না। Borg 1.4 repository SSH-এর মাধ্যমে borg serve process পরিবেশন করে, আর bucket-এর ভেতরে এমন কোনো process চলে না। Borg 2 তার borgstore layer-এর মাধ্যমে s3:, b2: এবং rclone: repository URL যোগ করে, কিন্তু October 2026 অনুযায়ী Borg 2 এখনও beta এবং project production-এ এটি ব্যবহার না করতে বলেছে। 1.4 ব্যবহারকারীরা rclone দিয়ে object storage-কে filesystem হিসেবে mount করে এই সীমাবদ্ধতা এড়ান। Borg FAQ repository storage-এর জন্য network filesystem ব্যবহার না করার পরামর্শ দেয় এবং সতর্ক করে যে FUSE ও network filesystem ধীরগতি বা corruption ঘটাতে পারে। আজ production backup-এর জন্য object storage প্রয়োজন হলে restic ব্যবহার করুন।

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

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

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

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

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

না। October 2026 অনুযায়ী Borg 2.0 এখনও beta, এবং project এটিকে testing only হিসেবে চিহ্নিত করেছে। Stable series হলো 1.4, বর্তমানে 1.4.5। এখনই 1.4 দিয়ে শুরু করুন। Borg 2 repository format পরিবর্তন করে এবং একটি documented upgrade path সরবরাহ করে (borg transfer --from-borg1), তাই আজ শুরু করলে পরে আটকে পড়তে হবে না। Stable হওয়ার পর native S3, B2 এবং rclone support-ও Borg 2-এ আসবে।