बैकअप और रिकवरी प्लानिंग: अपनी फ़ाइलों की सुरक्षा करें

बैकअप और रिकवरी प्लान दो संख्यात्मक प्रश्नों का उत्तर देता है: RPO (आप कितना डेटा खोना afford कर सकते हैं, समय में मापा गया) और RTO (आप कितनी देर down रहना afford कर सकते हैं)। प्रत्येक workload के लिए वो परिभाषित करें, फिर पीछे की ओर engineer करें। 5-मिनट RPO वाले database को continuous WAL shipping चाहिए; 24-घंटे RPO वाली साप्ताहिक marketing report को एक nightly job चाहिए। 3-2-1 नियम के साथ जोड़ें — तीन copies, दो media types पर, एक offsite — और त्रैमासिक restores परीक्षण करें। अधिकांश "हमारे पास backups हैं" की कहानियाँ बुरी तरह समाप्त होती हैं क्योंकि किसी ने कभी restore का अभ्यास नहीं किया।

RPO और RTO: शुरुआती संख्याएं

RPO (Recovery Point Objective) = समय में अधिकतम स्वीकार्य डेटा हानि। RTO (Recovery Time Objective) = अधिकतम स्वीकार्य downtime।

Workload के अनुसार उदाहरण:

• e-commerce site के लिए production database: RPO 5 मिनट, RTO 1 घंटा
• Customer-facing फ़ाइल uploads: RPO 15 मिनट, RTO 2 घंटे
• Internal file server: RPO 24 घंटे, RTO 8 घंटे
• Email archive: RPO 24 घंटे, RTO 48 घंटे
• Marketing analytics: RPO 24 घंटे, RTO 72 घंटे

तंग RPO/RTO अधिक खर्च करती है। 5-मिनट RPO का मतलब continuous replication (महंगा infrastructure); 24-घंटे RPO का मतलब एक nightly job (सस्ता)। over-engineer न करें — हर workload को hot standby की आवश्यकता नहीं है।

3-2-1 नियम अभी भी काम करता है

डेटा की तीन copies, दो अलग storage types पर, एक offsite। 3-2-1 नियम cloud से पहले का है और अभी भी लागू है:

• Primary: production storage (S3, EBS, PostgreSQL disk)
• Secondary: अलग media या अलग region में backup (replication के साथ दूसरा S3 bucket, Glacier)
• Tertiary: offsite, आदर्शतः अलग vendor या air-gapped (Backblaze B2, on-prem tape, safe में physical disks)

Vendor-diversity बिंदु मायने रखता है। compromised root AWS account आपके सभी AWS backups delete कर सकता है। Backblaze, Wasabi, या on-prem में secondary उस scenario से बचती है। ₹42 करोड़ से कम राजस्व वाली कंपनियों के लिए, second-vendor copy शायद ₹4,200-16,700/महीने जोड़ती है और catastrophic tenant-wide मुद्दों के विरुद्ध बीमा करती है।

Full, Incremental, और Synthetic Full

तीन backup strategies:

• Full: हर बार सब कुछ copy करें। सरल, restore तेज़ (एक फ़ाइल), storage भारी।
• Incremental: केवल वही copy करें जो last backup के बाद बदला। Storage-efficient, restore के लिए full + सभी incrementals चाहिए।
• Synthetic full: Full + incrementals को एक new virtual full में server-side merge। किसी भी point से तेज़ restore।

आधुनिक backup tools (Veeam, Rubrik, prune के साथ restic, BorgBackup) हुड के नीचे synthetic fulls के साथ incremental-forever उपयोग करते हैं। Pattern: nightly incremental, weekly synthetic full, 30 daily + 12 monthly + 7 yearly copies retain करें (grandfather-father-son rotation)।

5% daily change rate के साथ 2 TB file server के लिए, incremental-forever एक वर्ष की retention के लिए लगभग 3-5 TB कुल store करता है — बनाम 700+ TB यदि आप full-nightly करते।

जाने से पहले Encryption

Backups को unencrypted यात्रा या बैठना नहीं चाहिए। AES-256-GCM के साथ Client-side encryption (restic, Borg, Duplicacy, Veeam, और अन्य में default) सुनिश्चित करता है कि backup host कभी plaintext न देखे।

Key management algorithm choice से अधिक मायने रखता है। backup के साथ उसी AWS account में stored key के साथ encrypted backup theater है — IAM access वाला attacker दोनों प्राप्त करता है। Keys store करें:

• अलग-account key के साथ AWS KMS (cross-account decryption)
• out-of-band environment में HashiCorp Vault
• root key के लिए hardware security module (YubiKey, HSM)
• वास्तव में critical keys के लिए printed और sealed paper copy

नियमित रूप से rotate करें (वार्षिक), हर उपयोग log करें, और production में rotation प्रभावी होने से पहले rotated key के साथ recovery परीक्षण करें।

Immutability: Ransomware का उत्तर

2025 में Ransomware attacks आमतौर पर पहले backups को target करते हैं — production data encrypt करो, फिर recovery रोकने के लिए backups delete या encrypt करो। Immutable backups इसे विफल करते हैं।

