Restic না BorgBackup: কোনটি চালাবেন?

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

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

Repository model-ই প্রকৃত পার্থক্য

একটি restic repository হলো file-এর একটি 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 যে কোনো জায়গায় পৌঁছাতে পারে—সবই সমর্থন করে।

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

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

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

S3-তে restic ব্যবহার করতে 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

দূরবর্তী repository-তে Borg ব্যবহার করতে SSH এবং remote প্রান্তে Borg install করা প্রয়োজন। সেখানে থাকা version-টি client-এর সঙ্গে compatible-ও হতে হবে। 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-এর জন্য restricted authorized_keys entry সহ key-only SSH প্রয়োগ করুন।

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

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

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

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

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

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

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

Restic একই সময়ে একাধিক client-কে একটি repository-তে ব্যাকআপ নেওয়ার অনুমতি দেয়। কারণ backup shared lock নেয়, আর prune-এর মতো কেবল maintenance কাজ exclusive lock নেয়। একই restic repository ব্যবহার করা দশটি অনুরূপ server একে অপরের ডেটার সঙ্গে deduplicate করে। ফলে দ্বিতীয় server থেকে সাধারণত খুব অল্প ডেটা সংরক্ষণ করতে হয়। এর বিনিময়ে blast radius বড় হয়: সবকিছু একটি password এবং একটি repository-র ওপর নির্ভর করে। তাই 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 চালায় না, archive list ছোট থাকলেও repository-কে ক্রমাগত বড় হতে দেয়। restic-এ forget ছাড়া --prune চালালে শুধু snapshot reference সরানো হয়; prune না চালানো পর্যন্ত data থেকে যায়।

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

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

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

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

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

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

FAQ

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

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

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 সংরক্ষণ করুন। keyfile ব্যবহার করলে borg key export দিয়ে Borg key export করুন।

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

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