VPS का backup लें जिसे आप वाकई restore कर सकें

किसी से भी पूछिए कि वे backup क्यों लेते हैं, और जवाब अक्सर होता है “अगर डिस्क ख़राब हो जाए तो”। एक आधुनिक VPS पर आपके साथ यह होना लगभग सबसे कम संभावित बात है। आपका volume redundant array में NVMe पर टिका होता है, साथ में एक hypervisor जो किसी फेल होते host से आपको आपके नोटिस करने से पहले ही हटा देगा; drive फेल होना प्रोवाइडर की समस्या है, और वह एक सुलझी हुई समस्या है। अपनी पूरी backup रणनीति को इसके इर्द-गिर्द बनाना ऐसा है जैसे किसी ऐसे घर के लिए fire extinguisher ख़रीदना जिसमें बाढ़ आती हो।

लोगों का डेटा असल में क्या ले जाता है, यह रहा — मोटे तौर पर आवृत्ति (frequency) के क्रम में। पहला, और बड़े अंतर से: आप ख़ुद। एक rm -rf जिसमें कोई variable ख़ाली निकल गया। ग़लत terminal पर एक DROP DATABASE, क्योंकि दो tabs बिल्कुल एक जैसे दिख रहे थे। दो बार चलाई गई एक migration स्क्रिप्ट। एक docker compose down -v जिसमें -v लगाना हाथ की आदत बन चुका था। ये कोई अनोखी बातें नहीं हैं; ये तो बस एक और मंगलवार है।

दूसरा, वे application जो अपना ही डेटा मिटा देते हैं। कोई upgrade जो एक विनाशकारी migration चलाकर आधे में फेल हो जाए। कोई plugin जो एक cache डायरेक्टरी साफ़ कर दे जो असल में cache थी ही नहीं। ग़लत path पर सेट की गई log rotation। तीसरा, compromise — और ग़ौर करें कि यह वह मामला है जहाँ एक हमलावर backups का मिट जाना चाहता है, जो डिज़ाइन को उन तरीक़ों से बदल देता है जिन पर हम आगे लौटेंगे। चौथा, और no-KYC host पर भूल जाना आसान: अकाउंट खो देना। ऐसा बैलेंस जो आपकी ग़ैर-मौजूदगी में ज़ीरो हो गया, password manager की कोई ऐसी एंट्री जो आपने कभी लिखी ही नहीं, कोई ईमेल पता जिसे आपने छोड़ दिया। हम ज़ीरो बैलेंस के कुछ ही घंटों में सस्पेंड कर देते हैं और सात दिन बाद मिटा देते हैं, और यह जान-बूझकर बेरहम रखा गया है — यही वह अंकगणित है जो हमें यह पूछने से बचाता है कि आप कौन हैं। कोई support agent नहीं है जो आपकी पहचान ढूँढकर कोई अपवाद बना दे, क्योंकि ढूँढने के लिए कोई पहचान है ही नहीं।

यही आख़िरी श्रेणी है जो privacy-first hosting को मुख्यधारा वाली hosting से अलग करती है, और इसे आपकी योजना तय करनी चाहिए। हर वह नियंत्रण जो इस सर्वर को आपसे जोड़ना मुश्किल बनाता है, वह किसी के लिए भी — हमारे लिए भी — इसे आपको वापस लौटाना उतना ही मुश्किल बना देता है। Backup ही वह चीज़ है जो इस सौदे को एक जोखिम से एक विकल्प में बदल देती है।

Snapshots शानदार हैं और आपको इन्हें इस्तेमाल करना चाहिए। हर kernel upgrade से पहले, हर database migration से पहले, और जब भी आप कुछ ऐसा करने वाले हों जिसे बाद में पलटना चाहेंगे, तब एक snapshot ले लें। ये सेकंडों में restore हो जाते हैं, इनकी क़ीमत लगभग कुछ भी नहीं है, और साल में एक दर्जन बार ये आपकी एक पूरी दोपहर बचा देंगे।

