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

Restic और BorgBackup की तुलना, एक पैराग्राफ में

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

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

रिपॉजिटरी मॉडल ही वास्तविक अंतर है

एक restic रिपॉजिटरी फाइलों की एक डायरेक्टरी है: config, keys/, snapshots/, index/, और data/ जो पैक फाइलों से भरी होती हैं। इसे पढ़ने के लिए किसी और चीज की आवश्यकता नहीं होती। यही कारण है कि restic इतने सारे बैकएंड्स को सपोर्ट कर सकता है। कोई भी स्टोरेज जो ब्लब्स (blobs) को पुट, गेट, लिस्ट और डिलीट कर सकता है, वह restic रिपॉजिटरी को रख सकता है। इसी तरह एक सिंगल बाइनरी लोकल पाथ, SFTP, अपने स्वयं के REST सर्वर, S3, Backblaze B2, Azure, Google Cloud Storage और ऐसी किसी भी चीज को सपोर्ट करती है जहाँ तक rclone पहुँच सकता है।

Borg रिपॉजिटरी भी डिस्क पर मौजूद फाइलें ही हैं, लेकिन Borg कभी भी डंब ट्रांसपोर्ट (dumb transport) के माध्यम से उनसे बात नहीं करता है। रिमोट रिपॉजिटरी के लिए, Borg SSH के माध्यम से दूसरी तरफ borg serve शुरू करता है और उस प्रोसेस से अपने स्वयं के प्रोटोकॉल में बात करता है। सर्वर साइड वास्तविक काम करता है: यह रिपॉजिटरी को होल्ड करता है, ट्रांजेक्शन लागू करता है और इंडेक्स संबंधी सवालों के जवाब देता है। यही कारण है कि स्टेबल Borg 1.4 सीरीज में कोई S3 बैकएंड नहीं है। बकेट के अंदर चलाने के लिए कोई प्रोसेस नहीं होती है। Borg 2 इसे बदल देता है: यह स्टोरेज को borgstore नामक एक नई लेयर में ले जाता है, और इसका डॉक्यूमेंटेशन sftp://, rclone:remote:path और s3: या b2: रिपॉजिटरी URLs का वर्णन करता है। हालाँकि, Borg 2 अभी भी एक बीटा वर्जन है जिसे प्रोजेक्ट प्रोडक्शन में उपयोग न करने की सलाह देता है, इसलिए आज वास्तविक बैकअप के लिए S3 की कमी अभी भी बनी हुई है।

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

# 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 उन स्थितियों के लिए हैं जहाँ आप समय की तुलना में bytes को अधिक महत्व देते हैं, और 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, fastest, better या max। fastest और better मोड restic 0.19.0 में आए, इसलिए पुराने binaries केवल auto, off और max को स्वीकार करते हैं। एक पुरानी format 1 repository तब तक uncompressed रहती है जब तक आप उसे migrate न करें। इसलिए यदि आपकी restic repository 0.14 से पुरानी है और आपने कभी migrate नहीं किया है, तो आप अभी भी text, logs और database dumps के लिए पूरा storage space खर्च कर रहे हैं।

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 अधिक तेज़ है?

लोकल डिस्क या तेज़ LAN पर दोनों की गति लगभग समान है, और दोनों ही स्रोत पर रीड और हैश स्पीड से सीमित हो जाते हैं। Borg अधिक latency वाले SSH लिंक पर बहुत सारी छोटी फाइलों के साथ बेहतर प्रदर्शन करता है, क्योंकि दूसरी तरफ चलने वाली borg serve प्रक्रिया हर चंक के लिए नेटवर्क राउंड ट्रिप के बिना ही इंडेक्स संबंधी सवालों के जवाब दे देती है। Restic तब बेहतर होता है जब लक्ष्य object storage हो, जहाँ स्थिर Borg का उपयोग बिल्कुल नहीं किया जा सकता।

क्या BorgBackup S3 या Backblaze B2 पर बैकअप ले सकता है?

स्थिर 1.4 सीरीज के साथ ऐसा संभव नहीं है। एक Borg 1.4 रिपॉजिटरी को SSH के माध्यम से borg serve प्रक्रिया द्वारा सर्व किया जाता है, और ऐसी कोई प्रक्रिया बकेट के अंदर नहीं चलती है। Borg 2 अपने borgstore लेयर के माध्यम से s3:, b2: और rclone: रिपॉजिटरी URL जोड़ता है, लेकिन अक्टूबर 2026 तक Borg 2 अभी भी बीटा में है और प्रोजेक्ट इसे प्रोडक्शन में उपयोग न करने की सलाह देता है। 1.4 के साथ, लोग rclone का उपयोग करके object storage को फाइल सिस्टम के रूप में माउंट करके इस कमी को पूरा करते हैं। Borg FAQ रिपॉजिटरी स्टोरेज के लिए नेटवर्क फाइल सिस्टम के उपयोग के खिलाफ सलाह देता है और चेतावनी देता है कि FUSE और नेटवर्क फाइल सिस्टम धीमेपन या डेटा करप्शन का कारण बन सकते हैं। यदि आपको आज प्रोडक्शन बैकअप के लिए object storage की आवश्यकता है, तो restic का उपयोग करें।

क्या मैं एक ही डेटा पर दोनों टूल्स चला सकता हूँ?

हाँ, और कुछ लोग ऐसा करते भी हैं: तेज़ लोकल रिस्टोर के लिए Borg को दूसरे सर्वर पर, और ऑफसाइट कॉपी के लिए restic को object storage पर। वे आपस में कुछ भी साझा नहीं करते हैं, इसलिए आपको रीड और हैश की लागत दो बार चुकानी पड़ती है, और आपको दो पासवर्ड सुरक्षित रखने होते हैं। ऐसा केवल तभी करें जब आपने दोनों रिस्टोर का परीक्षण कर लिया हो।

यदि मैं रिपॉजिटरी पासवर्ड खो दूँ तो क्या होगा?

दोनों टूल्स में डेटा को रिकवर करना असंभव है। Restic अपने की (key) को पासवर्ड से scrypt के जरिए डिराइव करता है और इसे बायपास करने का कोई तरीका नहीं है। repokey मोड में Borg एन्क्रिप्टेड की (key) को रिपॉजिटरी के अंदर स्टोर करता है, इसलिए केवल पासफ्रेज से ही रिस्टोर हो जाता है, और keyfile मोड में आपको ~/.config/borg/keys/ से की (key) फाइल की भी आवश्यकता होती है। पासवर्ड को ऐसे पासवर्ड मैनेजर में रखें जो उस सर्वर पर न हो जिसका बैकअप लिया जा रहा है, और यदि आप keyfile का उपयोग करते हैं तो borg key export के साथ Borg की (key) को एक्सपोर्ट करें।

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

नहीं। अक्टूबर 2026 तक Borg 2.0 अभी भी बीटा में है, जो 2.0.0b25 (27 सितंबर 2026 को रिलीज) पर है, और प्रोजेक्ट इसे केवल टेस्टिंग के लिए लेबल करता है। स्थिर सीरीज 1.4 है, जो वर्तमान में 1.4.5 है। अभी 1.4 से शुरुआत करें। Borg 2 रिपॉजिटरी फॉर्मेट को बदलता है और एक डॉक्यूमेंटेड अपग्रेड पाथ (borg transfer --from-borg1) प्रदान करता है, इसलिए आज शुरुआत करने से आप कहीं फंसेंगे नहीं। Borg 2 में ही नेटिव S3, B2 और rclone सपोर्ट आएगा, जब यह स्थिर हो जाएगा।