Restic बनाम BorgBackup: आपके लिए कौन सा बेहतर है?

Restic और BorgBackup, एक पैराग्राफ में

Restic और BorgBackup दोनों एक ही मुख्य कार्य करते हैं: Linux सर्वर का deduplicated, encrypted और incremental बैकअप लेना। चुनाव का मुख्य आधार यह है कि बैकअप कहाँ स्टोर किया जा रहा है। Restic मूल रूप से S3 और अन्य object storage API को सपोर्ट करता है, इसलिए एक bucket सीधे तौर पर target हो सकता है और दूरस्थ छोर (far end) पर किसी सॉफ्टवेयर की आवश्यकता नहीं होती। Borg को repository रखने वाली मशीन पर borg प्रोग्राम इंस्टॉल होना चाहिए, क्योंकि Borg repository एक filesystem या API के बजाय एक process द्वारा संचालित होती है। यदि आपका target object storage है, तो Restic ही सही विकल्प है। यदि आपका target आपके नियंत्रण वाला दूसरा Linux बॉक्स है, तो Borg का उपयोग किया जा सकता है और यह अक्सर तेज होता है।

बाकी सभी अंतर छोटे हैं। दोनों content-defined chunking का उपयोग करके फाइलों को विभाजित करते हैं, इसलिए यदि 40 GB की डायरेक्टरी में 200 MB का बदलाव होता है, तो लगभग 200 MB ही अपलोड होता है। दोनों client-side पर encryption करते हैं। दोनों FUSE (filesystem in userspace) के माध्यम से snapshot को mount करने की सुविधा देते हैं ताकि आप एक फाइल को कॉपी कर सकें। जुलाई 2026 तक, restic 0.19.1 पर है और Borg की stable series 1.4, 1.4.5 संस्करण पर है। Borg 2.0 कई वर्षों से beta में है और अभी भी केवल टेस्टिंग के लिए चिह्नित है, इसलिए आपको आज 1.4 ही deploy करना चाहिए।

Repository model ही वास्तविक अंतर है

एक restic repository फाइलों की एक directory है: config, keys/, snapshots/, index/, और data/ जो pack files से भरी होती हैं। इसे पढ़ने के लिए किसी और चीज की आवश्यकता नहीं होती। यही कारण है कि restic इतने सारे backends को चला सकता है। कोई भी store जो blobs को put, get, list और delete कर सकता है, वह restic repository को रख सकता है। इसी तरह एक binary local paths, SFTP, अपने स्वयं के REST server, S3, Backblaze B2, Azure, Google Cloud Storage और rclone द्वारा पहुँच योग्य किसी भी चीज का समर्थन करती है।

Borg repository भी disk पर मौजूद फाइलें ही हैं, लेकिन Borg कभी भी dumb transport के माध्यम से इनसे बात नहीं करता है। remote repository के लिए, Borg SSH के माध्यम से दूसरी तरफ borg serve को start करता है और उस process से अपने स्वयं के protocol में बात करता है। server side वास्तविक काम करता है: यह repository को रखता है, transaction को लागू करता है और index संबंधी सवालों के जवाब देता है। यही कारण है कि Borg का कोई S3 backend नहीं है और project ने इसे क्यों नहीं जोड़ा है। bucket के अंदर चलाने के लिए कोई process नहीं होती है।

design का वह एक तथ्य नीचे दिए गए अधिकांश व्यावहारिक अंतरों को जन्म देता है।

# 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 हमेशा एन्क्रिप्टेड रहता है। इसमें कोई भी unencrypted मोड नहीं है। restic init एक पासवर्ड मांगता है, scrypt का उपयोग करके उससे एक key बनाता है, और उसके बाद लिखी गई प्रत्येक pack file एन्क्रिप्ट और ऑथेंटिकेट की जाती है। यदि पासवर्ड खो जाता है, तो डेटा भी खो जाता है, क्योंकि डिज़ाइन के अनुसार रिकवरी का कोई रास्ता मौजूद नहीं है।

