3-2-1-1-0 में गलती से चौथी copy न गिनें। Protected versions, keys, actual RPO/RTO और सुरक्षित business restart test करें।
लेखक
Anichur Rahaman
Backup job green है। मालिक पूछती है: “क्या इससे दूसरे server पर दुकान चला सकते हैं?” Planned drill में database खुलता है, पर invoices की files और decryption key नहीं मिलती। यह काल्पनिक scene है, customer incident नहीं।
Job ने कुछ copy किया; कारोबार recover नहीं हुआ। Ransomware में gap जरूरी है क्योंकि attacker reachable backups, identities और recovery controls भी compromise कर सकता है। Backup stolen data वापस नहीं करता, न intruder हटाता है।
उपयोगी plan के अंत में validated service और recovery decision का owner होता है। 3-2-1-1-0 योजना व्यवस्थित करता है, guarantee नहीं।
3-2-1-1-0 guideline का अर्थ तीन copies, दो media, एक off-site, एक offline/air-gapped/immutable और recovery verification में zero errors है। Production copy सामान्यतः तीन में गिनी जाती है।
उदाहरण: live system, अलग local backup और off-site protected backup। तीसरा off-site और protected दोनों हो सकता है; rule अपने-आप चौथी retained copy नहीं माँगता। Temporary restore target testing है, retained history का विकल्प नहीं।
एक disk के अलग folders independent copies नहीं। Shared admin login, identity provider, location, encryption key, billing और retention common failure बन सकते हैं। Replication/RAID availability बढ़ाकर भी deletion/corruption दोहरा सकते हैं; पूरी backup strategy नहीं।
Offline device controlled runs के बीच वास्तव में disconnected/protected रहे। Connected pull-backup server में separation है, पर स्वतः air-gapped या immune नहीं। Label के बजाय boundaries test करें।
AWS Object Lock documentation specific object versions बचाता है; new versions/delete markers रह सकते हैं। Compliance और governance override अलग हैं। Visible latest object अकेली recovery copy नहीं।
AWS encryption-key loss भी बताता है: key खोने/deletion से locked objects unreadable हो सकते हैं। Immutability retention property बचाता है, हर recovery dependency नहीं।
Provider से version protection, retention shortening, privileged override, account closure और non-current restore पूछें। Irreversible retention से पहले disposable objects पर test करें। S3-compatible समान lock semantics का प्रमाण नहीं।
Routine writer, protected-storage admin और recovery reader अलग रखें। Verification/multipart सहित जरूरत के permissions दें; “write-only” production writer का goal है, universal magic set नहीं। Writer garbage या capacity abuse कर सकता है। अलग controlled identity, strong authentication और missing jobs, failures, retention/key changes, growth monitoring रखें।
Recovery objectives tolerable data-loss age(RPO) और service interruption(RTO) अलग करते हैं। Business owners/dependencies से चुनें, दूसरी tier table न कॉपी करें।
शिक्षण drill: interruption 09:12; selected data में 08:45 तक committed transactions; staff 11:05 पर agreed service validate करते हैं। Data gap 27 minutes, recovery 113 minutes। RPO 15/RTO 120 हों तो data objective 12 minutes miss और time objective 7 minutes margin में।
09:10 upload में 08:45 data हो तो recovery point नहीं बदलता। Database 10:00 boot भी clock नहीं रोकता यदि invoice या payment reconciliation बाकी हो। Start, data point, validation scope, completion दर्ज करें।
Frequency promise support करे: monthly copy अकेला changing data का weekly RPO नहीं देता। PostgreSQL PITR में documentation suitable physical base और continuous required WAL माँगता है। Logical pg_dump WAL replay का base नहीं। Complete chain और version-specific procedure test करें।
Ransomware-safe point newest copy से पुराना हो सकता है। Compromise assess करके चुनें; encryption से पहले का अर्थ intrusion से पहले नहीं। Data gap और reconciliation ईमानदारी से रखें।
| Drill Measure | Illustrative Target | Observed Result | अर्थ |
|---|---|---|---|
| Data Gap(RPO) | 15 minutes | 09:12−08:45=27 minutes | 12 minutes miss |
| Service Recovery(RTO) | 120 minutes | 09:12→11:05=113 minutes | 7 minutes margin |
| Business Validation | Defined critical workflows | Files, keys, access, external reconciliation सहित | Database boot अकेला पर्याप्त नहीं |
Database, uploaded invoices/media, object versions, configuration, build/software, jobs, integrations और rebuild procedure inventory करें। Consistent recovery set लें; unrelated points के DB/files में attachments missing/wrong हो सकते हैं। Live DB files की copy स्वतः consistent backup नहीं।
Threat model अनुसार transit/at-rest encryption दें। Required decryption material अलग controlled custody में, tested emergency access सहित। Retained backups/encrypted records के historical keys रखें। App encryption key अंधाधुंध न बदलें; controlled migration और पुराने keys चाहिए हो सकते हैं।
Normal admin, vault, identity provider या main region unavailable होने पर test करें। Unlock route production के साथ गायब हो तो archive बेकार। Protected offline runbook और contacts रखें; general handbook में usable secrets न छापें।
Business, legal, discovery needs, point diversity और cost से retention चुनें। 30/90/365 universal नहीं। Last recoverable point की age alert करें, केवल नया filename नहीं। Checksum alteration पकड़ता है, clean/complete/useful backup प्रमाणित नहीं।
Isolated access-controlled target लें; services शुरू होने से पहले payment, email, courier, jobs, webhook side effects block या safely substitute करें। Restored customer data को privacy तथा बाद में secure disposal चाहिए। Test को live integrations पर न लगाएं।
Chosen point के records/balances, attachments, decryption, permissions और critical flows safe identities से जाँचें। Provisioning, download, replay, configuration, authentication, business validation सब timing में हों। Current row count और पुराने backup का सीधा comparison false alarm बना सकता है।
Resume से पहले external truth reconcile करें: provider ने recovery point के बाद capture या courier ने parcel लिया हो सकता है। Old queues rerun, charge या ship अंधाधुंध नहीं। Exception owners, stable references और duplicate protection रखें।
Risk-based calendar में lightweight checks, representative full restores और business exercises रखें। Non-current protected version, missing key, broken log chain, absent admin और restored-job replay test करें। Failures owner/deadline सहित दिखें। Zero error उस verification/scope का परिणाम है, भविष्य की guarantee नहीं।
Incident lead/recovery approver तथा clean out-of-band contacts तय करें। Isolation, evidence, backup protection, specialist response जल्दी शुरू हों; सारे backups fail होने पर ही मदद नहीं। Canadian Cyber Centre playbook response/recovery अलग करता है और restore रोकने वाले credential changes से सावधान करता है।
Responders संग affected access/systems contain करें। Universal “never power off” नहीं: volatile evidence और ongoing harm रोकने का संतुलन team करे। Clean rebuild targets, persistence/entry risks और validation के बाद staged reconnect हो।
Clean context से compromised access rotate करें, पर controlled decryption/recovery बचाएं। Backups और evidence रखें। “हर key अभी बदलें” से restore क्षमता नष्ट न करें।
Data theft, contract, insurance और notification obligations responsible advisers संग assess करें। Operations वापस आने से incident या disclosure समाप्त नहीं। Decisions/actions लिखें और plan review करें।
महत्वपूर्ण service का runbook usual maintainer के अलावा दूसरे व्यक्ति से चलवाएं। Protected version, key path, clean target, validated workflow, RPO/RTO दिखें। Gaps लिखकर खर्च तय करें, फिर customer को time promise दें।
नीचे existing interface walkthrough product demonstration है, आपके immutable copies या target का प्रमाण नहीं। Environment-specific acceptance test रखें।
Green job उपयोगी signal है; मजबूत evidence repeatable recovery है जिसकी सीमाएं बता सकें।
समीक्षा 5 नवंबर 2026 । Anichur Rahaman StoreConsole के निर्माता हैं। Scene, target, time उदाहरण हैं; actual provider capabilities और recovery duties जाँचें।
लेखक का परिचय
Anichur Rahaman
पढ़ना जारी रखें
