Restic बनाम BorgBackup: किसे चलाएँ?

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

Restic और BorgBackup दोनों का मुख्य काम एक जैसा है: Linux server के deduplicated, encrypted और incremental backups बनाना। चुनाव का सबसे महत्वपूर्ण आधार यह है कि backup कहाँ रखा जाएगा। Restic मूल रूप से S3 और अन्य object storage APIs का समर्थन करता है। इसलिए bucket सीधे target के रूप में इस्तेमाल किया जा सकता है और दूसरी ओर कुछ भी install करने की आवश्यकता नहीं होती। Repository रखने वाली machine पर 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 का version 0.19.1 है और Borg की stable series 1.4 है, जिसका वर्तमान version 1.4.5 है। Borg 2.0 कई वर्षों से beta में है और अभी भी केवल testing के लिए चिह्नित है। इसलिए आज आपको 1.4 deploy करना चाहिए।

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

restic repository files की एक 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 द्वारा पहुंच योग्य किसी भी स्थान को support करती है।

Borg repository भी disk पर files का संग्रह होती है, लेकिन Borg किसी साधारण transport के माध्यम से उससे संचार नहीं करता। Remote repository के लिए Borg SSH के माध्यम से दूसरी ओर borg serve शुरू करता है और उस 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

एन्क्रिप्शन: इनमें से एक को बंद किया जा सकता है

Restic हमेशा एन्क्रिप्टेड रहता है। इसमें unencrypted mode नहीं होता। restic init पासवर्ड मांगता है, scrypt की मदद से उससे key बनाता है, और उसके बाद लिखी जाने वाली प्रत्येक pack file को एन्क्रिप्ट और authenticated किया जाता है। पासवर्ड खोने पर data समाप्त हो जाता है, क्योंकि design के अनुसार recovery path मौजूद नहीं है।

Borg repository बनाते समय encryption को वैकल्पिक रखता है, और यह विकल्प स्थायी होता है। 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 से authentication करता है। SHA acceleration के बिना hardware पर यह तेज़ होता है। --encryption=none भी उपलब्ध है। जब repository आपके स्वामित्व वाली encrypted disk पर हो, तब यह वास्तविक विकल्प है।

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

Compression और restic को यह सुविधा देर से क्यों मिली

Borg में शुरुआत से ही Compression उपलब्ध है। डिफ़ॉल्ट विकल्प lz4 है। इसे इसलिए चुना गया है क्योंकि यह इतना तेज़ है कि इसे हर जगह सक्षम रखा जा सकता है। zstd में 1 से 22 तक के levels स्वीकार किए जाते हैं और डिफ़ॉल्ट 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 या उसके बाद का version आवश्यक है। नए repository के लिए अब format 2 डिफ़ॉल्ट है। Compression को --compression के साथ auto, off या max values पर सेट किया जाता है। पुराना format 1 repository तब तक uncompressed रहता है, जब तक आप उसे migrate नहीं करते। इसलिए यदि आपका restic repository 0.14 से पहले का है और आपने उसे कभी migrate नहीं किया, तो text, logs और database dumps के लिए अभी भी पूरा size खर्च हो रहा है।

दूरस्थ लक्ष्य: S3 बनाम SSH

आमतौर पर चुनाव यहीं किया जाता है।

S3 तक पहुंचने के लिए Restic को 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

दूरस्थ repository तक पहुंचने के लिए Borg को SSH और दूसरी ओर Borg की installation चाहिए। वहां का version client के साथ compatible होना चाहिए। यदि दूसरी ओर का server आपके नियंत्रण में नहीं है, तो यह अतिरिक्त जटिलता है। यदि वह दूसरा server है जिसे आप पहले से administer करते हैं, तो इसमें कोई समस्या नहीं है। इसके बदले आपको ransomware से बचाव के लिए दोनों tools में उपलब्ध सबसे मजबूत नियंत्रण मिलता है: 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 का समर्थन करता है। सामान्य S3 के साथ यही प्रभाव bucket policy या object lock से मिलता है। यह provider की जिम्मेदारी है, Restic की नहीं। Transport को भी सुरक्षित करें। SSH वाले हिस्से को किसी भी अन्य login की तरह सावधानी चाहिए: backup account पर restricted authorized_keys entry के साथ केवल key वाला SSH लागू करें।

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

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