Borg में repository बनाते समय एन्क्रिप्शन का चुनाव करना होता है, और यह चुनाव स्थायी होता है। borg init --encryption=repokey एन्क्रिप्टेड key को repository के अंदर रखता है, इसलिए केवल passphrase से ही रिस्टोर किया जा सकता है। --encryption=keyfile key को क्लाइंट पर ~/.config/borg/keys/ में रखता है, इसलिए यदि कोई पूरी repository चुरा भी ले, तो उसके पास कुछ नहीं होगा, और आपको उस key file का अलग से बैकअप लेना होगा अन्यथा आपके archives नहीं पढ़े जा सकेंगे। प्रत्येक मोड का एक -blake2 वेरिएंट होता है जो HMAC-SHA256 के बजाय BLAKE2b के साथ ऑथेंटिकेट करता है, जो SHA acceleration के बिना हार्डवेयर पर तेज़ होता है। --encryption=none भी मौजूद है, और यह एक वास्तविक विकल्प है जब repository आपके अपने एन्क्रिप्टेड डिस्क पर स्थित हो।

व्यावहारिक नियम: सामान्य सर्वर बैकअप के लिए repokey-blake2 का उपयोग करें, जब repository ऐसी जगह हो जिस पर आप पूरी तरह भरोसा नहीं करते तो keyfile का उपयोग करें, और किराए की मशीन पर कभी भी none का उपयोग न करें।

Compression, और restic में यह देर से क्यों आया

Borg शुरुआत से ही compression का उपयोग करता रहा है। डिफ़ॉल्ट 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

Restic में repository format 2 तक कोई compression नहीं था, जिसके लिए restic 0.14.0 या उससे नया वर्ज़न चाहिए। Format 2 अब नई repository के लिए डिफ़ॉल्ट है, और compression को --compression के साथ auto, off या max मानों पर सेट किया जाता है। एक पुरानी format 1 repository तब तक uncompressed रहती है जब तक आप उसे migrate नहीं करते। इसलिए यदि आपकी restic repository 0.14 से पुरानी है और आपने कभी migrate नहीं किया है, तो आप अभी भी text, logs और database dumps के लिए पूरा आकार खर्च कर रहे हैं।

Remote targets: 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 को रिमोट रिपॉजिटरी तक पहुँचने के लिए SSH और दूसरी तरफ Borg के इंस्टॉलेशन की आवश्यकता होती है, और यह चाहता है कि वहां का वर्ज़न क्लाइंट के साथ संगत हो। यदि दूसरी तरफ का सर्वर आपका नहीं है, तो यह एक बाधा है। यदि दूसरी तरफ वह सर्वर है जिसे आप पहले से ही मैनेज करते हैं, तो यह कोई समस्या नहीं है। यह आपको ransomware के खिलाफ सबसे मजबूत नियंत्रण प्रदान करता है जो दोनों टूल्स में से कोई भी दे सकता है: एक append-only SSH key। key को borg serve चलाने के लिए बाध्य करें, जिससे क्लाइंट archives को जोड़ तो पाएगा लेकिन उन्हें डिलीट नहीं कर पाएगा। इस प्रकार, एक compromised मशीन अपना इतिहास मिटा नहीं सकेगी।

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

Restic में इसके बराबर की सुविधा केवल तब मिलती है जब आप उसका अपना REST server चलाते हैं, जो append-only मोड को सपोर्ट करता है। साधारण S3 के मामले में, आपको bucket policy या object lock से वही प्रभाव मिलता है, जो कि प्रोवाइडर का काम है, restic का नहीं। ट्रांसपोर्ट को भी सुरक्षित रखें, क्योंकि SSH के इस हिस्से को भी किसी अन्य लॉगिन के समान ही सावधानी की आवश्यकता है: बैकअप अकाउंट पर restricted authorized_keys एंट्री के साथ key-only SSH लागू करें।

गति: प्रत्येक डिज़ाइन का निहितार्थ

कोई भी प्रोजेक्ट ऐसा बेंचमार्क प्रकाशित नहीं करता जिस पर आप अपने डेटा के लिए भरोसा कर सकें, इसलिए तंत्र (mechanism) के आधार पर तर्क करें।

SSH पर Borg एक latency वाले लिंक पर तेज़ है क्योंकि सर्वर साइड intelligent है। क्लाइंट एक प्रश्न पूछता है, रिमोट borg serve प्रोसेस रिपॉजिटरी इंडेक्स से उसका उत्तर देती है, और ट्रांजेक्शन एक ही स्थान पर कमिट हो जाता है। Chunk lookups हर छोटी फाइल के लिए नेटवर्क राउंड ट्रिप में नहीं बदलते हैं।