Implementations:

• S3 Object Lock (Compliance Mode): retention period के लिए root भी delete नहीं कर सकता
• Azure Blob immutable storage: समान, container level पर enforced
• Veeam Hardened Linux Repository: append-only, SSH-only, no delete API
• Vault में Physical tape: ultimate air gap

Business-critical data के लिए, retention period के लिए कम से कम एक backup copy immutable होनी चाहिए। Incremental लागत आमतौर पर शून्य है — आप इसे वैसे भी retain करने वाले थे। जब ransomware हिट करता है तो मूल्य पूर्ण है।

परीक्षण: न-वैकल्पिक भाग

जो backup आपने कभी restore नहीं किया वह backup नहीं है; वह उम्मीद है। प्राथमिकता से परीक्षण शेड्यूल:

• Tier 1 (mission-critical): त्रैमासिक full restore drill, मासिक random file restore
• Tier 2 (business-important): अर्ध-वार्षिक full restore drill, त्रैमासिक random file restore
• Tier 3 (standard): वार्षिक full restore drill, त्रैमासिक random file restore

परीक्षण में record करें:

1. Restore में कितना समय लगा (RTO से तुलना करें)
2. क्या data production state से match हुआ (किसी known point के विरुद्ध checksums)
3. क्या कोई permissions या configurations restore होने में विफल रहे
4. क्या टूटा और इसे कैसे ठीक किया

Parekshan छोड़ने वाली कंपनियाँ actual incidents के दौरान corrupted backups के बारे में सीखती हैं, जो किसी भी चीज़ सीखने का सबसे महंगा समय है।

Database Backups के लिए अलग योजना चाहिए

Files और databases अलग तरह से backup होते हैं। mid-transaction copied .pgdata directory corrupt होती है। Native tools उपयोग करें:

• PostgreSQL: PITR के लिए pg_basebackup + WAL archiving, logical के लिए pg_dump
• MySQL: hot physical के लिए Percona XtraBackup, logical के लिए mysqldump
• MongoDB: mongodump, delayed secondaries के साथ replica sets
• Microsoft SQL Server: BACKUP DATABASE के साथ native backup, PITR के लिए log shipping

5-मिनट RPO के साथ 500 GB PostgreSQL database के लिए, nightly base backups + S3 में continuous WAL archiving पिछले 30 दिनों के किसी भी second में point-in-time recovery देता है। Restore time: base backup pull करें (30 मिनट), target time तक WAL replay करें (5-30 मिनट)। Tight RTO का मतलब promote करने के लिए तैयार warm replica।

Application-Consistent Snapshots

Filesystem snapshots (ZFS, Btrfs, AWS EBS, Azure managed disks, GCP persistent disk) block level पर एक point in time freeze करते हैं। Databases के लिए, application quiesce के साथ मिलाएं:

1. pg_start_backup('label') (PostgreSQL) या FLUSH TABLES WITH READ LOCK (MySQL)
2. Snapshot लें
3. pg_stop_backup() या unlock

Snapshot application-consistent है — crash recovery के बिना restore के लिए उपयोगी। AWS Backup, Azure Backup, और Google Cloud Backup सामान्य databases के लिए इस pattern को automate करते हैं।

Third Parties को Backup Archives वितरित करना

जब backups बाहरी पक्षों को जाने की आवश्यकता हो — auditors, regulators, successor trustees — तो transfer में ही ध्यान देने की आवश्यकता है। FTP पुराना है; email attachments size limits से टकराते हैं; USB drives सौंपना धीमा है।

End-to-end encrypted file transfer ad-hoc backup distribution को साफ-साफ संभालता है। HexaTransfer AES-256-GCM client-side encryption और एक one-time link के साथ 10 GB तक फ़ाइलें move करता है। किसी auditor को आपके S3 buckets तक पहुँच दिए बिना database snapshot भेजने के लिए अच्छा है।

Documentation Backup का हिस्सा है

दुनिया का सबसे अच्छा backup बेकार है यदि जो इसे restore कर सकता है वह छुट्टी पर है और किसी अन्य को पता नहीं। Document करें:

• क्या backup हुआ और क्या नहीं (explicit exclusions)
• प्रति workload schedule और retention
• Key management और access
• Step-by-step commands के साथ Restore runbooks
• Contact list (vendor support, on-call)
• परीक्षण परिणाम और तिथियाँ

एक copy print करें। emergency keys के साथ physical safe में एक copy store करें। यदि आपका backup runbook केवल उसी infrastructure से serve होने वाले Confluence page पर रहता है जो अभी down हो गया है, तो आपको समस्या है। कागज़ तब भी काम करता है जब कुछ और नहीं करता।

RPO/RTO परिभाषित करें, immutability के साथ 3-2-1 implement करें, client-side encrypt करें, त्रैमासिक परीक्षण करें, जुनूनी रूप से document करें। Backup सफलता 10% technology और 90% अनुशासन है।

hexatransfer.com पर आज़माएं — मुफ़्त, कोई अकाउंट नहीं, अधिकतम 10 GB।