अपना बैकअप सिस्टम बनाना – भाग 1: स्क्रिप्ट्स से पहले की रणनीति

• बैकअप के महत्व को अक्सर कम करके आंका जाता है
• कई लोग cloud पर निर्भरता को लेकर निश्चिंत रहते हैं और डेटा सुरक्षा की जिम्मेदारी को नहीं समझते
• बैकअप योजना बनाए बिना सिर्फ कॉपी पर निर्भर रहना बड़ा जोखिम पैदा करता है
• पूरे डिस्क या अलग-अलग फ़ाइलों के बैकअप तरीकों के अपने-अपने फायदे और नुकसान हैं
• भरोसेमंद बैकअप के लिए snapshot का उपयोग और external storage सुनिश्चित करना मुख्य तत्व हैं

---

बैकअप का महत्व और वास्तविकता

• बैकअप ऐसा क्षेत्र है जिसे बहुत से लोग गंभीरता से नहीं लेते
• गलत तरीकों या अवधारणात्मक भूलों (जैसे: RAID बैकअप नहीं है) की वजह से असंख्य डेटा खो जाता है
• डेटा एक महत्वपूर्ण संपत्ति है जिसे अलग-अलग तरीकों से सुरक्षित रखना ही चाहिए

क्लाउड और बैकअप को लेकर गलतफहमियाँ

• कई बार लोग सारा डेटा cloud पर छोड़ देते हैं, लेकिन यह नहीं पूछते कि वास्तव में डेटा की सुरक्षा कैसे हो रही है
• बड़े cloud provider भी shared responsibility model अपनाते हैं
  • वे infrastructure की security देते हैं, लेकिन डेटा सुरक्षा की जिम्मेदारी उपयोगकर्ता की होती है
• cloud, private server, Kubernetes जैसे environments में भी बैकअप की कमी का जोखिम अक्सर बना रहता है

लेखक का डेटा रिकवरी अनुभव

• डेटा सेंटर में आग, सर्वर रूम में पानी भरना, भूकंप, ransomware, malicious attack, admin की गलती जैसी कई डेटा-हानि स्थितियों का अनुभव हुआ है
• इंटरनेट से जुड़े सर्वर (e-commerce, mail आदि) में data integrity और service continuity दोनों महत्वपूर्ण हैं
• बैकअप सिर्फ कॉपी नहीं है। खासकर चल रहे database files को कॉपी करना, recovery असंभव होने की संभावना बढ़ा देता है

बैकअप रणनीति बनाने के लिए ज़रूरी सवाल

• "आप कितना जोखिम उठाने को तैयार हैं?", "कौन-सा डेटा सुरक्षित रखना है?", "डेटा खोने पर कितना downtime स्वीकार्य है?", "कितना storage space उपलब्ध है?"
• बैकअप को उसी मशीन पर रखना, मशीन फेल होने पर बेकार हो जाता है। external storage में बैकअप रखना ज़्यादा सुरक्षित है
• network bandwidth, recovery speed, storage space जैसे व्यावहारिक पहलुओं को भी ध्यान में रखना चाहिए

पूरे डिस्क बनाम फ़ाइल-आधारित बैकअप

पूरे डिस्क का बैकअप

• फायदे
  • पूर्ण पुनर्स्थापन संभव। सिस्टम को पिछली स्थिति में तेज़ी से वापस लाया जा सकता है
  • virtualization systems के साथ उपयोगी। Proxmox आदि ऐसे full backup को आसानी से support करते हैं
  • कुछ solutions पूरे बैकअप से individual file recovery भी support करते हैं
• नुकसान
  • physical server के मामले में downtime की ज़रूरत होती है
  • ज़्यादा space लगता है, और अनावश्यक डेटा भी स्टोर हो जाता है
  • filesystem की विशेषताओं के अनुसार धीमापन या compatibility समस्या हो सकती है

अलग-अलग फ़ाइलों का बैकअप