फिर भी ये backups नहीं हैं, तीन संरचनात्मक वजहों से, जिन्हें प्रोवाइडर की कितनी भी मार्केटिंग नहीं बदल सकती। ये उसी अकाउंट के भीतर रहते हैं: जो कोई भी आपके panel में लॉगिन कर सकता है वह इन्हें मिटा भी सकता है, और अगर अकाउंट काम करना बंद कर दे तो snapshots भी उसी के साथ ख़त्म हो जाते हैं। ये उसी failure domain में रहते हैं: वही प्रोवाइडर, वही control plane, अक्सर वही storage cluster — मतलब एक ही बुरी घटना असली और कॉपी, दोनों को साथ ले जा सकती है। और ये अपारदर्शी हैं: चलती हुई मशीन का एक snapshot किसी डेटाबेस को mid-write उतनी ही ईमानदारी से पकड़ता है जितनी बाक़ी सब कुछ, इसलिए किसी व्यस्त MySQL सर्वर के snapshot से restore करने पर आपको एक साफ़-सुथरा डेटाबेस नहीं, बल्कि crash-recovery वाली स्थिति मिलती है।

पुराना 3-2-1 नियम — तीन कॉपियाँ, दो तरह के मीडिया पर, जिनमें से एक off-site — आमतौर पर बिना यह नोटिस किए दोहराया जाता है कि किराए के infrastructure पर बीच वाला हिस्सा बेमानी है। आपके पास दो तरह का मीडिया होता ही नहीं। आपके पास एक virtual block device है, और एक और virtual block device, और दोनों ही किसी और का SAN हैं। VPS पर तर्जुमा होने के बाद जो हिस्सा बचता है, वही हमेशा से मायने रखता था: कम से कम एक कॉपी ऐसी जगह होनी चाहिए जहाँ एक अकेली बुरी घटना न पहुँच सके। अलग प्रोवाइडर, या कम से कम अलग क्षेत्र, अलग credentials, अलग अकाउंट, और — अगर offshore host करने की वजह क़ानूनी है न कि तकनीकी — तो एक अलग jurisdiction भी, ताकि एक ही अदालती आदेश दोनों कॉपियों पर एक साथ न आ गिरे।

यह वह सेक्शन है जो बाक़ी backup ट्यूटोरियल्स में नहीं मिलता, और अगर आपने इस सर्वर के लिए Monero से भुगतान किया है तो यही सबसे ज़्यादा मायने रखता है।

इंटरनेट पर हर जगह मिलने वाली डिफ़ॉल्ट सलाह यह है कि अपने backups को किसी object store पर push करें: Backblaze B2, Amazon S3, Wasabi, या rclone के ज़रिए कोई Google Drive। यह सस्ता है, टिकाऊ है, और काम करता है। यह एक ही कमांड में आपकी अब तक की सारी मेहनत को उलट भी देता है। वह अकाउंट खोलने के लिए एक कार्ड और आमतौर पर एक पहचान दस्तावेज़ चाहिए था। जिस पल पहला snapshot अपलोड होता है, उसी पल से वह प्रोवाइडर आपका नाम और भुगतान विवरण को आपके सर्वर के IP पते से जोड़ता हुआ एक टाइमस्टैम्प वाला रिकॉर्ड रखता है, जो हर घंटे रिफ़्रेश होता है, हमेशा के लिए। आपने अपनी पहचान हमसे सत्यापित नहीं करवाई; आपने वह उनसे करवाई, और फिर आपने ख़ुद दोनों के बीच एक लकीर खींच दी।

दूसरा आधा हिस्सा और बुरा है, और यही वह हिस्सा है जिसे लोग चूक जाते हैं। जो API key उन अपलोड्स को authorise करती है, वह प्रोडक्शन सर्वर पर पड़ी एक फ़ाइल है। जो कोई भी उस बॉक्स पर root हासिल कर ले — या जो कोई भी क़ानूनी तौर पर वह डिस्क हासिल कर ले — वह सिर्फ़ आपका डेटा नहीं पाता। उसे एक ऐसा credential मिल जाता है जो एक ही API कॉल में एक billing identity तक पहुँचा देता है। गुमनाम सर्वर अब आपके बैंक की तरफ़ इशारा करता एक साइनपोस्ट बन चुका है।

इनमें से कुछ भी object storage को ग़लत नहीं बनाता। यह बस इसे एक डिफ़ॉल्ट की बजाय एक फ़ैसला बना देता है। तीन रास्ते बाहर निकलने के, इस क्रम में कि वे आपकी शुरुआत की चीज़ को कितनी अच्छी तरह बचाए रखते हैं:

