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

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

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

বাকি পার্থক্যগুলো তুলনামূলকভাবে ছোট। উভয় tool-ই content-defined chunking ব্যবহার করে file ভাগ করে। তাই 40 GB directory-তে 200 MB পরিবর্তন হলে প্রায় 200 MB upload হয়। উভয় tool-ই client side-এ encryption করে। উভয় tool-ই 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 only হিসেবে চিহ্নিত। তাই আজ deploy করার জন্য 1.4 ব্যবহার করা উচিত।

মূল পার্থক্য হলো repository মডেল

একটি 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 যে কোনো গন্তব্যে পৌঁছাতে পারে।

Borg repository-ও disk-এ থাকা ফাইলের সমষ্টি। তবে 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

এনক্রিপশন: এদের একটি বন্ধ করা যায়

Restic সবসময় এনক্রিপ্ট করা থাকে। এনক্রিপশন ছাড়া কোনো মোড নেই। restic init একটি পাসওয়ার্ড চায়, scrypt ব্যবহার করে সেই পাসওয়ার্ড থেকে একটি ক্রিপ্টোগ্রাফিক কী তৈরি করে, এবং এরপর লেখা প্রতিটি pack file এনক্রিপ্ট ও authenticated থাকে। পাসওয়ার্ড হারালে ডেটা নষ্ট হয়ে যায়, কারণ নকশা অনুযায়ী কোনো পুনরুদ্ধারের পথ নেই।

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

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

কম্প্রেশন, এবং restic কেন এটি দেরিতে যোগ করেছে

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

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

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

দূরবর্তী লক্ষ্য: S3 বনাম SSH

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

S3-তে restic সংযোগ করতে পরিবেশে credentials থাকা দরকার; অন্য কোথাও অতিরিক্ত কিছু চালানোর প্রয়োজন নেই। আপনি নিজে পরিচালিত 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 এবং অপর প্রান্তে Borg ইনস্টল করা থাকা দরকার। সেখানে থাকা সংস্করণটি client-এর সঙ্গে সামঞ্জস্যপূর্ণও হতে হবে। অপর প্রান্তটি আপনার নিয়ন্ত্রণে না থাকলে এটি অতিরিক্ত জটিলতা তৈরি করে। তবে অপর প্রান্তটি আপনার পরিচালিত দ্বিতীয় server হলে এটি কোনো সমস্যা নয়। এর বিনিময়ে ransomware প্রতিরোধে উভয় tool-এর মধ্যে সবচেয়ে শক্তিশালী নিয়ন্ত্রণটি পান: append-only SSH key। key-টিকে borg serve চালানোর জন্য বাধ্য করুন। তাহলে client archive যোগ করতে পারবে, কিন্তু সেগুলো মুছতে পারবে না। ফলে কোনো 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 প্রয়োগ করুন।

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

কোনও প্রকল্পই আপনার নিজস্ব ডেটার জন্য নির্ভরযোগ্য বেঞ্চমার্ক প্রকাশ করে না। তাই প্রক্রিয়াটি বিবেচনা করে সিদ্ধান্ত নিন।

ল্যাটেন্সিযুক্ত লিঙ্কে Borg over SSH দ্রুত, কারণ সার্ভার-প্রান্তে বুদ্ধিমান প্রক্রিয়াকরণ থাকে। ক্লায়েন্ট একটি প্রশ্ন করে, রিমোট borg serve প্রক্রিয়া রিপোজিটরি ইনডেক্স থেকে তার উত্তর দেয়, এবং ট্রানজ্যাকশন এক জায়গাতেই কমিট হয়। প্রতিটি ছোট ফাইলের জন্য chunk lookup-কে আলাদা network round trip-এ পরিণত হতে হয় না।

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

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

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

Borg 1.4 পুরো অপারেশনজুড়ে repository-তে exclusive lock নেয়। একই সময়ে দুইটি client একটি repository-তে লিখতে পারে না: দ্বিতীয়টি অপেক্ষা করে, তারপর 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 বাড়ে: একটি password এবং সবকিছু ধারণকারী একটি repository থাকে। তাই password হারালে দশটি server-এর সব ব্যাকআপ হারিয়ে যায়।

Retention: ভুলে যাওয়া ও 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 archive সরিয়ে দেয়, কিন্তু নিজে থেকে disk space মুক্ত করে না। borg compact চললে space ফিরে আসে। তাই যে cron job শুধু prune চালায় এবং কখনও compact চালায় না, সেটি এমন repository রেখে যায় যা archive তালিকা ছোট থাকা সত্ত্বেও অনন্তকাল বড় হতে থাকে। restic-এ --prune ছাড়া forget শুধু snapshot reference সরিয়ে দেয়। prune না চলা পর্যন্ত data থেকে যায়।

prune চালানোর পরে restic check চালান। এটি repository-র কাঠামো যাচাই করে এবং কোনো ক্ষতি থাকলে তা জানায়। 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 হয়ে যাবে।

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

কোন কাজের জন্য কোনটি বেশি উপযোগী

টার্গেট যদি object storage হয়, যদি আপনি একটি binary ব্যবহার করতে চান এবং দূরের প্রান্তে কোনো software রাখতে না চান, যদি একাধিক machine-এর মধ্যে deduplication করতে চান, অথবা restore করবেন এমন ব্যক্তি আপনি নাও হতে পারেন, তাহলে restic বেছে নিন। এটি একটি একক static binary, যার repository নির্দিষ্ট করতে একটি URL লাগে। পরিচালনাগত দিক থেকে এটিকে অতিক্রম করা কঠিন।

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

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

FAQ

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

স্থানীয় ডিস্ক বা দ্রুত LAN-এ দুটির গতি কাছাকাছি। উভয়ের গতি শেষ পর্যন্ত source-এর read এবং hash speed দ্বারা সীমাবদ্ধ থাকে। অনেক ছোট ফাইলসহ উচ্চ-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 scrypt দিয়ে password থেকে key তৈরি করে। এর কোনো bypass নেই। Borg-এর repokey mode-এ encrypted key repository-র ভিতরে সংরক্ষিত থাকে। তাই restore করতে শুধু passphrase যথেষ্ট। keyfile mode-এ ~/.config/borg/keys/ থেকে key file-ও প্রয়োজন। Password এমন একটি password manager-এ রাখুন, যা যে server-এর backup নেওয়া হচ্ছে সেই server-এ থাকে না। keyfile ব্যবহার করলে borg key export দিয়ে Borg key export করুন।

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

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