• फायदे
  • system utilities (tar, cp, rsync आदि) से किया जा सकता है
  • सिर्फ बदलावों का बैकअप लेकर space और transfer कम किया जा सकता है
  • individual recovery, migration, compression और deduplication जैसी flexibility मिलती है
  • सिस्टम रोके बिना संचालन संभव है
• नुकसान
  • साधारण कॉपी में काफी storage space लग सकता है
  • snapshot के बिना चल रहे filesystem का बैकअप लेने पर असंगति और त्रुटियाँ हो सकती हैं

snapshot का उपयोग करके बैकअप

• जब बैकअप लक्ष्य एक चल रहा filesystem हो, तो बैकअप के "शुरू" और "खत्म" होने के बीच डेटा बदल सकता है, जिससे data consistency टूट सकती है
• MySQL, browser history जैसी खुली हुई databases में सिर्फ फ़ाइल कॉपी से recovery संभव नहीं होती
• consistent backup सुनिश्चित करने के लिए पहले filesystem की snapshot सुविधा का उपयोग करना चाहिए
• प्रमुख तरीके
  • native filesystem snapshot (BTRFS, ZFS support करने वाले सिस्टम)
  • LVM snapshot: space की बर्बादी और snapshot delete करते समय सिस्टम रुकने की संभावना
  • DattoBD: कभी-कभी stability issue आते हैं, लेकिन UrBackup आदि के साथ मिलाकर उपयोग किया जा सकता है

बैकअप तरीका: Push बनाम Pull

• Push: बैकअप लक्ष्य सर्वर से कनेक्ट होकर डेटा भेजता है
• Pull: केंद्रीय बैकअप सर्वर हर सर्वर से कनेक्ट होकर बैकअप करता है
• सुरक्षा की दृष्टि से बैकअप सर्वर पर बाहरी access बंद रखकर, ज़रूरत पड़ने पर ही clients तक पहुँचने वाला Pull तरीका अधिक सुरक्षित है
  • intrusion या ransomware की स्थिति में बैकअप डेटा मिटने से बचाने के लिए, बैकअप सर्वर के अपने snapshot भी अलग से लंबे समय तक सुरक्षित रखे जाते हैं

सुझाए गए बैकअप सिस्टम की मुख्य विशेषताएँ

• तुरंत recovery और तेज़ processing
• external storage में संग्रहित (हालाँकि local snapshot तुरंत rollback के लिए बनाए रखें)
• Google Drive, Dropbox जैसे commercial cloud का उपयोग न करने की सलाह। डेटा अपने पास होना चाहिए
• compression, deduplication जैसी प्रभावी space management
• संचालन के लिए ज़रूरी अतिरिक्त components न्यूनतम होने चाहिए

आगे की श्रृंखला की योजना

• अलग-अलग बैकअप scenarios, वास्तव में उपयोग किए जा रहे सर्वर, मुख्य settings, और विभिन्न software व technologies का परिचय दिया जाएगा
• अगली कड़ी में FreeBSD आधारित बैकअप सर्वर बनाने का तरीका बताया जाएगा

[GN⁺]

Hacker News राय