• एक दूसरा no-KYC VPS, आदर्श रूप से प्रोडक्शन से अलग jurisdiction में, उसी crypto बैलेंस से भुगतान किया हुआ। गंतव्य स्रोत के गुमनामी वाले गुणों को अपना लेता है, उनके ख़िलाफ़ जाने की बजाय। यही हम करते हैं, और यही इस बाक़ी गाइड की धारणा है।
• ऐसा storage प्रोवाइडर जो बिना पहचान के crypto लेता हो। ऐसे प्रोवाइडर मौजूद हैं; वे छोटे होते हैं; marketing पर भरोसा करने से पहले जाँच लें कि payment का रास्ता वाक़ई पहचान-मुक्त है या नहीं, और egress की क़ीमत भी पहले जाँच लें, न कि किसी restore के दौरान पता चले।
• एक ऐसी मशीन जो आपकी अपनी भौतिक संपत्ति हो, जो आपके अपने कनेक्शन के पीछे से WireGuard के ज़रिए pull करे। गुमनामी के लिए बेहतरीन, उपलब्धता के लिए कमज़ोर, और इसका मतलब है कि आपकी restore स्पीड आपकी घर की अपलोड स्पीड जितनी ही होगी। तीसरी कॉपी के तौर पर ठीक-ठाक, अकेली कॉपी के तौर पर कमज़ोर।

आप जो भी चुनें, जो अकाउंट backups रखता है उसे प्रोडक्शन वाले अकाउंट के साथ credentials, ईमेल पता या recovery रास्ता साझा नहीं करना चाहिए। पूरी बात यही है कि एक compromised login दोनों तक न पहुँच सके। यह ठीक वही अनुशासन है जो कहीं और पहचानों को अलग-अलग रखने में बरता जाता है, बस यहाँ इसे सिस्टम के सबसे कम चमकदार कोने पर लागू किया गया है।

लगभग हर backup ट्यूटोरियल एक ही architecture देता है: प्रोडक्शन सर्वर पर एक cron जॉब जो किसी दूर के repository से authenticate होकर उसमें लिखता है। यह सरल है, काम करता है, और इसमें एक ऐसा गुण है जिसका कोई ज़िक्र नहीं करता — प्रोडक्शन सर्वर के पास एक ऐसा credential होता है जो पूरी repository मिटा सकता है। पुराने snapshots की pruning के लिए delete अधिकार चाहिए होते हैं, इसलिए जो key आपका nightly जॉब चलाती है, वही key तिजोरी को भी ख़ाली कर सकती है।

ज़रा सोचिए कि compromise के दौरान इसका क्या मतलब होता है। बॉक्स पर root रखने वाले हमलावर को आपके backups ढूँढने की ज़रूरत ही नहीं; आपने बड़ी मेहरबानी से उसके लिए एक काम करता हुआ credential और repository का नाम बताने वाली एक config फ़ाइल पहले से छोड़ रखी है। कुछ भी दिखने लायक करने से पहले backups को गिनना और मिटा देना कोई काल्पनिक बारीकी नहीं है — यह मानक तरीक़ा है, क्योंकि यही किसी incident को एक सौदेबाज़ी में बदल देता है। आपकी nightly जॉब असल में एक रेकी (reconnaissance) थी।

तीन डिज़ाइन हैं, और इनके बीच का फ़र्क़ पूरी तरह इस बात पर टिका है कि कौन-सी मशीन कौन-सी key रखती है।

सादा push वही है जो ऊपर बताया गया। प्रोडक्शन के पास read-write-delete होता है। सुविधाजनक, और यह ठीक उसी परिस्थिति में पूरी तरह फेल हो जाता है जहाँ आपको backup की सबसे ज़्यादा ज़रूरत होती है। इसे सिर्फ़ तभी इस्तेमाल करें जब आपकी असली चिंता सिर्फ़ आपकी अपनी उँगलियाँ हों।

Append-only push वही ढाँचा रखता है लेकिन ख़तरनाक क्रिया हटा देता है। repository को कोई ऐसी चीज़ serve करती है जो प्रोटोकॉल समझती है और deletions को मना कर देती है: restic के लिए rest-server --append-only, या authorized_keys से force किया गया borg serve --append-only। प्रोडक्शन नए snapshots बना सकता है और पुराने नहीं हटा सकता। Pruning बाद में, कहीं और से, एक अलग key इस्तेमाल करके होती है। बीस मिनट के काम के बदले यह एक बड़ा सुधार है, और ज़्यादातर लोगों के लिए यहीं रुक जाना सही है।