Object storage पर Restic का कोई सर्वर साइड नहीं होता है, इसलिए इसे HTTP पर फेच की गई इंडेक्स फाइलों और पैक फाइलों से अपनी तस्वीर बनानी पड़ती है। रिक्वेस्ट काउंट को उचित रखने के लिए, यह अपलोड करने से पहले कई छोटे चंक्स को बड़ी पैक फाइलों में पैक करता है, और यह ~/.cache/restic में एक लोकल कैश रखता है ताकि अगली रन पूरा इंडेक्स दोबारा फेच न करे। उस कैश को डिलीट करें और अगला बैकअप धीमा हो जाएगा क्योंकि इसे फिर से बनाना पड़ता है। लाखों छोटी फाइलों वाले उच्च latency लिंक पर, यह वह स्थिति है जहाँ restic उसी डेटा पर Borg की तुलना में धीमा महसूस होता है।

लोकल डिस्क या तेज़ LAN पर यह अंतर काफी हद तक खत्म हो जाता है, और दोनों टूल्स अंततः इस बात से सीमित हो जाते हैं कि वे सोर्स को कितनी तेज़ी से पढ़ और हैश (hash) कर सकते हैं।

कई मशीनों को लॉक करना और उनका बैकअप लेना

Borg 1.4 पूरी प्रक्रिया के दौरान repository पर एक exclusive lock लगाता है। एक ही repository में एक साथ लिखने वाले दो clients काम नहीं करते हैं: दूसरा client प्रतीक्षा करता है और फिर lock timeout के साथ विफल हो जाता है। समर्थित पैटर्न प्रति client एक repository है। इसका अर्थ यह भी है कि deduplication केवल एक मशीन की repository के भीतर होता है, इसलिए दस लगभग समान servers एक ही base system की दस प्रतियां store करते हैं।

Restic कई clients को एक ही समय में एक repository में बैकअप लेने की अनुमति देता है, क्योंकि बैकअप एक shared lock लेता है और केवल रखरखाव कार्य जैसे कि prune एक exclusive lock लेता है। एक restic repository की ओर इशारा करने वाले दस समान servers एक-दूसरे के विरुद्ध deduplicate करते हैं, और दूसरा server अक्सर बहुत कम डेटा store करता है। इसकी कीमत blast radius है: एक पासवर्ड और एक repository में सब कुछ होता है, इसलिए पासवर्ड खोने का मतलब है कि सभी दस का डेटा खो जाना।

Retention: forget और prune, बनाम prune और compact

दोनों tools "क्या रखना है" का निर्णय लेने और "space को reclaim करने" की प्रक्रिया को अलग-अलग रखते हैं, और दोनों में आपको दूसरा चरण स्वयं चलाना पड़ता है।

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

दोनों tools में एक ही trap है जिसे स्पष्ट रूप से समझना आवश्यक है। Borg में, borg prune archives को हटा देता है लेकिन यह अपने आप disk space खाली नहीं करता है। Space तब वापस मिलती है जब borg compact चलता है, इसलिए यदि कोई cron job केवल prune करती है और कभी compact नहीं करती, तो repository का आकार बढ़ता ही रहेगा जबकि archive list छोटी बनी रहेगी। Restic में, --prune के बिना forget चलाने पर केवल snapshot references हटते हैं, और data तब तक बना रहता है जब तक कि prune न चलाया जाए।

Pruning के बाद restic check चलाएं। यह repository की संरचनाओं की पुष्टि करता है और आपको बताता है कि क्या कुछ क्षतिग्रस्त है, जो कि restore के समय पता चलने से कहीं बेहतर है।

Restore करना, जो एकमात्र मायने रखने वाला परीक्षण है

दोनों tools एक snapshot को mount करते हैं ताकि आप उसे browse कर सकें। किसी एक file को वापस पाने का यह सबसे तेज़ तरीका है।

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 को leading slash के बिना store किया जाता है, इसलिए etc/nginx सही है और /etc/nginx किसी भी चीज़ से match नहीं करता और कुछ भी extract नहीं करता, बिना किसी error के जो आपको कारण बता सके। Extraction वर्तमान working directory में भी लिखता है, इसलिए पहले एक scratch directory में जाएँ अन्यथा आप live files को पुरानी files से overwrite कर देंगे।