• जिन मशीनों में बैकअप अनिवार्य रूप से “push” तरीके से करना पड़ता है, उनमें यह सीमित करना ज़रूरी है कि वे केवल अपने ही स्पेस तक पहुंच सकें। इससे भी अधिक महत्वपूर्ण यह है कि बैकअप सर्वर सुरक्षा के लिए अपने filesystem snapshots को कुछ समय तक बनाए रखे। तब, अगर सबसे बुरा हाल यह हो कि workload corrupt हो जाए और बैकअप सर्वर तक पहुंचकर ransomware के लिए बैकअप मिटा दिए जाएं, तब भी सर्वर पर snapshots बचे रहेंगे। मेरा पसंदीदा तरीका यह है कि client सिर्फ नए backups लिख सके और deletion बिल्कुल न कर सके; deletion अलग प्रक्रिया से हो, जैसे manual या cron के जरिए। यह rsync/ssh में .ssh/authorized_keys की allowed command सुविधा से लागू किया जा सकता है.

  • मैं दोनों तरीकों का उपयोग करता हूँ। बैकअप को दो जगह रखना तो चाहिए ही, लेकिन यह dual-backup संरचना मैं शुरू से चाहता था। बैकअप sources एक intermediate location पर push करते हैं, और primary backup storage वहाँ से pull करता है। Intermediate location की capacity छोटी है, इसलिए वह snapshots रखता है, लेकिन primary storage और sources एक-दूसरे को authenticate ही नहीं करते। यानी दोनों केवल intermediate location को authenticate कर सकते हैं, reverse authentication भी नहीं है। इन 3 जगहों में से एक या दो hack हो जाएँ, तब भी बाकी सुरक्षित रहने की संभावना अधिक है। Certificates के backups को मैं पूरी तरह अलग रखता हूँ ताकि वे कभी internet-connected servers पर पूरी तरह store न हों। सच में महत्वपूर्ण data के लिए अतिरिक्त उपाय के रूप में offline backup भी रखता हूँ। संरचना अलग होने से actual backup verification झंझटभरा हो जाता है, लेकिन backup storage समय-समय पर checksum verify करके उसका परिणाम intermediate host को भेजता है, और source host पर बने hashes से तुलना कर corruption events पकड़ता है। इस तरह source से backup snapshots को सीधे नुकसान नहीं पहुँचाया जा सकता — एक तरह का “soft offline” backup है.

  • अलग container या backup-only user का उपयोग करना भी एक तरीका है। उदाहरण के लिए systemd-nspawn को lightweight chroot jail की तरह इस्तेमाल किया जा सकता है, और उसके अंदर rm चलने से ही रोका जा सकता है। बस pacman/pacstrap आदि से chroot बनाइए, और systemd-nspawn/machinectl से manage कीजिए। इस तरीके में सामान्य systemd की तरह access control, file path restrictions, memory/CPU limits, केवल कुछ IP ranges को access देना, boot conditions को बारीकी से नियंत्रित करना आदि कई तरह के controls मिलते हैं, इसलिए यह काफ़ी लचीला है। BTRFS subvolumes जैसी चीज़ें भी काम आती हैं, और ज़रूरत हो तो पूरे system को systemd-vmspawn से पूरी तरह isolate किया जा सकता है। importctl से replication automation भी बहुत आसान है.

  • मैं “ऐसा pull तरीका, जिसमें backup server के पास backup target server पर कोई अधिकार न हो,” को प्राथमिकता देता हूँ। Live server पर root access compromise हो जाए, तब भी backup system पर असर नहीं पड़ता.

  • मैं बैकअप के लिए rclone copy का उपयोग करता हूँ, और केवल ऐसी API key इस्तेमाल करता हूँ जिसके पास object deletion permission नहीं है। rclone sync जैसी sync करने वाली विधि चीज़ें मिटा सकती है, इसलिए यह ज़्यादा सुरक्षित है.

  • अच्छा होता अगर syncoid में भी ऐसा विकल्प होता जिसमें “client सिर्फ snapshots/backups कॉपी करे और deletion बैकअप सर्वर खुद manage करे।” अभी deletion permission देनी पड़ती है, जो खटकता है.