Pull कनेक्शन को उलट देता है। backup host, SSH के ज़रिए प्रोडक्शन के भीतर पहुँचता है, जो चाहिए वह कॉपी करता है, और backup टूल को अपनी ही डिस्क पर locally चलाता है। प्रोडक्शन के पास कोई backup credential होता ही नहीं — उस मशीन पर ढूँढने के लिए कुछ है ही नहीं, क्योंकि उस मशीन को यह पता ही नहीं कि उसके backups कहाँ रहते हैं। यह सबसे मज़बूत इंतज़ाम है, और नीचे दिया step-by-step तरीक़ा यही बनाता है।

पर ईमानदारी से मानिए कि pull की भी क़ीमत है, क्योंकि यह मुफ़्त नहीं है। आपने key को ख़त्म नहीं किया, बस उसकी जगह बदली है: अब backup host के पास प्रोडक्शन में जाने वाली एक SSH key है, इसलिए backup host का compromise होना आगे live सिस्टम तक पहुँच सकता है। यह फिर भी एक बेहतर सौदा है — backup host कुछ नहीं चलाता, SSH के अलावा कुछ भी उजागर नहीं करता, और एक पब्लिक web सर्वर से कहीं छोटा निशाना है — लेकिन है तो यह एक सौदा ही, और बचे हुए ज़्यादातर अंतर को आप उस key को एक read-only command तक सीमित करके पाट सकते हैं, ताकि उसका इस्तेमाल फ़ाइलें पढ़ने के अलावा कुछ और न हो सके।

तीन टूल लगभग हर मामला कवर कर लेते हैं, और यह चुनाव उतना दर्दनाक नहीं जितना forum की बहसें जताती हैं।

restic डिफ़ॉल्ट रूप से encrypt करता है, snapshots के बीच deduplicate करता है, SFTP, S3, REST और दर्जन भर दूसरे backends की भाषा बोलता है, और एक अकेले static बाइनरी के तौर पर आता है जिसे आप कहीं भी रख सकते हैं। इसका repository फ़ॉर्मेट content-addressed है, इसलिए एक snapshot सस्ता पड़ता है और एक जैसा डेटा सिर्फ़ एक बार स्टोर होता है, चाहे कितनी भी मशीनें उसे भेजें। इसकी क़ीमतें असली हैं पर मामूली: इसे repository index के अनुपात में मेमोरी चाहिए होती है, और कोई बीच में रुका हुआ run एक बासी lock छोड़ सकता है जिसे अगला run तब तक पार नहीं करेगा जब तक आप उसे restic unlock से साफ़ न करें। यही डिफ़ॉल्ट सिफ़ारिश है, और नीचे दिए स्टेप्स इसी का इस्तेमाल करते हैं।

Borg बेहतर deduplicate करता है, बेहतर compress करता है, और लाखों छोटी फ़ाइलों वाली repositories पर साफ़ तौर पर तेज़ है। इसकी क़ीमत जुड़ाव के रूप में चुकानी पड़ती है: Borg को दोनों सिरों पर इंस्टॉल होना चाहिए और वर्शन क़रीब-क़रीब मेल खाने चाहिए, एक repository असल में एक ही client के लिए बनाई गई होती है, और बिना किसी helper layer के इसका कोई native object-store backend नहीं है। अगर आपका स्रोत कोई बड़ा mail spool है या छोटी फ़ाइलों से भरा कोई filesystem, और आप दोनों मशीनों को नियंत्रित करते हैं, तो Borg आधी जगह इस्तेमाल करेगा। इसका --append-only मोड भी इस विचार का दोनों टूल में सबसे साफ़-सुथरा कार्यान्वयन है।

rsync कोई backup टूल नहीं है, और इसे मान लेना ही वह तरीक़ा है जिससे लोगों के पास किसी ख़राब डायरेक्टरी की एक ईमानदारी से मिरर की हुई कॉपी बचती है। इसमें कोई versioning नहीं, कोई deduplication नहीं, और आराम की हालत में कोई encryption नहीं; rsync --delete आपकी ग़लती को कॉपी तक wire की रफ़्तार से पहुँचा देता है। फिर भी यह दो ऐसी मशीनों के बीच bytes ले जाने के लिए सही टूल है जिन्हें आप नियंत्रित करते हैं, और pull डिज़ाइन में यह ठीक यही काम करता है, जबकि bytes पहुँचने के बाद versioning और encryption restic देता है। हर टूल को वही काम दें जो उसका है।

