Restic की BorgBackup: कोणते वापरावे?

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

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

इतर सर्व फरक तुलनेने लहान आहेत. दोन्ही products 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 only म्हणून चिन्हांकित आहे. त्यामुळे आज deploy करण्यासाठी 1.4 वापरा.

वास्तविक फरक repository मॉडेलमध्ये आहे

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

Borg repository हीदेखील disk वरील files असते. मात्र Borg तिच्याशी 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 मध्ये नेहमी एन्क्रिप्शन असते. अनएन्क्रिप्टेड मोड उपलब्ध नाही. restic init पासवर्ड मागते आणि scrypt वापरून त्यापासून key तयार करते. त्यानंतर लिहिल्या जाणाऱ्या प्रत्येक pack file चे एन्क्रिप्शन आणि प्रमाणीकरण केले जाते. पासवर्ड हरवल्यास डेटा गमावला जातो, कारण डिझाइननुसार recovery path उपलब्ध नाही.

Repository तयार करताना Borg मध्ये एन्क्रिप्शन निवडावे लागते. ही निवड कायमची असते. borg init --encryption=repokey encrypted key repository मध्ये ठेवते. त्यामुळे केवळ passphrase वापरून restore करता येते. --encryption=keyfile key client वरील ~/.config/borg/keys/ मध्ये ठेवते. त्यामुळे कोणी संपूर्ण repository चोरले तरी त्याच्याकडे काहीही उपयोगाचे राहत नाही. मात्र त्या key file चा स्वतंत्रपणे backup घेणे आवश्यक असते. अन्यथा archives वाचता येत नाहीत. प्रत्येक mode मध्ये -blake2 variant उपलब्ध आहे. तो HMAC-SHA256 ऐवजी BLAKE2b वापरून प्रमाणीकरण करतो. 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 3 आहे. zlib आणि lzma हे bytes वाचवणे minutes वाचवण्यापेक्षा महत्त्वाचे असताना वापरता येतात. auto प्रत्येक chunk साठी heuristic चालवते, त्यामुळे आधीच compressed असलेला data पुन्हा squeeze केला जात नाही.

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

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

Restic मध्ये यासाठी समतुल्य पर्याय तेव्हाच असतो, जेव्हा तुम्ही त्याचा स्वतःचा REST server चालवता. तो append only mode ला support करतो. साध्या S3 विरुद्ध bucket policy किंवा object lock वापरून हाच परिणाम मिळतो. ही जबाबदारी provider ची असते, restic ची नाही. Transport वरही निर्बंध लावा. SSH बाजूची सुरक्षा इतर कोणत्याही login इतकीच काळजीपूर्वक हाताळणे आवश्यक आहे: backup account साठी मर्यादित authorized_keys entry सह केवळ key आधारित SSH लागू करा.

गती: प्रत्येक रचनेचा परिणाम

तुमच्या स्वतःच्या डेटासाठी विश्वास ठेवावा असा बेंचमार्क कोणताही प्रकल्प प्रकाशित करत नाही. त्यामुळे यंत्रणेच्या आधारे विचार करा.

विलंब असलेल्या दुव्यावर SSH वरील Borg वेगवान असतो, कारण सर्व्हरची बाजू कार्यक्षम असते. क्लायंट प्रश्न विचारतो, दूरस्थ borg serve प्रक्रिया रिपॉझिटरीच्या अनुक्रमणिकेतून त्याचे उत्तर देते आणि व्यवहार एकाच ठिकाणी कमिट होतो. प्रत्येक लहान फाइलसाठी चंक शोधण्यामुळे नेटवर्कवर स्वतंत्र राउंड ट्रिप्स होत नाहीत.

ऑब्जेक्ट स्टोरेजवरील Restic कडे सर्व्हर-साइड प्रक्रिया नसते. त्यामुळे HTTP द्वारे आणलेल्या index files आणि pack files मधून त्याला स्वतःची स्थिती तयार करावी लागते. विनंत्यांची संख्या नियंत्रणात ठेवण्यासाठी अपलोड करण्यापूर्वी ते अनेक छोटे चंक मोठ्या pack files मध्ये एकत्र करते. पुढील रनमध्ये संपूर्ण अनुक्रमणिका पुन्हा आणावी लागू नये म्हणून ते ~/.cache/restic मध्ये स्थानिक cache ठेवते. तो cache हटवल्यास पुढील backup धीमा होतो, कारण तो cache पुन्हा तयार करावा लागतो. उच्च विलंब असलेल्या दुव्यावर लाखो लहान फाइल्स असल्यास, त्याच डेटावर Restic Borg पेक्षा धीमा वाटतो.

स्थानिक डिस्कवर किंवा वेगवान LAN वर हा फरक बहुतांश प्रमाणात कमी होतो. दोन्ही साधनांचा वेग शेवटी 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 गमावल्यास सर्व दहा serversचा डेटा गमावला जातो.

धारणा कालावधी: विसरा आणि छाटणी करा, विरुद्ध छाटणी करा आणि संकुचित करा

दोन्ही साधने "काय ठेवायचे ते ठरवणे" आणि "जागा पुन्हा मिळवणे" हे वेगळे करतात. दोन्हींमध्ये तुम्हाला दुसरी पायरी चालवावी लागते.

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 सतत वाढवत राहते. restic मध्ये, --prune शिवाय forget केल्यास snapshot references फक्त काढल्या जातात; prune चालवेपर्यंत data तसाच राहतो.

pruning नंतर 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 कोणत्याही path शी जुळत नाही आणि काहीही extract करत नाही. याचे कारण सांगणारी कोणतीही error दिसत नाही. Extraction सध्याच्या working directory मध्येही लिहिते. त्यामुळे आधी scratch directory मध्ये जा. अन्यथा जुन्या फाइल्समुळे live files overwrite होतील.

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

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

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

लक्ष्य तुमच्या नियंत्रणाखालील 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 साठी लागू होते, कारण कोणत्याही यादृच्छिक क्षणी copy केलेली live database file हा database चा backup नसतो.

FAQ

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

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

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 वापरा.

समान डेटावर दोन्ही tools चालवता येतात का?

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

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

दोन्ही tools मध्ये डेटा पुनर्प्राप्त करता येत नाही. Restic password पासून scrypt वापरून key तयार करते आणि त्याला कोणताही bypass नाही. Borg च्या repokey mode मध्ये encrypted key repository मध्येच साठवली जाते, त्यामुळे passphrase पुरेसा असतो. 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 साठी म्हणून oznaखते. Stable series 1.4 आहे आणि सध्याची आवृत्ती 1.4.5 आहे. आता 1.4 वर सुरुवात करा. Borg 2 repository format बदलते आणि documented upgrade path उपलब्ध करून देते. त्यामुळे आज सुरुवात केल्यास पुढे अडचण निर्माण होत नाही.