backup strategy की असली परीक्षा उस रात नहीं होती जब server मर जाता है। यह हफ़्तों पहले, तीन खामोश फ़ैसलों में तय हो चुकी होती है जिन्हें कोई लिखकर नहीं रखता: copy कहाँ जाएगी, उसे मिटाने का हक़ किसे है, और क्या किसी ने वाकई उसे वापस पढ़कर देखा है।
जो hosting आपकी पहचान कभी माँगती ही नहीं, वह बदले में कुछ छोड़ भी देती है, और यही जगह है इसे साफ़ कहने की। यहाँ फ़ोन करने के लिए कोई account manager नहीं है, कोई ऐसा ticket नहीं जो मिटा हुआ volume वापस ज़िंदा कर दे, और हमारी अपनी retention policy इसकी वजह साफ़-साफ़ बताती है: termination के 24 घंटे के भीतर server का data नष्ट कर दिया जाता है, disks को format नहीं बल्कि cryptographically wipe किया जाता है, और कोई भी backup रखा नहीं जाता। यही खूबी दूसरी तरफ़ से देखने पर इस platform को खरीदने लायक बनाती है। किसी बुरी रात के बाद जो कुछ भी आपको वापस चाहिए, वह पहले से ही कहीं और होना चाहिए — और उसे वहाँ पहुँचाने वाले आप ही हैं।
server को असल में बर्बाद कौन करता है
लगभग कोई भी अपना server उस तरह से नहीं खोता जैसा वह सोचता है। भयंकर hardware failure सच में होती है, पर कम ही, और यह वह इकलौता मामला है जिसके ख़िलाफ़ एक सक्षम host पहले से ही तैयारी कर चुका होता है। जो नुकसान असल में होते हैं वे उससे कहीं ज़्यादा फीके होते हैं, और हर एक अलग तरह की copy को मात देता है — इसीलिए "मेरे पास backup है" तब तक कोई जवाब नहीं है जब तक आप यह न बताएँ कि इनमें से किससे वह बचता है।
| क्या गड़बड़ होती है | यह आम तौर पर कैसे होता है | वापसी किससे मिलती है |
|---|---|---|
| आपका अपना हाथ | एक खाली shell variable के साथ चला rm -rf, production की तरफ़ इशारा करता एक migration, ग़लत table गिरा देने वाला एक deploy | ग़लती से पहले की कोई भी off-box copy — यानी retention को आपके ग़ौर करने में लगने वाले समय से कहीं आगे तक पहुँचना होगा |
| ख़ामोश corruption | मरता हुआ NVMe, reboot के दौरान अधूरा लिखा गया data, एक हफ़्ते से ख़राब rows लिख रहा database | किसी भरोसेमंद बिंदु तक पहुँचने लायक गहरी versioned copies। एक अकेली mirrored copy नुकसान को भी उतनी ही ईमानदारी से mirror कर देती है |
| Compromise | एक चुराई गई key, एक बिना patch वाला application, एक ज़हरीली dependency — और फिर, जान-बूझकर, आपके backups | ऐसी copy जिसे मिटाने की ताक़त compromise हुई machine के पास कभी थी ही नहीं। यहाँ बस यही मायने रखता है |
| किसी provider या देश से जुड़ी घटना | Hardware का नुकसान, datacentre पर कोई क़ानूनी कार्रवाई, ऐसा account या token जिस तक अब आपकी पहुँच नहीं | ऐसी copy जो न उस provider के पास हो, न उस jurisdiction के अंदर |
| key खो देना | भूला हुआ passphrase, server के साथ ही मिट गई keyfile, कभी export न की गई LUKS header | कुछ नहीं। यह इकलौती पंक्ति है जिसमें वापसी का कोई रास्ता नहीं, और यह hardware failure से भी ज़्यादा आम है |
इस table को डर की सूची नहीं, checklist की तरह पढ़ें। एक ही machine की दूसरी disk पर हर रात जाने वाली copy सिर्फ़ पहली पंक्ति का जवाब देती है, और कुछ नहीं। उसी panel में रखा snapshot पहली और दूसरी दोनों पंक्तियों का जवाब देता है। सिर्फ़ वह copy जो server की पहुँच से बाहर, आपके पास मौजूद किसी key के तहत रखी हो, पाँचों का जवाब देती है।
snapshot backup नहीं है, और आपका host भी नहीं
snapshots जो करते हैं उसमें बेहतरीन हैं: वे किसी ग़लत upgrade को सेकंडों में, बिना कोई transfer किए, वापस पलट देते हैं। जो वे नहीं कर सकते वह है server को ले जाने वाली घटना से बच पाना, क्योंकि वे उसी के साथ हर failure domain बाँटते हैं — वही provider, वही account, वही billing token, वही देश, अक्सर वही storage cluster भी। snapshot आपको ख़ुद से बचाता है। backup आपको बाक़ी सब चीज़ों से बचाता है।
यहाँ यह फ़र्क़ किसी mainstream host के मुक़ाबले कहीं ज़्यादा मायने रखता है, क्योंकि आम safety nets जान-बूझकर हटा दिए गए हैं। कोई भी customer के server में लॉग-इन नहीं करता, इसलिए किसी को पता ही नहीं चलता कि आपका backup job मार्च से fail हो रहा है। account से कोई पहचान जुड़ी नहीं होती, इसलिए "साबित करें कि आप कौन हैं और हम इसे restore कर देंगे" जैसा कोई इंसानी रास्ता भी नहीं बचता। और termination सचमुच अंतिम होता है: एक ख़त्म हो चुका balance billing की नहीं, data खोने की घटना है।
24 घंटे वाली शर्त ही पूरी दलील है। इस platform पर किसी terminate किए गए server का data एक दिन के भीतर नष्ट कर दिया जाता है, और disks को format नहीं बल्कि cryptographically wipe किया जाता है। यहाँ न कोई undelete है, न कोई चुपचाप चलने वाला cold-storage tier, न ही support का कोई ऐसा नतीजा जो "हमें एक पुरानी copy मिल गई" पर ख़त्म हो — क्योंकि एक copy रखने का मतलब होगा आपके मना करने के बाद भी आपका data पास रखना। safety net और privacy, दोनों एक ही सौदे का हिस्सा हैं, जो एक बार में तय हो चुका।
3-2-1 नियम, उनके लिए फिर से लिखा गया जिन्होंने कभी कोई ID नहीं दिखाई
पारंपरिक नियम कहता है: तीन copies, दो तरह के media पर, जिनमें से एक off-site हो। यह tape और spinning disk के ज़माने के लिए लिखा गया था, और media वाली शर्त चुपचाप बेमानी हो चुकी है: आपकी production disk भी NVMe है, आपके backup target की disk भी NVMe है, और इसे "दो media" कहना बस अपने आप को सुनाई गई एक कहानी है। बचाने लायक शर्त दूरी वाली है, और offshore infrastructure में दूरी किलोमीटर में नहीं नापी जाती।
इसे यूँ फिर से लिखें: तीन copies, दो providers, दो jurisdictions। जो घटनाएँ दोनों copies को एक साथ ख़त्म करती हैं वे लगभग कभी भौतिक नहीं होतीं — वे होती हैं किसी account तक खो चुकी पहुँच, किसी provider का बुरा हफ़्ता, या किसी एक देश में असर डालने वाला और दूसरे में बेअसर एक क़ानूनी आदेश। एक ही rack में रखे दो servers, अतिरिक्त मेहनत वाली सिर्फ़ एक copy भर हैं; एक ही क़ानूनी दायरे के अंदर दो servers भी मुश्किल से ही बेहतर हैं। हमारी jurisdiction guide बताती है कि ऐसा दूसरा जुरिस्डिक्शन कैसे चुनें जो पहले के जोखिम को ही न दोहराए।
असल में यह सस्ता पड़ता है। एक backup target को cores की ज़रूरत नहीं, और network की भी मुश्किल से ज़रूरत पड़ती है — उसे बस disk और एक पता चाहिए। सबसे छोटा VPS tier, हमारे सात locations में से किसी अलग location में, एक सक्षम restic या Borg endpoint बन जाता है, और terabytes में नापे जाने वाले archives के लिए असली drives वाला dedicated box किसी भी object store से प्रति terabyte सस्ता पड़ता है। जहाँ data सचमुच बड़ा हो और कम ही पढ़ा जाता हो, वहाँ अर्थशास्त्र bare metal के पक्ष में काफ़ी झुक जाता है।
एक बात लोग production में तो सही करते हैं पर backup target पर ग़लत: उसके लिए भी उसी तरह भुगतान करें। अपने ही नाम के card से ख़रीदा गया दूसरा server, चुपचाप वही पहचान वापस जोड़ देता है जिसे हटाने में आपने पहले मेहनत की थी — और अब उस पर पहले server की पूरी copy भी मौजूद है। अगर production box का भुगतान Monero में हुआ है, तो backup box को भी वही बर्ताव मिलना चाहिए।
तीसरी copy वही है जिसे ज़्यादातर लोग छोड़ देते हैं, और यही इकलौती है जो हर दूर की घटना से एक साथ अछूती रहती है: एक disk जिसे आप ख़ुद अपने हाथ में रखें, कभी-कभार update करें, और offline रखें। ज़्यादातर लोगों के लिए महीने में एक बार काफ़ी है। इसमें बस एक कॉफ़ी जितना ध्यान लगता है, और यही वह copy है जो बाक़ी दोनों के साझा हालात में भी बची रहती है।
Push, pull, और वह ग़लती जो एक बुरी रात में दोनों copies खा जाती है
यह है वह ढाँचा जो लगभग हर कोई सबसे पहले बनाता है। production server पर हर रात एक job चलती है, जिसके पास backup target की एक key या token होता है, वह जुड़ती है, और data push कर देती है। यह काम करता है, सीधा है, पर इसमें एक खूबी ऐसी है जो server की ज़िंदगी के सबसे बुरे दिन ही दिखाई देती है: जिसका control production box पर है, उसी का control backups पर भी है।
यह कोई फ़र्ज़ी बात नहीं। अपनी हरकत का ऐलान करने से पहले पीड़ित के backups मिटा देना या encrypt कर देना, इसे commercially करने वालों के लिए आम तरीक़ा है — credentials किसी cron job या environment file में पड़े होते हैं, और उन्हें ढूँढने में बमुश्किल एक मिनट लगता है। ऐसी copy जिसे आपका हमलावर मिटा सकता है, दूसरी copy है ही नहीं। वह बस पहली का देरी वाला mirror है।
इसके दो साफ़-सुथरे इलाज हैं, और ये आपके पहले से किए हुए बुनियादी hardening के साथ अच्छे से जुड़ते हैं।
- Append-only targets। दोनों बड़े tools एक ऐसा mode देते हैं जिसमें client data जोड़ तो सकता है, हटा नहीं सकता। Borg यह target पर SSH key को
borg serve --append-onlyसे बाँधकर करता है; restic यह--append-onlyसे शुरू किए गए REST server के ज़रिए करता है। production server हर रात लिखता है और ढाँचागत रूप से history मिटाने में असमर्थ रहता है। पुराने snapshots की छँटाई फिर target पर होती है, ऐसे session में जिसे production box शुरू ही नहीं कर सकता। - Push की जगह Pull। दिशा पलट दें: backup host production से जुड़ता है, पढ़ता है, और संभालकर रखता है। production के पास target के लिए कोई credential होता ही नहीं, तो चुराने को कुछ बचता नहीं। production वाली तरफ़ इस्तेमाल होने वाली key को
restrictऔर एक ज़बरनcommand=से सीमित करें ताकि चुराई गई backup key किसी shell में न बदल सके।
Pull ज़्यादा मज़बूत तरीक़ा है और चलाने में थोड़ा ज़्यादा काम माँगता है; अगर आप पहले से Borg या restic इस्तेमाल कर रहे हैं तो append-only लगभग मुफ़्त पड़ता है। दोनों में से कोई भी "हमलावर ने मेरे backups मिटा दिए" को नतीजे से घटाकर सिर्फ़ एक कोशिश बना देता है। अगर इस guide से बस एक चीज़ लेनी हो, तो यही हिस्सा लें।
पहले source पर ही encrypt करें, फिर तय करें key किसके पास रहेगी
दोनों गंभीर tools जिस machine का backup लिया जा रहा है उसी पर, network पार करने से पहले, data encrypt कर देते हैं। target ऐसे blobs रखता है जिन्हें वह पढ़ ही नहीं सकता — और यही वह चीज़ है जो cross-provider copy को सुरक्षित बनाती है। आपके दूसरे host का भरोसेमंद या दोस्ताना होना ज़रूरी नहीं; बस उस तक पहुँचा जा सके और उसके पास disk हो, इतना काफ़ी है। यही एक खूबी "एक ऐसा देश जिसके बारे में मुझे कुछ पता नहीं" वाले server को जोखिम से बदलकर infrastructure बना देती है।
यह server की अपनी disk को encrypt करने से अलग तरीक़ा है, और दोनों अलग-अलग सवालों के जवाब देते हैं — VPS पर full-disk encryption पर हमारी guide इस बात में जाती है कि machine के चलते रहने के दौरान disk encryption क्या बचाता है और क्या नहीं। backup encryption इन दोनों में आसान भी है और ज़्यादा क़ीमती भी, क्योंकि इसका threat model ईमानदार है: data आराम की हालत में है, ऐसे hardware पर जिस पर आपका control नहीं, और key वहाँ कभी जाती ही नहीं।
इससे पूरा जोखिम key की हिफ़ाज़त पर आ टिकता है। passphrase अब पूरी तरह खोने का इकलौता बिंदु है, और यह लोगों की सोच से भी बुरा बिंदु है, क्योंकि इसे खोना ख़ामोशी से होता है — कुछ भी टूटता नहीं, backups चलते रहते हैं, और आपको इसका पता ठीक उसी पल चलता है जब आपको इनकी ज़रूरत होती है। तीन आदतें इसे ठीक करती हैं:
- passphrase को server पर सिर्फ़ ऐसी file के रूप में रखें जिसे सिर्फ़ root पढ़ सके, और उसे
--password-fileके ज़रिए इस्तेमाल करें, ताकि वह कभी किसी process list या shell history में न दिखे। - इंसान के पढ़ने लायक एक copy इसमें शामिल हर machine से बाहर रखें। दराज़ में रखा काग़ज़ सचमुच उस password manager से बेहतर है जो किसी ऐसे account से sync होता है जिसकी पहुँच भी आप खो सकते हैं।
- repository में एक दूसरी key जोड़ें —
restic key add, या export की गई Borg key — ताकि एक भूला हुआ passphrase बस एक झंझट बने, archive का अंत नहीं।
तीनों के पीछे का नियम यही है: अगर key की इकलौती copy उसी machine पर रहती है जिसकी जगह यह backup लेने के लिए है, तो आपके पास backup है ही नहीं। आपके पास बस encrypted blocks का एक ढेर है, और उनके बारे में एक कहानी।
एक ही table में, tool कैसे चुनें
tool का चुनाव connection की दिशा और आपकी key की हालत जितना मायने नहीं रखता, इसीलिए यह पहले नहीं छठे नंबर पर आया है। फिर भी, फ़र्क़ असली हैं, और काम के लिए ग़लत ढाँचा चुनना बाद में मेहनत बढ़ा देता है।
| Tool | निकलने से पहले encrypt करता है | Deduplicate करता है | Append-only target | कहाँ फ़िट बैठता है |
|---|---|---|---|---|
| restic | हाँ, पूरी repository | हाँ | हाँ, अपने REST server के ज़रिए | डिफ़ॉल्ट चुनाव। SFTP, object storage और अपना server बोलता है, इसलिए target लगभग कुछ भी हो सकता है |
| BorgBackup | हाँ, पूरी repository | हाँ, समूह में सबसे बेहतर | हाँ, SSH पर native रूप से | SSH से पहुँचा जाने वाला एक Linux target। जब data बड़ा और दोहराव वाला हो तो बेजोड़ |
| rotations के साथ rsync | नहीं — target सब कुछ देख सकता है | आंशिक, hardlinks के ज़रिए | नहीं | पूरी तरह आपके control वाली machine पर mirror करना, जब privacy से ज़्यादा तुरंत आंशिक restore मायने रखे |
| rclone | सिर्फ़ rclone crypt के साथ | नहीं | storage provider पर निर्भर | पहले से मौजूद किसी archive को object storage में, या एक provider से दूसरे में ले जाना |
| ZFS replication | सिर्फ़ encrypted dataset के साथ | हाँ, block स्तर पर | snapshot permissions के ज़रिए | दो ZFS machines के बीच replicate करना। बेहद तेज़, दोनों सिरों पर बेहद सख़्त |
| age या GPG के साथ tar | हाँ, अगर आप archive को encrypt करें | नहीं | लागू नहीं | छोटे, कभी-कभार, हमेशा रखे जाने वाले archives जहाँ सादगी दक्षता पर भारी पड़े |
अकेले server के लिए, दूसरे VPS पर restic सही नतीजे तक पहुँचने का सबसे छोटा रास्ता है। किसी seedbox, media archive या मिलती-जुलती बड़ी files के ढेर के लिए, Borg का deduplication ही भरी हुई disk और आरामदायक disk के बीच का फ़र्क़ है — seedbox guide इस तरह के काम के storage पहलू को विस्तार से बताती है।
जो चल रहा है वह file नहीं है
दुनिया का सबसे आम ख़राब backup, एक live database की सीधी file copy होता है। यह बिना किसी error के पूरा होता है, सही वज़न का लगता है, और restore होकर ऐसे table में बदल जाता है जिसे engine खोलने से मना कर देता है। copy गुज़रते वक़्त database बीच-लेखन में था; जो आपने बचाया वह पलटे जा रहे पन्ने की एक तस्वीर भर है।
इससे निकलने के तीन तरीक़े हैं, मेहनत के हिसाब से बढ़ते क्रम में। इसे dump करें: mysqldump --single-transaction बिना writers को lock किए एक सुसंगत InnoDB dump देता है, और PostgreSQL के लिए pg_dump भी वही करता है। इसे snapshot करें: filesystem को freeze करें या एक LVM या ZFS snapshot लें, snapshot से copy लें, फिर उसे छोड़ दें — बहुत बड़े data sets के लिए, जिन्हें रोज़ रात dump करना संभव नहीं, यही तरीक़ा है। या इसे रोक दें: किसी छोटी service के लिए, सुबह 04:00 बजे दो मिनट का downtime एक पूरी तरह भरोसेमंद consistency रणनीति है, और यही इकलौती है जिसमें कोई edge case नहीं बचता।
यही तर्क database से आगे भी लागू होता है। container की writable layer डिस्पोज़ेबल है, पर उसके volumes नहीं, और न ही उनके साथ रखी docker compose file और environment — ऐसा backup जो data तो लौटा दे पर definition नहीं, आपको पूरा stack याददाश्त से फिर बनाने पर मजबूर कर देता है। Message queues, persistence चालू किए हुए Redis, और किसी MTA द्वारा लिखा जा रहा mail spool — इन सबको वही बर्ताव चाहिए: रोकें, snapshot लें, या dump करें, पर कभी सीधी copy लेकर उम्मीद न लगाएँ।
क्या backup करें, और वे हिस्से जो हर कोई भूल जाता है
ज़्यादातर लोग साफ़ दिखने वाला payload — database और application directory — backup करते हैं, और बाक़ी सब दबाव में हाथ से फिर से बनाते हैं। घंटे यहीं ख़र्च होते हैं। जो backup सही data के ढेर की बजाय एक चलती हुई system वापस दे, उसमें यह उबाऊ परत भी शामिल होनी चाहिए:
- पूरा
/etc, साथ ही आपके लिखे systemd units और timers, और उससे बाहर रहने वाले कोई भी crontabs। - TLS certificates और उनकी private keys, या कम से कम ACME account key, ताकि certificates शून्य से शुरू होने की बजाय renew हो सकें।
- Firewall नियम और package list, जो साथ मिलकर machine का ढाँचा किसी भी याददाश्त से तेज़ फिर खड़ा कर देते हैं।
- Application secrets और environment files — वे जो जान-बूझकर आपकी code repository से बाहर रखी गई हैं, और इसलिए कहीं और मौजूद ही नहीं।
- text के रूप में export किए गए DNS records, जिनमें reverse-DNS और PTR entries भी शामिल हैं, जो provider के पास रहती हैं, server पर नहीं।
कुछ keys data नहीं हैं — वे पहचान हैं। किसी Tor onion service की private key ही वह पता है: इसे खो दें तो साइट चाहे बाक़ी सब restore हो जाए, वही .onion नाम लेकर वापस नहीं आ सकती। WireGuard server key खोने का मतलब है आपके दिए हर client configuration को दोबारा जारी करना। mail server की DKIM key खोने का मतलब है एक नया selector और deliverability पर एक नई शुरुआत। किसी Lightning node का seed और channel state, files नहीं बल्कि funds जैसा मामला हो सकता है — node hosting guide इसे साफ़ शब्दों में कहती है। इन्हें अलग से copy करें, offline रखें, और इन्हें उस data से भी ज़्यादा क़ीमती मानें जिसकी वे रक्षा करती हैं।
जिस restore को आपने आज़माया नहीं, वह बस एक अफ़वाह है
backup software अपने बारे में रिपोर्ट देता है, और वह ग़लत चीज़ के बारे में ईमानदार रिपोर्ट देता है। "Snapshot completed" का मतलब बस इतना है कि repository में data लिख दिया गया। यह कुछ नहीं बताता कि क्या उस repository को किसी और machine पर, किसी ऐसे इंसान द्वारा पढ़ा जा सकता है जिसे ग्यारह महीने पहले की गई अपनी configuration याद ही नहीं।
सस्ती integrity जाँच से शुरू करें — किसी schedule पर restic check --read-data-subset=5% या borg check --verify-data — और यह समझें कि ये archive को परखती हैं, आपकी इस्तेमाल करने की क़ाबिलियत को नहीं। असली अभ्यास अलग है और एक दोपहर लेता है, बस एक बार। किसी ऐसे location में घंटे के हिसाब से एक नया server लें जिसे आप वैसे इस्तेमाल नहीं करते। सिर्फ़ repository का पता, passphrase, और अपने नोट्स के सहारे उस पर restore करें। service को चालू करें। पूरी प्रक्रिया का समय नापें। फिर machine मिटा दें। कुल ख़र्च: कुछ ही dollars, और यही इकलौती कवायद है जो कोई भरोसेमंद संख्या देती है।
यह जो भरोसे से उजागर करता है वह कभी data नहीं होता। यह होता है वह package जिसे किसी ने लिखकर नहीं रखा, वह config जो backup किए गए paths से बाहर रहती थी, वह passphrase जो सिर्फ़ उस server की shell history में मौजूद थी जिसे आप अभी बदलने की कोशिश कर रहे हैं, और वह tool version जो आपकी repository का format पढ़ पाता है। इनमें से हर एक को पहले से ठीक करना आसान है, और किसी outage के बीच खोजना बेहद तकलीफ़देह।
यह अभ्यास जो दो संख्याएँ देता है उन्हें लिख लें: restore में कितना समय लगा, और schedule कितना काम खो सकता है। यही backup policy है। बाक़ी ऊपर लिखा सब कुछ बस इन्हीं की सेवा में उठाया गया implementation detail है।
इसे automate करें ताकि यह चलता रहे
job को cron की बजाय एक systemd timer से चलाएँ। इससे आपको logs एक ही जगह मिलते हैं, आख़िरी run का असली रिकॉर्ड मिलता है, और एक ऐसा schedule मिलता है जो reboot के बाद भी बचा रहता है — यह सब cron बिना अतिरिक्त मेहनत के नहीं देता। passphrase को unit file से बाहर रखें, क्योंकि shell access वाला कोई भी इंसान उसे सीधे systemctl cat से पढ़ सकता है।
फिर उस failure mode को ठीक करें जो लोगों को असल में पकड़ता है — यह कोई error नहीं, ख़ामोशी है। छह हफ़्ते पहले चलना बंद कर चुका backup बिल्कुल वैसा ही दिखता है जैसा सही चला हुआ backup, क्योंकि दोनों कोई output नहीं देते। अनुपस्थिति पर alert करें, विफलता पर नहीं। job को कामयाबी पर किसी monitor को ping करने दें, और monitor को शिकायत करने दें जब ping न पहुँचे — और उस monitor को उस server के अलावा कहीं भी रखें जिसे वह देखता है, क्योंकि जो box बंद पड़ा है वह यह रिपोर्ट नहीं कर सकता कि वह बंद है।
Retention डिफ़ॉल्ट पर नहीं, जान-बूझकर तय करें। --keep-daily 7 --keep-weekly 4 --keep-monthly 6 जैसा कुछ, बिना हमेशा के लिए बढ़ते रहे, आज रात दिखने वाली ग़लतियों और बसंत में दिखने वाले corruption दोनों को समेट लेता है। अगर आपने append-only अपनाया है तो छँटाई target की तरफ़ चलाएँ, आख़िर append-only अपनाने का यही मक़सद है। हमारे network पर transfer की मात्रा शायद ही कभी रुकावट बनती है — हर plan पर bandwidth unmetered है — इसलिए schedule किसी quota के लिए नहीं, स्थिरता के लिए तय करें, और उसका समय अपने ख़ामोश घंटों से मिलाकर देखें। इससे जुड़ी बाक़ी आदतें server OpSec guide में बताई गई हैं।
छोटी-सी बात
अगर इस page से बस इतना ही लें, तो ये छह काम करें, तक़रीबन इसी क्रम में:
- एक copy दूसरे provider के पास, दूसरे jurisdiction में रखें, और उसका भुगतान पहले जितना ही private रखें।
- उस copy को append-only बनाएँ, या उसे target से pull करें, ताकि कोई compromise हुआ server उसे मिटा न सके।
- tool को source पर ही encrypt करने दें, और key को दोनों जुड़ी हुई machines से दूर रखें।
- databases dump करें और जो कुछ चल रहा है उसे रोकें या snapshot करें; live state की कभी सीधी copy न लें।
- पहचान वाली keys — onion, WireGuard, DKIM, node seeds — अलग से backup करें, क्योंकि इन्हें दोबारा बनाया नहीं जा सकता।
- एक बार किसी उपयोग-के-बाद-फेंक देने वाले server पर restore करके देखें, समय नापें, और जो कुछ छूटा हो उसे लिख लें।
इसमें से कुछ भी असाधारण नहीं है, और न ही इसमें कोई पूरा weekend लगता है। यह बस एक दोपहर की तैयारी और एक अभ्यास है, उस तरह के नुकसान के ख़िलाफ़ जो पूरे project ख़त्म कर देता है। ऐसे platform पर जो जान-बूझकर आपके बारे में कुछ भी नहीं रखता, वहाँ सिर्फ़ वही copy मौजूद रहती है जो आपने ख़ुद बनाई हो — यही इस पूरे इंतज़ाम की क़ीमत है, और एक वाजिब क़ीमत भी। अपने पहले वाले से अलग किसी jurisdiction में दूसरा server शुरू करें, और आज रात के backup को उतरने के लिए कोई जगह दें।