• हैरानी की बात है कि बहुत से लोग backups को गंभीरता से नहीं लेते। छोटे-बड़े, दोनों तरह की कंपनियों में यही हाल है। जिस 1 अरब यूरो वार्षिक revenue वाली कंपनी को मैं consult करता हूँ, उसके पास खुद का कोई backup नहीं था, और वह केवल data center provider की अनियमित disk copies पर निर्भर थी। उन्होंने कभी recovery test भी खुद नहीं किया। हाल ही में user mistake की वजह से production DB पूरी तरह उड़ गया, और सबसे नया backup 4 दिन पुराना निकला, इसलिए उस बीच के सभी transactions दोबारा reconstruct करने पड़े। लेकिन इतनी बड़ी घटना के बाद भी कोई shocked नहीं था; सब कुछ सामान्य की तरह चलता रहा.

  • शायद लोग मानते हैं कि जब तक यह business के लिए सचमुच घातक न हो, तब तक यह स्वीकार्य है.

  • Backup requirements को ज़रूरत से ज़्यादा जटिल बना देना भी एक आम समस्या है.

  • शायद यह legal issue की वजह से भी हो सकता है। मुकदमे या कानूनी retention obligations के कारण backup खुद एक risk factor बन सकता है.

  • यह SOC2-audited disaster recovery policies का side effect है। जिस कंपनी में मैं काम करता था, वहाँ हमने सभी teams की disaster recovery policies देखीं — सब SOC2 approved थीं — और निष्कर्ष यह निकला कि अगर सचमुच बड़ा incident हो जाए, तो कंपनी बंद करके घर चले जाना normal recovery से तेज़ होगा.

  • अगर production DB के पूरे 4 दिन का data loss सच में हुआ, तो क्या ग्राहक नाराज़ नहीं हुए? उस आकार की कंपनी में यह व्यवहारिक रूप से भारी नुकसान लगता है, इसलिए जानना चाहूँगा कि वास्तव में इसे कैसे संभाला गया.

• साझा करने के लिए धन्यवाद। 10 साल से backup/disaster recovery software बनाते हुए एक बात हमेशा सुनने को मिलती है: “मैं अपने दोस्त को खुद backup/disaster recovery solution बनाने की सलाह नहीं दूँगा।” BCDR बनाना आसान नहीं है; इसमें छूट जाने वाले जाल बहुत हैं। कुछ अहम बिंदु साझा करना चाहूँगा। Backup, “disaster recovery” नहीं है। असली incident होने पर minutes से लेकर कुछ घंटों के भीतर recovery हो जानी चाहिए, तभी business trust बना रहता है। Recovery Time Objective (RTO) और Recovery Point Objective (RPO) ही असली कुंजी हैं। सिर्फ rsync copy वाले file replication से point-in-time backup नहीं मिलता, क्योंकि filesystem लगातार बदलता रहता है। सही point-in-time backup के लिए “crash-consistent” या “application-consistent” backup चाहिए। दूसरे प्रकार में महत्वपूर्ण applications disk पर state flush करती हैं और backup के दौरान रुकती हैं। Microsoft VSS जैसी सुविधाएँ यही काम देती हैं। rsync copy या crash-consistent backups पर कभी अंधा भरोसा नहीं करना चाहिए। Storage पर Murphy's law हमेशा लागू होता है, इसलिए कई locations में backups होना — 3-2-1 strategy — अनिवार्य है। अपने अनुभव से कह सकता हूँ, हर तरह की disks fail होती हैं। NVMe SSD > SSD > HDD क्रम में टिकाऊपन बेहतर हो सकता है, पर कोई अपवाद नहीं। और भी बहुत कुछ लिखना था, लेकिन देर हो गई है, इसलिए यहीं तक.

  • 3-2-1 वाली उपमा पुरानी सोच है। आजकल data रखने की जगह लगभग असीमित है, इसलिए local snapshots, remote replication, और अलग-अलग तरीकों से दोहरा-तिहरा backup ज़्यादा महत्वपूर्ण है। मैं default snapshots के लिए zfs रखता हूँ, और अतिरिक्त रूप से Borg भी उपयोग करता हूँ; इस संयोजन के साथ लगभग किसी भी disaster के लिए पर्याप्त तैयारी हो जाती है.

  • वह कहावत मुझे Alice in Chains के एक concert में सुनी हुई मिलती-जुलती बात की याद दिलाती है। BCDR solutions कंपनियों के बीच भरोसे का प्रतीक हैं। ऐसे systems खरबों के स्तर के data की रक्षा करते हैं, और अगर आप CTO हैं तो company backups को open source approach पर नहीं छोड़ेंगे। Enterprise IT spending सामान्यतः assets की value और anti-vendor-lock-in रणनीति के हिसाब से धीरे-धीरे बढ़ती है। Professional अनुभव में ransomware prevention के लिए immutability और WORM backups सबसे महत्वपूर्ण हैं, और compliance न होने के कारण government IT में समस्या पैदा होने के कई मामले भी मैंने देखे हैं। BCDR vendors ransomware को sales point बनाते हैं, लेकिन सच्ची immutability का प्रमाण कई locations में data replication से मिलता है। वहीं 3-2-1 strategy अपनी असली ताकत दिखाती है। Backup principles पर और विचार सुनना चाहूँगा.

  • NAS उपयोग कर रहे हों, तो दोनों तरफ एक ही manufacturer और एक ही model की hard disks का उपयोग न करना बेहतर है.

  • “कई locations में backup ज़रूरी है (3-2-1)” — इससे मैं पूरी तरह सहमत हूँ। लेकिन अधिकांश व्यक्तियों के लिए “1” यानी offsite व्यवहारिक रूप से संभव नहीं होता। तब, backup service इस्तेमाल न करें तो खुद backup करने का कारण ही खत्म हो जाता है। मेरे आसपास कोई ऐसा नहीं जो मेरे शहर के बाहर 24x7 computer चलाकर और maintain करके दे सके.

  • “rsync copy या यहाँ तक कि crash-consistent backup पर भी कभी भरोसा नहीं करना चाहिए” — इससे आख़िरकार मैं इस निष्कर्ष पर पहुँचता हूँ कि चूँकि हर system/service को infra tools से दोबारा बनाया जा सकता है, इसलिए बस DB और file/object storage का सक्रिय backup लेना पर्याप्त है। VM का पूरा backup जटिल बनाना वास्तव में उतना अर्थपूर्ण नहीं है.