एक चीज़ जो मत कीजिए: tar और तारीख़-वाले filename के सहारे अपना ख़ुद का सिस्टम मत बनाइए। यह क़रीब चार महीने चलता है, जब तक कि वह दिन न आ जाए जब डिस्क भर जाए क्योंकि कभी कुछ expire ही नहीं हुआ, या वह दिन जब आपको पता चले कि 40 GB के डेटासेट की हर रात एक पूरी कॉपी लेने का मतलब है महीने के 1.2 TB storage का ख़र्च, सिर्फ़ तीस लगभग एक जैसी चीज़ों को रखने के लिए।

स्वाभाविक प्रवृत्ति पूरे filesystem का backup लेने की होती है। इससे बचिए। एक root filesystem ज़्यादातर distribution पैकेज ही होते हैं जिन्हें आप नब्बे सेकंड में दोबारा इंस्टॉल कर सकते हैं, और इन्हें शामिल करने पर storage, transfer का समय, और उससे भी बुरा — ध्यान ख़र्च होता है। एक 40 GB का backup जिसे कोई टेस्ट नहीं करना चाहता, उस 900 MB वाले backup से कम काम का है जो हर तिमाही restore होता है।

जो चीज़ें वाक़ई दोबारा नहीं बनाई जा सकतीं, वह सूची छोटी है: /etc (आपका पूरा configuration, और वह वजह जिससे rebuild एक वीकेंड की बजाय एक घंटे में हो जाता है), /home और /root, /srv और /var/www, /var/lib/ और /opt/ के तहत application state, नाम वाले Docker volumes, आपके लिखे cron और systemd units, और आपके database dumps। छोड़ दें /proc, /sys, /dev, /run, /tmp, /var/cache, swap फ़ाइलें, sockets, और /var/lib/docker/overlay2 — यह आख़िरी वाला आपकी compose फ़ाइल से दोबारा बन सकता है और अक्सर डिस्क पर अकेली सबसे बड़ी डायरेक्टरी होता है।

अब वह हिस्सा जो restores को चुपचाप बर्बाद कर देता है। डेटाबेस के चलते हुए उसकी data डायरेक्टरी कॉपी करने से जो फ़ाइल सेट बनता है, वह बहुत मुमकिन है कि बेकार निकले। इंजन अपनी स्थिति मेमोरी में रखता है, कई फ़ाइलों में एक ऐसे क्रम में लिखता है जो मायने रखता है, और आपकी कॉपी उस ट्री पर कई मिनटों तक चलती है, हर बार अलग-अलग पल पर अलग-अलग फ़ाइलें पकड़ते हुए। InnoDB कभी-कभी इससे crash-recover कर लेता है और कभी-कभी नहीं; और यह गड़बड़ महीनों बाद, किसी ऐसे restore के दौरान सामने आती है जब आपका दिन पहले से ही ख़राब चल रहा होता है।

इसकी बजाय इंजन के ज़रिए dump लें, फिर उस dump का backup लें:

# MariaDB / MySQL — InnoDB gets a consistent snapshot from one transaction
mariadb-dump --single-transaction --quick --routines --triggers --events \
  --all-databases | zstd -T0 > /var/backups/db/all-$(date -u +%F).sql.zst

# PostgreSQL — pg_dump is consistent by design; grab roles separately
pg_dumpall --globals-only > /var/backups/db/globals.sql
pg_dump -Fc -Z6 mydb    > /var/backups/db/mydb.dump

# SQLite — never cp a live database; WAL mode makes that a torn file
sqlite3 /var/lib/app/app.db ".backup /var/backups/db/app.db"

दो टिप्पणियाँ याद रखने लायक हैं। --single-transaction सिर्फ़ InnoDB के लिए consistency देता है — अगर कोई टेबल अब भी MyISAM है तो वह transaction के बाहर कॉपी होती है और बाक़ी से असंगत हो सकती है, इसलिए उन टेबलों को बदल दें या lock कर दें। और जब आप dump ले ही रहे हैं, तो live data डायरेक्टरी को file pass से बाहर रखें। दोनों का backup लेने का मतलब है एक बड़ी फटी हुई कॉपी को अच्छी वाली के साथ स्टोर करना, और भविष्य के किसी restore को दो उम्मीदवार थमा देना जिनमें से एक चुपचाप ग़लत है।

