निरंतरता और पुनरुद्धार: वह Restore जिसे किसी ने परीक्षित नहीं किया

हर बैकअप डैशबोर्ड हरी जांच दिखाता है। काम पूरा हुए, retention नीति संतुष्ट, storage का उपयोग अपेक्षानुसार। इनमें से कोई भी आपको यह नहीं बताता कि क्या आप किसी वास्तविक घटना के दौरान चार घंटों में bare metal से domain controller वापस ला सकते हैं। "बैकअप सफल" और "restore सफल" के बीच का अंतर वह जगह है जहां अधिकांश निरंतरता योजनाएं quietly विफल होती हैं।

जांच चिह्न झूठ क्यों बोलता है

बैकअप सॉफ़्टवेयर सफलता की रिपोर्ट करता है जब यह किसी गंतव्य को bytes लिखना समाप्त करता है। इसे नहीं पता कि ये bytes उपयोग योग्य हैं या नहीं। एक SQL Server बैकअप साफ-सुथरे तरीके से पूरा हो सकता है और फिर भी unrestorable हो सकता है क्योंकि transaction log chain तीन दिन पहले टूट गई थी और किसी ने ध्यान नहीं दिया। VM snapshots कंसोल में ठीक दिख सकते हैं जबकि अंतर्निहित VSS writer ने guest OS के अंदर silently विफल हो गया हो, जिससे एक crash-consistent (application-consistent नहीं) image तैयार हुआ हो।

Ransomware ऑपरेटर इसे जानते हैं। पिछली घटनाओं में Conti-style playbooks चलाने वाले समूहों ने जानबूझकर बैकअप इंफ्रास्ट्रक्चर को लक्ष्य बनाया — vssadmin delete shadows /all /quiet से shadow copies हटाए, Veeam repositories को अक्षम किया, SMB पर पहुंच योग्य NAS-आधारित बैकअप लक्ष्यों को encrypt किया। यदि आपके बैकअप production के समान नेटवर्क सेगमेंट पर रहते हैं और domain credentials हैं जो उन्हें छू सकते हैं, तो वे safety net नहीं, एक लक्ष्य हैं।

Backup policy नहीं, एक restore runbook बनाएं

एक निरंतरता योजना को step-by-step restore निर्देशों की आवश्यकता होती है जो उस व्यक्ति के लिए लिखे गए हों जो आम तौर पर ऐसा नहीं करता। नीचे लिखें:

• सटीक recovery आदेश (domain controllers और DNS पहले, फिर core apps, फिर बाकी सब कुछ)
• यदि आपका password vault भी down है तो बैकअप कंसोल के लिए credentials कहां रहते हैं
• विशिष्ट restore command या कंसोल path, न कि "VM को restore करने के लिए Veeam का उपयोग करें"
• प्रति system अपेक्षित duration, vendor marketing numbers नहीं, actual measured tests के आधार पर

Veeam Backup & Replication के लिए, इसका अर्थ है actual steps को document करना: कंसोल खोलें, Backups > Disk पर navigate करें, restore point पर right-click करें, scenario के आधार पर Instant VM Recovery या Full VM Restore चुनें, और पर्याप्त free capacity वाले target host को चुनें। यदि आपका primary host भी compromise है, तो आपको एक दूसरा, isolated host पहले से पहचाना हुआ और licensed चाहिए।

Whim नहीं, एक schedule पर restores परीक्षित करें

एक rotation चुनें। हर महीने, एक critical system को एक isolated VLAN में restore करें और validate करें कि यह boot करता है, authenticate करता है, और data सही तरीके से serve करता है। हर quarter, एक full-scope test चलाएं: अपने domain controller, file server, और primary database को isolated infrastructure में restore करें, फिर backup team के बाहर किसी को login करने और एक report pull करने की कोशिश करनी दें।

Databases के लिए, केवल .bak file को restore न करें — इसे verify करें:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

फिर इसे एक test instance में actually restore करें और इसके विरुद्ध DBCC CHECKDB चलाएं। एक backup जो VERIFYONLY को pass करता है उसमें अभी भी logical corruption हो सकता है जो केवल तब दिखता है जब आप इसे query करते हैं।

Linux systems के लिए कुछ जैसे Bacula या restic का उपयोग करते हुए, actual restore path को test करें:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

फिर restored config files को production के विरुद्ध diff करें ताकि confirm करें कि कुछ silently नहीं गिरा।

Immutable copies और 3-2-1-1 rule

क्लासिक 3-2-1 rule (तीन copies, दो media types, एक offsite) को ransomware era के लिए एक अपडेट की जरूरत है: 3-2-1-1, जहां अतिरिक्त "1" एक immutable या air-gapped copy है। S3-compatible storage पर Object lock (Wasabi, Backblaze B2, या AWS S3 with Object Lock enabled) एक परिभाषित retention window के लिए deletion या modification को रोकता है, यहां तक कि admin credentials वाले किसी account द्वारा भी। इसे configure करें:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

COMPLIANCE mode का अर्थ है कि कोई भी, root account सहित, retention को कम नहीं कर सकता या objects को जल्दी delete नहीं कर सकता। जब attacker के पास domain admin हो तो यह मायने रखता है।

RTO और RPO को guesses के साथ नहीं, real numbers के साथ मापें

Recovery Time Objective और Recovery Point Objective paperwork exercises की तरह लगते हैं जब तक कि कोई executive न पूछे "हम कितना data खो देते हैं और हम कितने समय के लिए down हैं।" अपने आखिरी तीन test restores को time करें। यदि आपका RPO target एक घंटा है लेकिन आपका backup job केवल हर छह घंटे चलता है, तो आपके पास एक documented gap है, और यह gap एक tabletop exercise में खोजना actual encryption event के दौरान 2 a.m. को शनिवार को खोजने से बेहतर है।

Test चलाएं, actual clock time लिखें, और इसे disaster recovery document में जो आपने promised किया था उससे compare करें। इन दोनों संख्याओं के बीच का अंतर आपकी continuity plan की वास्तविक स्थिति है।

जिन systems को आप protect कर रहे हैं उन्हें hardening करने और incident response workflows को build करने के बारे में अधिक जानकारी के लिए, Korra Studio पर संबंधित Blue Team और Digital Forensics segments को देखें।