• लेख साफ-सुथरा है, लेकिन एक कमी है: वास्तव में अच्छे backup system में recovery speed और procedure स्पष्ट होने चाहिए। मैंने कई बार देखा है कि लोग इस भरोसे में रहते हैं कि backup ठीक चल रहा है, लेकिन recovery के समय पता चलता है कि सिर्फ कुछ हिस्सा ही बहाल हो रहा है, या इसमें कई दिन लग रहे हैं और भारी नुकसान हो जाता है। restic ऐसा tool है जो file-level deduplicated snapshot backups देता है, इसलिए जब ZFS जैसा snapshot filesystem न हो तो यह उपयोगी है। और “push” backup में ransomware backup भी मिटा सकता है, इसलिए “pull” तरीका सही है। अगर push करना ही हो, तो read-only media (जैसे Bluray) बेहतर है, या कम से कम auto-snapshot/ZFS जैसी point-in-time recovery उपलब्ध होनी चाहिए.

  • भले ही ransomware push backups तक पहुँचकर उन्हें मिटा सके, अगर server permissions ठीक से सीमित हों तो समस्या नहीं होती। Borg और Restic ssh के साथ append-only लागू कर सकते हैं, और local स्तर पर offline backup drives को अंतिम रक्षा-पंक्ति के रूप में rotate किया जाता है। वास्तविक तरीका यहाँ देखा जा सकता है.

  • क्या restic के append-only mode में अगर periodic pruning केवल server के अंदर से की जाए, तो pull mode का उपयोग किए बिना भी काम चल सकता है? मेरी जानकारी में ransomware protection के लिए यही restic की आधिकारिक सिफारिश है.

  • “Recovery speed” सचमुच requirements पर निर्भर करती है। अगर परिवार की तस्वीरें restore होने में 6 महीने लगें, तो भी मुझे ठीक लगेगा.

  • Read-only media के बजाय permissions-सीमित push server भी एक विकल्प है। उदाहरण के लिए ssh को केवल scp तक सीमित कर दें, chroot environment तक बाँध दें, और folders को daily rotation में रखें — तब ransomware भी पुराना data नहीं मिटा सकता। मेरी backup प्रक्रिया भी ऐसे ही chroot + scp-only ssh server से manage होती है, और साथ में read-only media भी उपयोग करता हूँ.