Containers इस सिद्धांत को नहीं बदलते, बस रास्ता बदलते हैं: dump को docker compose exec -T db mariadb-dump … से चलाएँ और जो फ़ाइल बने उसी का backup लें, नीचे वाले volume का नहीं।

Client-side encryption ही वह पूरी वजह है जिससे आपके डेटा को उस मशीन से अलग किसी और मशीन पर रखना स्वीकार्य बन जाता है जहाँ से वह आया था। restic और Borg दोनों कुछ भी स्रोत छोड़ने से पहले ही encrypt कर देते हैं, इसलिए backup host के पास सिर्फ़ ciphertext रहता है और उसे untrusted storage माना जा सकता है। यह गुण ठीक उतना ही मूल्यवान है जितनी अच्छी तरह आप key संभालते हैं, उससे ज़्यादा नहीं।

फेल होने का यह तरीक़ा निराशाजनक हद तक आम है। repository का पासवर्ड प्रोडक्शन सर्वर पर /etc/restic/env में रहता है, जो automation के लिए ठीक भी है और ज़रूरी भी। फिर ठीक प्रोडक्शन ही वह चीज़ बन जाती है जिसे आप खो देते हैं — तबाह, ज़ब्त, या बस अकाउंट के साथ ग़ायब — और अब आपके सामने कई सौ गीगाबाइट encrypted ब्लॉक्स हैं, और यह धीरे-धीरे उतरता एहसास कि key की इकलौती कॉपी उसी चीज़ के भीतर थी जिससे खोने से बचाने के लिए आपने यह सब किया था।

तो: सर्वर पर मौजूद पासवर्ड एक working copy है, कभी असली रिकॉर्ड नहीं। असली रिकॉर्ड कहीं ऐसी जगह रहता है जो सर्वर से आगे बचा रहे — कोई password manager जिसका vault ख़ुद कहीं और backed up हो, या दराज़ में काग़ज़ पर लिखा हुआ, या दोनों। repository का पता और उसके ठीक बग़ल में सटीक restore command लिख लें, क्योंकि बिना किसी संदर्भ वाला पासफ़्रेज़ एक ऐसी पहेली है जिसे आप अठारह महीने बाद तनाव में सुलझा रहे होंगे। और इसे verify करने के लिए पाँच मिनट निकालें: किसी दूसरी मशीन से, सिर्फ़ वही इस्तेमाल करके जो password manager में है, repository पर restic snapshots चलाएँ। अगर यह काम कर जाए, तो आपके पास एक backup है। अगर इसके लिए कुछ ऐसा चाहिए जो सिर्फ़ प्रोडक्शन पर मौजूद है, तो आपके पास बस एक बहुत महँगा फ़ोल्डर है।

दोनों टूल एक ही repository पर कई keys रखने का समर्थन करते हैं (restic key add), जो pruning जॉब या किसी दूसरे admin को असली पासफ़्रेज़ साझा किए बिना पहुँच देने का साफ़-सुथरा तरीक़ा है। और अगर प्रोडक्शन डिस्क LUKS से encrypted है, तो दोनों secrets को वाक़ई अलग-अलग रखें — restic पासफ़्रेज़ को LUKS volume के भीतर, और LUKS पासफ़्रेज़ को restic repository के भीतर रखना एक ऐसा लूप है जो दोनों तरफ़ से बंद होकर फेल होता है।

Retention देखने में storage-लागत का सवाल लगता है, पर असल में यह detection-latency का सवाल है। जो नंबर मायने रखता है वह यह नहीं कि आप कितनी डिस्क ख़र्च करना चाहते हैं; यह है कि आपके सिस्टम में कोई समस्या कितनी देर तक बिना पकड़ में आए रह सकती है। वह अवधि जो भी हो, आपका सबसे पुराना backup उससे भी पुराना होना चाहिए।

