Restic की BorgBackup: कोणता backup चालवावा?

Restic विरुद्ध BorgBackup, एका परिच्छेदात

Restic आणि BorgBackup ही दोन्ही Linux सर्व्हरची deduplicated, encrypted आणि incremental backups घेण्याचे समान मूलभूत काम करतात. निवड ठरवणारा मुख्य फरक म्हणजे backup कुठे साठवला जातो. Restic मध्ये S3 आणि इतर object storage APIs साठी native support आहे. त्यामुळे दूरच्या बाजूला काहीही install न करता bucket हा थेट target म्हणून वापरता येतो. Repository ज्या मशीनवर आहे, त्या मशीनवर Borg साठी borg program install केलेले असणे आवश्यक आहे. कारण Borg repository filesystem किंवा API द्वारे नव्हे, तर process द्वारे उपलब्ध करून दिली जाते. तुमचा target object storage असेल, तर उत्तर स्पष्ट आहे. तुमचा target तुमच्या नियंत्रणातील दुसरा Linux box असेल, तर Borg योग्य पर्याय आहे आणि तो अनेकदा अधिक वेगवान असतो.

इतर सर्व फरक तुलनेने लहान आहेत. दोन्हीमध्ये content-defined chunking वापरून files चे विभाजन केले जाते. त्यामुळे 200 MB ने बदललेली 40 GB directory असेल, तर साधारण 200 MB upload होतो. दोन्ही client वर encryption करतात. दोन्ही FUSE (filesystem in userspace) वापरून snapshot mount करतात, त्यामुळे त्यातून एक file copy करता येते. July 2026 पर्यंत restic ची आवृत्ती 0.19.1 आहे आणि Borg ची stable series 1.4 असून आवृत्ती 1.4.5 आहे. Borg 2.0 अनेक वर्षांपासून beta मध्ये आहे आणि अजूनही फक्त testing साठी असल्याचे नमूद केले आहे. त्यामुळे आज deploy करण्यासाठी 1.4 हीच आवृत्ती वापरावी.

रिपॉझिटरी मॉडेल हाच खरा फरक आहे

restic रिपॉझिटरी ही फाइल्सची एक directory असते: config, keys/, snapshots/, index/ आणि data/; त्यामध्ये pack files असतात. ती वाचण्यासाठी याशिवाय दुसरे काहीही आवश्यक नसते. म्हणूनच restic अनेक backend सह काम करू शकते. blobs put, get, list आणि delete करू शकणाऱ्या कोणत्याही store मध्ये restic रिपॉझिटरी ठेवता येते. त्यामुळे एकच binary local paths, SFTP, स्वतःचा REST server, S3, Backblaze B2, Azure, Google Cloud Storage आणि rclone ज्या कोणत्याही ठिकाणी पोहोचू शकते तिथे काम करू शकते.

Borg रिपॉझिटरी देखील disk वरील files असते; परंतु Borg तिच्याशी साध्या transport द्वारे कधीही संवाद साधत नाही. Remote repository साठी Borg SSH द्वारे दूरच्या बाजूला borg serve सुरू करते आणि त्या process शी स्वतःच्या protocol द्वारे संवाद साधते. Server side वर प्रत्यक्ष काम केले जाते: तो repository ठेवतो, transaction लागू करतो आणि index संबंधी प्रश्नांची उत्तरे देतो. म्हणून Borg कडे S3 backend नाही आणि प्रकल्पाने ते जोडलेलेही नाही. Bucket मध्ये चालवण्यासाठी कोणतीही process उपलब्ध नसते.

या एका design fact मुळे खालील बहुतेक व्यावहारिक फरक निर्माण होतात.

# 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 वापरून त्यापासून key तयार करतो आणि त्यानंतर लिहिलेली प्रत्येक pack file एन्क्रिप्ट व authenticated केली जाते. पासवर्ड हरवल्यास डेटा गमावला जातो, कारण डिझाइननुसार recovery path उपलब्ध नाही.

Borg मध्ये repository तयार करताना एन्क्रिप्शन निवडता येते आणि ही निवड कायमची असते. borg init --encryption=repokey encrypted key repository मध्ये ठेवतो, त्यामुळे केवळ passphrase वापरून restore करता येते. --encryption=keyfile key client वरील ~/.config/borg/keys/ मध्ये ठेवतो. त्यामुळे संपूर्ण repository चोरणाऱ्या व्यक्तीकडे key नसते. मात्र त्या key file चा स्वतंत्र backup घ्यावा लागतो; अन्यथा तुमचे archives वाचता येणार नाहीत. प्रत्येक mode मध्ये -blake2 variant देखील उपलब्ध आहे. तो HMAC-SHA256 ऐवजी BLAKE2b वापरून authentication करतो. SHA acceleration नसलेल्या hardware वर तो अधिक वेगवान असतो. --encryption=none देखील उपलब्ध आहे. Repository तुमच्या मालकीच्या encrypted disk वर असल्यास हा प्रत्यक्षात योग्य पर्याय ठरू शकतो.

