Restic विरुद्ध BorgBackup: कोणते backup साधन निवडावे?

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

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

उर्वरित फरक तुलनेने लहान आहेत. दोन्ही साधने content-defined chunking वापरून files चे भाग करतात. त्यामुळे 40 GB directory मधील फक्त 200 MB बदलल्यास साधारण 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 only म्हणून चिन्हांकित आहे. त्यामुळे आज deploy करण्यासाठी 1.4 हीच आवृत्ती वापरावी.

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

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

Borg repository देखील disk वरील files असते. मात्र Borg कधीही अशा repository शी dumb transport द्वारे संवाद साधत नाही. Remote repository साठी Borg SSH द्वारे दूरच्या बाजूला borg serve सुरू करते आणि त्या process शी स्वतःचा protocol वापरते. Server side प्रत्यक्ष काम करते: ते repository ठेवते, transaction लागू करते आणि index विषयीच्या प्रश्नांची उत्तरे देते. म्हणूनच Borg मध्ये S3 backend नाही आणि project ने ते जोडलेलेही नाही. 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 नेहमी encrypted असते. Unencrypted mode उपलब्ध नाही. restic init password मागते, scrypt वापरून त्यापासून cryptographic 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 ठेवावा लागतो; अन्यथा तुमचे archives वाचता येणार नाहीत. प्रत्येक mode मध्ये -blake2 variant उपलब्ध आहे. तो HMAC-SHA256 ऐवजी BLAKE2b वापरून authentication करतो. SHA acceleration नसलेल्या hardware वर तो अधिक वेगवान असतो. --encryption=none देखील उपलब्ध आहे. Repository तुमच्या मालकीच्या encrypted disk वर असेल, तेव्हा हा खरा पर्याय ठरतो.

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

कंप्रेशन आणि restic मध्ये ते उशिरा का आले

Borg मध्ये सुरुवातीपासूनच कंप्रेशन उपलब्ध आहे. डीफॉल्ट पर्याय lz4 आहे. तो पुरेसा वेगवान असल्यामुळे सर्व डेटासाठी तो सुरू ठेवता येतो. zstd मध्ये 1 ते 22 स्तर स्वीकारले जातात आणि डीफॉल्ट स्तर 3 आहे. zlib आणि lzma हे वेळेपेक्षा बाइट्सची बचत अधिक महत्त्वाची असताना वापरता येतात. auto प्रत्येक chunk साठी heuristic वापरते, त्यामुळे आधीच compressed असलेला डेटा पुन्हा कंप्रेस केला जात नाही.

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 migrate करेपर्यंत uncompressed राहते. त्यामुळे तुमची restic repository 0.14 पूर्वीची असेल आणि तुम्ही तिचे migration केले नसेल, तर text, logs आणि database dumps साठी अजूनही पूर्ण आकाराइतकी storage वापरली जात आहे.

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

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

Restic मध्ये याच्याशी समतुल्य पर्याय तेव्हाच असतो, जेव्हा तुम्ही त्याचा स्वतःचा 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 प्रकाशित करत नाही. त्यामुळे यंत्रणा कशी कार्य करते यावरून निष्कर्ष काढा.

SSH वरील Borg उच्च latency असलेल्या link वर वेगवान असतो, कारण server side बुद्धिमान असते. client एक प्रश्न पाठवतो. remote borg serve प्रक्रिया repository index मधून त्याचे उत्तर देते. transaction एकाच ठिकाणी commit होते. प्रत्येक लहान file साठी chunk lookup मुळे स्वतंत्र network round trip होत नाही.

Object storage वरील Restic कडे server side नसते. त्यामुळे HTTP द्वारे fetch केलेल्या index files आणि pack files मधून त्याला स्वतःची माहिती तयार करावी लागते. request ची संख्या नियंत्रणात ठेवण्यासाठी upload करण्यापूर्वी ते अनेक छोटे chunks मोठ्या pack files मध्ये एकत्र करते. पुढील run मध्ये संपूर्ण index पुन्हा fetch करावा लागू नये म्हणून ते ~/.cache/restic मध्ये local cache ठेवते. हा cache हटवल्यास पुढील backup slow होतो, कारण तो cache पुन्हा तयार करतो. उच्च latency असलेल्या link वर millions of small files असल्यास, त्याच डेटावर Borg पेक्षा restic slow वाटतो.

Local disk किंवा fast LAN वर हा फरक बहुतांश वेळा कमी होतो. त्यानंतर दोन्ही tools source वाचण्याच्या आणि hash करण्याच्या कमाल वेगामुळे मर्यादित राहतात.

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

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

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

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

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

Restore error शिवाय पूर्ण झाले, तरी ते पुरावा नाही. कारण त्यावर चालणाऱ्या application कडे complete restore ची स्वतःची व्याख्या असते. उदाहरणार्थ, Postgres data directory च्या copy मधून पुन्हा तयार केलेला Immich server disk वरील सर्व photos सह सुरू होतो, पण timeline मध्ये काहीही दिसत नाही. हीच समस्या Immich चा backup आणि restore सोडवण्याचा प्रयत्न करते.

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

कोणत्या कामासाठी कोणते योग्य आहे

लक्ष्य object storage असेल, एकच binary वापरायचा असेल आणि दूरच्या बाजूला कोणतेही software स्थापित करायचे नसेल, अनेक machines ने एकमेकांमधील data deduplicate करायचा असेल किंवा restore करणारी व्यक्ती तुम्हीच असेलच असे नाही, तर restic निवडा. Repository साठी URL देऊन चालणारा हा एक 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 setup यातील पद्धत दोन्ही tools साठी लागू होते. कारण random क्षणी copy केलेली live database file ही database चा backup नसते.

FAQ

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

स्थानिक डिस्कवर किंवा जलद LAN वर दोन्हींची कामगिरी जवळपास सारखी असते. दोन्ही साधने source वरील read आणि hash speed मुळे मर्यादित होतात. अतिशय लहान फाइल्स असलेल्या high-latency SSH link वर Borg सहसा अधिक जलद ठरते, कारण दूरच्या बाजूला चालणारी borg serve process प्रत्येक chunk साठी network round trip न करता index संबंधी प्रश्नांची उत्तरे देते. Target म्हणून object storage वापरताना restic सहसा अधिक योग्य ठरते, कारण Borg थेट object storage वर वापरता येत नाही.

BorgBackup चा backup S3 किंवा Backblaze B2 वर घेता येतो का?

थेट घेता येत नाही. Borg repository SSH वरील borg serve process द्वारे उपलब्ध करून दिली जाते. Bucket च्या आत असा कोणताही process चालत नाही. काही जण rclone वापरून object storage filesystem म्हणून mount करतात. Borg project ही पद्धत सुचवत नाही, कारण transaction सुरू असताना mount connection तुटल्यास repository दूषित होऊ शकते. Object storage आवश्यक असल्यास restic वापरा.

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

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

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

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