सात रोज़ाना snapshots उदार लगते हैं पर व्यवहार में पतले साबित होते हैं। कोई ख़राब टेबल जिस पर कोई query नहीं चलाता, किसी बदतमीज़ cron जॉब की धीमी deletion, कोई घुसपैठ जो कुछ भी दिखने लायक करने से पहले एक महीने तक चुपचाप बैठी रही — ये सब आमतौर पर सामने आने में एक हफ़्ते से ज़्यादा वक़्त लेते हैं, और अगर आपकी history सिर्फ़ सात दिन गहरी है तो आपके पास मौजूद हर snapshot पहले से ही दूषित है। असली घुसपैठों में ठहराव का समय अक्सर हफ़्तों में नापा जाता है। सस्ते मासिक snapshots ठीक इसी के ख़िलाफ़ बचाव हैं, और deduplication इन्हें वाक़ई बहुत सस्ता बना देता है: एक साल तक रखा गया मासिक snapshot एक पूरी कॉपी का बस एक छोटा-सा हिस्सा जोड़ता है, क्योंकि सिर्फ़ वही ब्लॉक्स दोबारा स्टोर होते हैं जो असल में बदले।

restic forget \
  --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 2 \
  --prune

यह सीढ़ी — दिनों का एक हफ़्ता, हफ़्तों का एक महीना, महीनों का एक साल, सालों के कुछ साल — लगभग छब्बीस snapshots बनती है, और सामान्य डेटा पर, एक अकेली पूरी कॉपी के आकार से भी कहीं कम, दोगुने से भी कम में। जब तक आपके पास इससे हटने की कोई ख़ास वजह न हो, हम इसी को डिफ़ॉल्ट मानने की सलाह देंगे।

दो परिचालन टिप्पणियाँ। बिना --prune के forget सिर्फ़ लेबल हटाता है, इसलिए जगह तब तक वापस नहीं मिलती जब तक आप prune न करें — जो उन लोगों को चौंका देता है जो देख रहे होते हैं कि डिस्क सिकुड़ ही नहीं रही। और --prune को repository पर delete अधिकार चाहिए होते हैं, इसलिए append-only या pull डिज़ाइन में यह प्रोडक्शन सर्वर पर नहीं चलता। यह backup host पर, या आपके laptop से चलता है, ऐसी key के साथ जिसे प्रोडक्शन ने कभी देखा ही नहीं। यही अलगाव पूरी बात है; आख़िरी कदम पर सुविधा के लिए इसे मत मिटाइए।

क्लासिक backup आपदा कोई ऐसा जॉब नहीं है जो crash हो जाए। यह वह जॉब है जो चलना बंद कर दे और किसी को बताए ही नहीं, और ग्यारह महीने बाद उस किसी को पता चले जिसे उसकी ज़रूरत थी। नीचे दी गई हर चीज़ इसी ख़ास नतीजे को नामुमकिन बनाने के लिए है।

cron की बजाय एक systemd टाइमर इस्तेमाल करें। आपको journal में असली logs मिलते हैं, exit status के साथ, Persistent=true जिससे मशीन के बंद रहने के दौरान छूटा हुआ run हमेशा के लिए टलने की बजाय अगले boot पर हो जाता है, और RandomizedDelaySec जिससे कोई पूरा fleet ठीक 03:00 बजे backup host पर एक साथ टूट नहीं पड़ता। Cron का नाकामी नोटिफ़िकेशन किसी local mailbox को भेजी एक ईमेल है, जो किसी आधुनिक सर्वर पर बिल्कुल कहीं नहीं पहुँचती।

# /etc/systemd/system/backup.timer
[Unit]
Description=Nightly encrypted backup

[Timer]
OnCalendar=*-*-* 03:17:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target

फिर एक dead man's switch जोड़ें, जो इस पूरी गाइड की सबसे ज़्यादा मूल्यवान इकलौती लाइन है। स्क्रिप्ट के बिल्कुल आख़िर में — backup सफल होने के बाद, पहले नहीं — किसी ऐसे मॉनिटर को एक HTTPS रिक्वेस्ट भेजें जो आपसे रोज़ाना सुनने की उम्मीद रखता हो और न सुनने पर अलर्ट करे। यह नोटिफ़िकेशन के तर्क को उलट देता है: किसी नाकामी के संदेश भेजने पर निर्भर रहने की बजाय, ग़ैर-मौजूदगी ख़ुद ही अलार्म बन जाती है। तीन दिन से मरा पड़ा जॉब तब किसी संकट में अचानक हुई खोज नहीं, बल्कि आपके inbox में एक संदेश भर बनकर रह जाता है। अगर आप कोई और third-party अकाउंट नहीं बनाना चाहते, तो मॉनिटर को backup host पर ही self-host कर लें; यह बस कुछ लाइनें हैं और अपना एक टाइमर।