व्यावहारिक नियम: सामान्य server backup साठी repokey-blake2, repository पूर्णपणे विश्वासार्ह नसलेल्या ठिकाणी असल्यास keyfile, आणि भाड्याने घेतलेल्या machine वर कधीही none वापरू नका.

Compression आणि restic मध्ये हे उशिरा का आले

Borg मध्ये सुरुवातीपासून compression उपलब्ध आहे. Default पर्याय lz4 आहे. तो पुरेसा वेगवान असल्यामुळे सर्व ठिकाणी सुरू ठेवता येतो. zstd मध्ये 1 ते 22 हे levels स्वीकारले जातात आणि default level 3 आहे. zlib आणि lzma हे वेळेपेक्षा bytes कमी ठेवणे अधिक महत्त्वाचे असलेल्या परिस्थितीसाठी आहेत. 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 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. नवीन repository साठी आता format 2 हा default आहे. Compression --compression वापरून auto, off किंवा max या values पैकी एकावर सेट करता येते. जुना format 1 repository migrate करेपर्यंत uncompressed राहतो. त्यामुळे तुमचे restic repository 0.14 पूर्वीचे असेल आणि तुम्ही ते migrate केले नसेल, तर text, logs आणि database dumps यांच्यासाठी अजूनही पूर्ण size मोजला जातो.

रिमोट लक्ष्य: S3 विरुद्ध SSH

इथेच सहसा निवड केली जाते.

Restic ला S3 पर्यंत पोहोचण्यासाठी environment मध्ये credentials आवश्यक असतात. त्याशिवाय इतरत्र काहीही चालू असण्याची गरज नसते. हाच नमुना तुम्ही स्वतः 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 ची installation आवश्यक असते. तिथली version client शी compatible असणेही आवश्यक आहे. Remote बाजू तुमच्या नियंत्रणात नसेल, तर यामुळे अतिरिक्त अडथळा निर्माण होतो. Remote बाजू तुम्ही आधीच administer करत असलेला दुसरा server असेल, तर ही अडचण राहत नाही. त्याऐवजी ransomware विरुद्ध दोन्हीपैकी कोणतेही tool देऊ शकत नाही इतके मजबूत नियंत्रण मिळते: append-only SSH key. त्या key ला borg serve चालवण्यापुरते मर्यादित करा. त्यामुळे client archives add करू शकतो, पण ते delete करू शकत नाही. परिणामी compromised machine स्वतःचा इतिहास पुसू शकत नाही.

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

Restic मध्ये याचे equivalent फक्त त्याचा स्वतःचा REST server चालवल्यावर मिळते. तो append-only mode ला support करतो. Plain S3 विरुद्ध हाच परिणाम bucket policy किंवा object lock वापरून मिळतो. हे provider चे काम आहे; restic चे नाही. Transport वरही निर्बंध लागू करा. या SSH बाजूची काळजी इतर कोणत्याही login प्रमाणेच घ्या: backup account साठी restricted authorized_keys entry सह key-only 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 द्वारे fetch केलेल्या index files आणि pack files मधून त्याला repository ची माहिती तयार करावी लागते. Request ची संख्या नियंत्रणात ठेवण्यासाठी upload करण्यापूर्वी ते अनेक छोटे chunks मोठ्या pack files मध्ये एकत्र करते. पुढील run मध्ये संपूर्ण index पुन्हा fetch करावा लागू नये म्हणून ते ~/.cache/restic मध्ये local cache ठेवते. हा cache delete केल्यास पुढील backup धीमा होतो, कारण तो cache पुन्हा तयार करावा लागतो. उच्च latency असलेल्या link वर लाखो छोट्या files असल्यास, त्याच डेटावर Restic Borg पेक्षा धीमा वाटतो.

Local disk किंवा वेगवान LAN वर हा फरक प्रामुख्याने कमी होतो. दोन्ही tools source किती वेगाने read आणि hash करू शकतात यावर मर्यादित होतात.

एकाच वेळी लॉक करणे आणि अनेक मशीनचा बॅकअप घेणे

Borg 1.4 संपूर्ण ऑपरेशनदरम्यान repository वर exclusive lock घेतो. एकाच repository मध्ये एकाच वेळी लिहिणारे दोन clients कार्य करत नाहीत: दुसरा client प्रतीक्षा करतो आणि नंतर lock timeout मुळे अयशस्वी होतो. समर्थित पद्धत म्हणजे प्रत्येक client साठी एक repository ठेवणे. याचा अर्थ deduplication फक्त एका मशीनच्या repository मध्ये होते. त्यामुळे जवळजवळ समान असलेले दहा servers समान base system च्या दहा प्रती साठवतात.