• मुझे अलग backup system की ज़रूरत नहीं लगती; बस इतना काफी होगा कि 4 सदस्यों वाले परिवार की 25 साल की photos — phones, cameras, downloads, scans आदि — को कुशलता से एक जगह इकट्ठा करने का कोई standard तरीका हो। अभी तक मुझे कोई संतोषजनक विधि नहीं मिली.

  • मैं NAS पर Immich चलाता हूँ, और media तथा Immich DB dump का रोज़ाना backup AWS S3 Deep Archive में करता हूँ। Immich, Google Photos जैसी पर्याप्त functionality देता है, और अगर desktop photos/scans को NAS में जोड़ दें तो Immich उन्हें अपने आप ingest कर लेता है। HN users के लिए यह setup कठिन नहीं है.

  • “25 साल की photos” सुनकर मज़ाक में पूछा गया कि क्या यह North American data unit है, और साथ ही कहा गया कि वास्तव में backup system तो चाहिए ही। मैं syncthing को gnu/linux/windows/android पर mesh की तरह चलाता हूँ, दो Debian VMs पर archives के नियमित snapshots लेता हूँ, और borgbackup से secondary backup करता हूँ। RPO 24 घंटे है, लेकिन चाहें तो और घटाया जा सकता है। हाँ, Apple devices में syncthing का background execution रुकता है, इसलिए यह setup वहाँ उपयुक्त नहीं है। मेरे मामले में photos 500GB हैं, और अन्य documents भी कई दर्जन से सैकड़ों GB तक हैं, लेकिन diff-based backup की वजह से यह काफ़ी efficient है.

  • Downloads और scans, अगर बहुत महत्वपूर्ण नहीं हैं, तो अंततः फेंकने योग्य data ही हैं। Phone/camera को Nextcloud से sync करें, और backups को केवल अपने home network के भीतर चलाएँ। उसके बाद NAS पर रोज़ backup और health checks करें। अंतिम चरण में किसी भरोसेमंद cloud backup या किसी दूसरे घर में रखी drive का उपयोग करें — तब secondary backup भी पूरा हो जाता है.

  • PhotoPrism या Immich जैसे self-hosted solutions photo deduplication, search और tagging के लिए उपयोगी हैं। Cloud backup के लिए Backblaze B2 + Cryptomator का संयोजन encrypted storage और DIY upload scripts के साथ उपयोग किया जा सकता है। लागत लगभग $1 प्रति TB प्रति माह है.

  • मैं syncthing का उपयोग करता हूँ। आधिकारिक रूप से Android support नहीं है, लेकिन fork version से यह अच्छी तरह काम करता है। अतिरिक्त रूप से photos backup के लिए ente.io या self-hosted Immich की सिफारिश करता हूँ। Documents को paperless ngx जैसी अलग व्यवस्था में रखना बेहतर है.

• Dirvish एक हल्का rsync wrapper है जिसे कम-से-कम एक बार ज़रूर आज़माना चाहिए। यह rotation, incremental backups, retention, pre/post-processing scripts जैसी शानदार सुविधाएँ देता है। 20 साल से अधिक समय में इसने मेरे data को कई बार बचाया है। लेख में उठाए गए बिंदुओं के साथ भी इसकी अच्छी संगति है। dirvish आधिकारिक साइट, rsync आधिकारिक साइट

  • Dirvish, rsync की तुलना में किस तरह आसान या बेहतर है, यह जानने की उत्सुकता है.

• मैंने काफ़ी आलसी तरीके से भी hardware failure और theft, दोनों समस्याओं का सामना किया है। संयोजन यह है: desktop के अंदर temporary storage, घर में external disk, और offsite external disk — सब Samsung T7 Shield। robocopy /MIR से रोज़ temporary या काम के बाद copy करता हूँ, हफ्ते में एक बार external पर backup लेता हूँ, और महीने में एक बार offsite external disks को बदलता हूँ.

  • External disks कम-से-कम अलग batch की होनी चाहिए, और बेहतर हो तो अलग models की। अगर वही model और वही lot हो, तो अक्सर दोनों के एक साथ fail होने की संभावना अधिक होती है — खासकर तब जब recovery के दौरान उन पर बहुत ज़्यादा load पड़े.