आख़िर में, वे छोटे परिचालन ख़तरे जिनसे हम ख़ुद कम से कम एक बार टकरा चुके हैं। कोई बीच में रुका हुआ run एक lock छोड़ जाता है और हर अगला run उस संदेश के साथ फेल होता है जिसे आप चौथी रात के बाद पढ़ना बंद कर देते हैं — restic unlock को जान-बूझकर संभालें, बिना सोचे-समझे नहीं। एक भरी हुई गंतव्य डिस्क तब तक हर जॉब फेल करती रहती है जब तक कोई देखे न; job status पर नहीं, ख़ाली जगह पर अलर्ट लगाएँ। किसी SSH key का expire होना, कोई घुमाई गई host key, किसी असंबंधित काम के दौरान जोड़ा गया कोई nftables rule — इनमें से हर एक चुपचाप pull को काट देगा। और सिर्फ़ start नहीं, systemctl enable --now: जो टाइमर कभी enable ही नहीं हुआ, वह पहले reboot तक ख़ूबसूरती से चलता है और फिर कभी नहीं चलता।

ऊपर बताई गई हर चीज़ सिर्फ़ तैयारी है। यही वह हिस्सा है जो इसे एक backup में बदलता है, और यही वह हिस्सा है जिसे लगभग हर कोई छोड़ देता है।

हर तिमाही में एक बार, एक नया VPS deploy करें — $5 वाला Starter काफ़ी है और बिलिंग घंटे के हिसाब से, सेकंड तक की सटीक गणना के साथ होती है, इसलिए पूरी कवायद के बस कुछ ही सेंट ख़र्च होते हैं। उसमें सिर्फ़ वही इस्तेमाल करके restore करें जो किसी असली आपदा में आपके पास होता: repository का पता, password manager से लिया गया पासफ़्रेज़, और लिखी हुई प्रक्रिया। जान-बूझकर प्रोडक्शन से कुछ भी इस्तेमाल न करें, क्योंकि जिस परिदृश्य का आप अभ्यास कर रहे हैं उसमें प्रोडक्शन मौजूद ही नहीं है। Application को चालू करें, किसी hosts-file एंट्री को नए IP पर इंगित करें, इधर-उधर क्लिक करके देखें। फिर उसे मिटा दें।

# on a throwaway machine, with nothing but the passphrase
export RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/prod
restic snapshots                      # can you even see the history?
restic restore latest --target /restore
restic check --read-data-subset=10%   # verify stored blocks, not just metadata

यह जो पकड़ता है वह कभी वह नहीं होता जिसकी आप उम्मीद करते हैं। यह वह config फ़ाइल होती है जो किसी ऐसी डायरेक्टरी में थी जिसे include लिस्ट ने कवर ही नहीं किया। वह database dump जो पाँच हफ़्तों से ज़ीरो bytes का पड़ा है क्योंकि एक पासवर्ड बदल गया और स्क्रिप्ट ने अपना exit status जाँचा ही नहीं। वह application जो शुरू ही नहीं होगा क्योंकि एक secret orchestrator के पास मौजूद किसी environment variable में रहता है और कभी filesystem में था ही नहीं। वह DNS रिकॉर्ड जो कहीं दर्ज ही नहीं। वह certificate जिसे 443 पर कुछ भी जवाब देने से पहले दोबारा जारी करना पड़ता है। इनमें से हर एक किसी शांत दोपहर में दस मिनट का फ़िक्स है, और रात तीन बजे के दो भद्दे घंटे।

यह लिख लें कि ड्रिल को शुरू से आख़िर तक कितना समय लगा। यही नंबर — न कि backup की frequency — आपका असली recovery time है, और जब कोई पूछे कि आप कितनी देर के लिए down रहेंगे, तो यही इकलौता ईमानदार जवाब है। एक मासिक टाइमर में restic check --read-data-subset=5% भी जोड़ दें: यह सिर्फ़ index नहीं, बल्कि असल में स्टोर किए गए blocks के एक घूमते हुए नमूने को पढ़ता और verify करता है, और यही वह तरीक़ा है जिससे आप ख़ामोश corruption को तब पकड़ लेते हैं जब वापस गिरने के लिए अभी भी एक अच्छी कॉपी मौजूद हो। अगर आप कभी पूरे सर्वर को किसी नए host पर माइग्रेट करें, तो एक अभ्यास किया हुआ restore माइग्रेशन का ज़्यादातर हिस्सा पहले ही पूरा कर चुका होता है।