Restic मध्ये अनेक clients एकाच वेळी एका repository मध्ये बॅकअप घेऊ शकतात, कारण बॅकअप shared lock घेतो आणि prune सारख्या maintenance कामांसाठीच exclusive lock घेतला जातो. एकाच restic repository कडे निर्देश करणारे दहा समान servers परस्पर deduplication करतात. त्यामुळे दुसऱ्या server पासून पुढे साधारणपणे फारच कमी डेटा साठवला जातो. याची किंमत म्हणजे blast radius: एकच password आणि सर्व काही ठेवणारी एकच repository असते. त्यामुळे password गमावल्यास सर्व दहा servers चा डेटा गमावला जातो.

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 archives काढून टाकते; परंतु त्याने स्वतःहून disk space मोकळी होत नाही. borg compact चालवल्यावरच जागा पुन्हा उपलब्ध होते. त्यामुळे archives prune करणारे, पण compact कधीही न चालवणारे cron job repository सतत वाढवत राहते, जरी archive list लहान राहिली तरी. restic मध्ये, --prune शिवाय forget केल्यास फक्त snapshot references काढले जातात. prune चालवेपर्यंत data तसाच राहतो.

prune केल्यानंतर restic check चालवा. हे repository structures पडताळते आणि काही नुकसान झाले आहे का ते सांगते. 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 मधील paths सुरुवातीचा slash वगळून साठवले जातात. त्यामुळे etc/nginx योग्य आहे. /etc/nginx शी काहीही जुळत नाही आणि काहीही extract होत नाही. हे का झाले ते सांगणारी कोणतीही error दिसत नाही. Extraction सध्याच्या working directory मध्येही लिहिते. त्यामुळे आधी scratch directory मध्ये जा; अन्यथा जुन्या फाइल्स live files वर overwrite होतील.

तुम्ही कोणतेही साधन निवडले तरी schedule हे कामाचे केवळ निम्मे अंग आहे. प्रत्यक्षात monitor करत असलेल्या timer वर scratch directory मध्ये restore चालवा. VPS साठीच्या restic backup मार्गदर्शकाच्या उर्वरित भागात हेच systemd timer वापरून केले आहे.

कोणते साधन कोणत्या कामासाठी

लक्ष्य object storage असेल, एकच binary वापरायचा असेल, दूरच्या बाजूला कोणतेही software स्थापित करायचे नसेल, अनेक मशीनमधील deduplication हवी असेल किंवा restore करणारी व्यक्ती तुम्हीच असेलच असे नाही, तर restic निवडा. Repository साठी URL देऊन हे single static binary म्हणून चालते. Operational दृष्टीने याला मागे टाकणे कठीण आहे.

लक्ष्य तुमच्या नियंत्रणाखालील Linux box असेल, link मध्ये latency असेल आणि dataset मध्ये लाखो लहान files असतील, ransomware विरुद्ध नियंत्रण म्हणून append only SSH key हवी असेल किंवा प्रत्येक job साठी compression स्वतंत्रपणे समायोजित करायचे असेल, तर Borg निवडा. हे जुने tool आहे. याची stable series हळूहळू बदलते. Backup software मध्ये हे एक वैशिष्ट्य आहे.

दोन्ही योग्य पर्याय आहेत. तुम्ही कधीही test न केलेला पर्याय चुकीचा आहे. तुम्ही आधीच application level dumps घेत असाल, तर ते सुरू ठेवा: database dumps असलेली Nextcloud on Docker रचना ही पद्धत दोन्ही tools साठी लागू होते, कारण random वेळी copy केलेली live database file ही database चा backup नसतो.

FAQ

restic किंवा BorgBackup पैकी कोणते जलद आहे?

स्थानिक डिस्कवर किंवा वेगवान LAN वर दोन्हींचा वेग जवळपास समान असतो. दोन्ही साधने source वरील read आणि hash speed मुळे मर्यादित होतात. अतिशय latency असलेल्या SSH link वर आणि खूप मोठ्या संख्येने लहान files असताना 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 वापरा.

दोन्ही tools वर एकाच data विरुद्ध चालवता येतात का?

होय. काही जण असे करतात: जलद local restore साठी Borg द्वितीय server वर आणि offsite copy साठी restic object storage वर. दोन्ही साधने कोणतीही माहिती सामायिक करत नाहीत. त्यामुळे read आणि hash cost दोनदा द्यावी लागते आणि सुरक्षितपणे साठवण्यासाठी दोन passwords लागतात. दोन्ही restore प्रक्रियांची चाचणी घेतली असल्यासच ही पद्धत वापरा.

repository password हरवल्यास काय होते?

दोन्ही tools मध्ये data पुनर्प्राप्त करता येत नाही. Restic scrypt वापरून password पासून key तयार करते आणि त्यासाठी कोणताही bypass नाही. Borg च्या repokey mode मध्ये encrypted key repository मध्येच साठवली जाते, त्यामुळे restore करण्यासाठी passphrase पुरेसा असतो. keyfile mode मध्ये मात्र ~/.config/borg/keys/ मधील key file देखील आवश्यक असते. 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 देते. त्यामुळे आज सुरुवात केल्यास पुढे अडचणीत येणार नाही.