बिना किसी error के पूरा हुआ restore भी प्रमाण नहीं है, क्योंकि ऊपर चल रहे application की अपनी धारणा होती है कि पूर्ण restore क्या है: Postgres data directory की copy से rebuild किया गया Immich server disk पर मौजूद सभी photos के साथ वापस आता है, लेकिन timeline में कुछ भी नहीं दिखता, जो कि ठीक वही विफलता है जिसे Immich को backup और restore करना में हल करना होता है।

आप जो भी tool चुनें, schedule केवल आधा काम है। एक timer पर scratch directory में restore चलाएं जिसे आप वास्तव में देखते हैं, ठीक वैसे ही जैसे VPS के लिए restic backup guide में systemd timer के साथ पूरा walkthrough किया गया है।

किस काम के लिए कौन सा टूल चुनें

जब आपका लक्ष्य object storage हो, जब आप एक single binary चाहते हों और दूरस्थ छोर (far end) पर किसी अन्य software की आवश्यकता न हो, जब कई machines को एक-दूसरे के विरुद्ध deduplicate करना हो, या जब restore करने वाला व्यक्ति आप न हों, तब restic चुनें। यह एक single static binary है जिसमें repository के लिए केवल एक URL की आवश्यकता होती है, और 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 के साथ Docker पर Nextcloud सेटअप में दिया गया पैटर्न किसी भी tool पर लागू होता है, क्योंकि किसी भी यादृच्छिक क्षण पर copy की गई live database file, database का backup नहीं होती है।

FAQ

क्या restic या BorgBackup अधिक तेज है?

Local disk या तेज LAN पर दोनों की गति लगभग समान है, और दोनों ही source पर read और hash speed की सीमा तक पहुँच जाते हैं। उच्च 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 द्वारा serve किया जाता है, और bucket के अंदर ऐसा कोई process नहीं चलता। लोग rclone का उपयोग करके object storage को filesystem के रूप में mount करके इसे हल करते हैं, लेकिन Borg project इसकी सलाह नहीं देता, क्योंकि यदि transaction के बीच में mount disconnect हो जाए, तो repository corrupt हो सकती है। यदि आपको object storage की आवश्यकता है, तो restic का उपयोग करें।

क्या मैं एक ही data के लिए दोनों tools चला सकता हूँ?

हाँ, और कुछ लोग ऐसा करते भी हैं: तेज local restore के लिए Borg को दूसरे server पर, और offsite copy के लिए restic को object storage पर। दोनों के बीच कोई साझा संसाधन नहीं होता, इसलिए आपको read और hash की लागत दो बार चुकानी पड़ती है, और आपको दो passwords सुरक्षित रखने होते हैं। ऐसा केवल तभी करें जब आपने दोनों के restore process का परीक्षण कर लिया हो।

यदि मैं repository का password भूल जाऊं तो क्या होगा?

दोनों ही tools में data को recover करना असंभव है। Restic अपने key को password से scrypt के जरिए derive करता है और इसे bypass करने का कोई तरीका नहीं है। Borg, repokey mode में encrypted key को repository के अंदर ही रखता है, इसलिए केवल passphrase से ही restore हो जाता है, जबकि keyfile mode में आपको ~/.config/borg/keys/ से key file की भी आवश्यकता होती है। Password को ऐसे password manager में रखें जो उस server पर न हो जिसका backup लिया जा रहा है, और यदि आप keyfile का उपयोग करते हैं, तो borg key export के साथ Borg key को export कर लें।

क्या मुझे Borg 2.0 का इंतजार करना चाहिए?

नहीं। जुलाई 2026 तक Borg 2.0 अभी भी beta में है, जो 2.0.0b22 version पर है, और project इसे केवल testing के लिए मानता है। Stable series 1.4 है, जो वर्तमान में 1.4.5 है। अभी 1.4 से शुरुआत करें। Borg 2 repository format को बदलता है और एक documented upgrade path प्रदान करता है, इसलिए आज शुरू करने से आप भविष्य में नहीं फंसेंगे।