SSH पर Borg अधिक latency वाले लिंक पर तेज़ है, क्योंकि सर्वर साइड में समझदारी से काम करने वाली प्रक्रिया होती है। क्लाइंट एक प्रश्न भेजता है, रिमोट borg serve प्रक्रिया repository index से उसका उत्तर देती है, और transaction एक ही स्थान पर commit होता है। प्रत्येक छोटी फ़ाइल के लिए chunk lookup अलग network round trip नहीं बनता।

Object storage पर Restic में सर्वर साइड प्रक्रिया नहीं होती। इसलिए उसे HTTP के माध्यम से प्राप्त की गई index files और pack files से अपनी स्थिति तैयार करनी पड़ती है। अनुरोधों की संख्या को नियंत्रित रखने के लिए यह upload से पहले कई छोटे chunks को बड़ी pack files में रखता है। अगली run में पूरे index को दोबारा fetch न करना पड़े, इसके लिए यह ~/.cache/restic में local cache रखता है। इस cache को delete करने पर अगला backup धीमा होगा, क्योंकि cache फिर से तैयार किया जाएगा। लाखों छोटी फ़ाइलों वाले high latency लिंक पर यही स्थिति है जिसमें उसी डेटा पर Restic, Borg की तुलना में धीमा लगता है।

Local disk या fast LAN पर यह अंतर अधिकांशतः समाप्त हो जाता है। इसके बाद दोनों tools की गति मुख्यतः इस बात से सीमित होती है कि वे source को कितनी तेज़ी से read और hash कर सकते हैं।

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

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

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

Retention: forget और 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 खाली नहीं करता। Space तब वापस मिलता है जब borg compact चलता है। इसलिए ऐसा cron job, जो prune चलाता है लेकिन compact नहीं चलाता, archive list छोटी रहने के बावजूद repository को लगातार बड़ा करता रहता है। restic में, forget को --prune के बिना चलाने पर केवल snapshot references हटते हैं। Data तब तक बना रहता है, जब तक prune नहीं चलता।

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

आप चाहे जो भी टूल चुनें, schedule केवल आधा काम है। किसी ऐसे timer पर scratch directory में restore चलाएँ जिसे आप वास्तव में monitor करते हों। VPS के लिए restic backup guide का शेष भाग भी systemd timer के साथ यही करता है।

कौन सा विकल्प किस कार्य के लिए बेहतर है

जब लक्ष्य object storage हो, जब आप एक ही binary चाहते हों और दूर वाले सिस्टम पर कोई software न हो, जब कई मशीनों को एक-दूसरे के डेटा से deduplicate करना हो, या जब 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 पर लागू होता है, क्योंकि किसी random moment पर copy की गई live database file, database का backup नहीं होती।

FAQ

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

स्थानीय डिस्क या तेज़ LAN पर दोनों की गति लगभग समान होती है। दोनों में स्रोत पर पढ़ने और hash करने की गति सीमा बन जाती है। बहुत-सी छोटी फ़ाइलों वाले उच्च-latency SSH link पर Borg आमतौर पर बेहतर होता है, क्योंकि दूरस्थ सिस्टम पर चलने वाली borg serve प्रक्रिया प्रत्येक chunk के लिए network round trip किए बिना index संबंधी प्रश्नों का उत्तर देती है। जब target object storage हो, तब restic आमतौर पर बेहतर होता है, क्योंकि Borg वहां सीधे काम नहीं कर सकता।

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

सीधे नहीं। Borg repository को SSH के माध्यम से borg serve प्रक्रिया उपलब्ध कराती है। Bucket के अंदर ऐसी कोई प्रक्रिया नहीं चलती। कुछ लोग rclone की सहायता से object storage को filesystem के रूप में mount करके इसका workaround करते हैं। Borg project इसकी अनुशंसा नहीं करता, क्योंकि transaction के बीच mount हटने पर repository corrupt हो सकती है। यदि आपको object storage चाहिए, तो restic का उपयोग करें।

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

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

यदि repository password खो जाए तो क्या होगा?

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

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

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