• समय अच्छा है, इसलिए मैं अपनी archlinux settings और backup strategy साझा कर रहा हूँ। config/backup automation scripts, borg automation layer भी सार्वजनिक हैं.

  • मैं python + borg से SAN के 51 block devices के snapshots, 71 file systems के backups, और S3 sync तक automate करता हूँ। Recovery को offsite पर वास्तव में test किया गया है, और VM boot तक बिना समस्या के सफल रहा। Automation अभी भी जटिल और अधूरी है, इसलिए recovery speed धीमी है, लेकिन यह बहुत सस्ते में बनाया गया है। Borg सचमुच शक्तिशाली है। ऐसी चीज़ कोई भी आज़मा सकता है, और नतीजतन यह बहुत किफायती है.

• मेरे पास जो मूल्यवान data है, वह 100MiB से कम है। इसलिए चुने हुए paths को tar + compression + encryption के साथ हफ्ते में दो बार backup करता हूँ, और कुछ महीनों तक rotation रखता हूँ। इन्हें घर के भीतर और बाहर दोनों जगह रखता हूँ, और लगभग कोई inspection या maintenance नहीं चाहिए। कुछ lines की sh script से यह आराम से automate हो जाता है.

  • अगर मैं कल अचानक मर जाऊँ, तो मुझे सोचना चाहिए कि कौन-सा data परिवार और आने वाली पीढ़ियों के लिए सचमुच restore करने लायक है। शायद लाखों files की ज़रूरत नहीं; कुछ मुख्य photos, videos और texts ही काफी हों.

  • इस टिप्पणी ने मुझे फिर सोचने पर मजबूर किया कि मेरे लिए वास्तव में मूल्यवान data क्या है। मेरी photos compress करने पर भी कम-से-कम कई GB की होंगी, contacts या कम महत्वपूर्ण चीज़ें छोटी हैं, और बाकी ज़्यादातर चीज़ें खो जाएँ तो चलेगा। Recovery keys को और सुरक्षित जगह रखना चाहिए, लेकिन दिलचस्प बात यह है कि सबसे महत्वपूर्ण accounts के लिए तो recovery keys हैं ही नहीं। सिर्फ photos ही लगभग 2TB हैं — hobby photographer होने का दुख.

• Backup consistency में सबसे कठिन बात यह है कि application data को service downtime के बिना consistent तरीके से backup करना लगभग असंभव है। Disk snapshots लेने पर भी उस क्षण किसी service के mid-write स्थिति में होने की संभावना रहती है, इसलिए restore के समय corrupt state मिलने का जोखिम बड़ा है। DB dumps इस समस्या को काफी हद तक कम करते हैं, लेकिन कई बार backup service के बाहर से लेना पड़ता है, इसलिए query के बीच में snapshot हो सकता है। अगर किसी के पास इस हिस्से पर कोई व्यावहारिक ज्ञान हो, तो सुनना चाहूँगा.

  • सामान्यतः DB इस मामले में काफी robust होते हैं, इसलिए किसी भी समय disk snapshot लेना backup के लिए पर्याप्त माना जा सकता है। चिंता केवल battery-less cache जैसी विशेष स्थितियों की होती है, लेकिन modern cloud environments आदि में ऐसी संरचनाएँ लगभग नहीं होतीं, इसलिए बड़ी समस्या नहीं है.

  • रणनीति इस बात पर भी निर्भर करती है कि DB के अलावा application state में और क्या capture करना है — जैसे cache भी backup करनी है या नहीं। pg_dump/mysqldump वास्तव में live DB snapshots को सुरक्षित तरीके से संभव बनाते हैं, लेकिन वे धीमे हो सकते हैं और dump size भी बड़ा हो सकता है। इस समस्या से बचने के लिए बड़े PostgreSQL DB पर backup-only read-only replica रखना, replication रोकना, backup चलाना, और फिर replication दोबारा शुरू करना — ऐसा तरीका भी मैंने उपयोग किया है.