9.5 आपदा पुनर्प्राप्ति और व्यवसाय निरंतरता

अवलोकन और प्रेरणा

देर-सबेर, कोई ऐसी चीज़ जिसकी आपने योजना नहीं बनाई थी, किसी सिस्टम को गिरा देगी: एक क्षेत्र-व्यापी क्लाउड आउटेज, गलती से चला दिया गया DROP TABLE, किसी डेटा सेंटर में बाढ़, एक रैंसमवेयर विस्फोट, या कोई आपूर्तिकर्ता जो रातों-रात गायब हो जाए। सवाल कभी यह नहीं होता कि व्यवधान आएगा या नहीं, बल्कि यह होता है कि आप कितनी तेज़ी से उबरते हैं और इस प्रक्रिया में कितना खोते हैं। यह अध्याय बुरे दिन के आने से पहले उसके लिए तैयार रहने के बारे में है।

दो अनुशासन इस तैयारी का जवाब देते हैं, और वे एक जैसी चीज़ नहीं हैं। बिज़नेस कॉन्टिन्युइटी प्लानिंग (BCP) किसी व्यवधान के दौरान पूरे संगठन को कार्यशील बनाए रखती है: लोग, कार्यालय, संचार, पेरोल, और वे महत्वपूर्ण व्यावसायिक प्रक्रियाएँ जिन पर ग्राहक निर्भर करते हैं। डिज़ास्टर रिकवरी (DR) IT सिस्टम और डेटा को विफल होने के बाद पुनर्स्थापित करने का संकीर्ण, तकनीकी कार्य है। निरंतरता लक्ष्य है; पुनर्प्राप्ति उसके साधनों में से एक है। आप हर सर्वर को पुनर्स्थापित कर सकते हैं और फिर भी अपने ग्राहकों को विफल कर सकते हैं यदि किसी को यह नहीं पता था कि आपदा घोषित करने का अधिकार किसे है या उन तक कैसे पहुँचा जाए। यह अध्याय DR को एक इंजीनियरिंग प्रथा के रूप में और BCP को उस व्यावसायिक ढाँचे के रूप में देखता है जिसकी यह सेवा करती है।

बड़ी टीमों के लिए दांव आपके साथ बढ़ते हैं। एक एंटरप्राइज़ नियामक पुनर्प्राप्ति दायित्व, बहु-क्षेत्रीय उपस्थिति, और कुछ गिने-चुने आपूर्तिकर्ताओं में सांद्रण जोखिम (concentration risk) वहन करता है। सरकार पर नागरिकों के लिए आवश्यक कार्यों को बनाए रखने का कानूनी कर्तव्य होता है, जिसे कॉन्टिन्युइटी ऑफ़ ऑपरेशंस के रूप में संहिताबद्ध किया गया है। दोनों ऐसी जाँच के अंतर्गत काम करते हैं जहाँ एक अपरीक्षित योजना एक देनदारी है जिसे आप सबसे बुरे संभव क्षण पर खोजेंगे। पुनर्प्राप्ति वह जगह है जहाँ विश्वसनीयता (अध्याय 9.1) और घटना प्रतिक्रिया (अध्याय 9.3) उस कठिन प्रश्न से मिलते हैं कि उन विफलताओं से कैसे बचा जाए जिन्हें आप डिज़ाइन करके टाल नहीं सकते।

मुख्य सिद्धांत

• निरंतरता पुनर्प्राप्ति से व्यापक है। सर्वर को पुनर्स्थापित करना व्यवसाय को चालू रखने के समान नहीं है।
• दो संख्याएँ सब कुछ तय करती हैं। रिकवरी टाइम ऑब्जेक्टिव (RTO) और रिकवरी पॉइंट ऑब्जेक्टिव (RPO), जो व्यावसायिक प्रभाव से तय होती हैं, हर निर्णय का आकार तय करती हैं।
• एक अपरीक्षित बैकअप बैकअप नहीं है। एक रीस्टोर जो आपने कभी नहीं किया, वह एक उम्मीद है, क्षमता नहीं।
• मान लें कि बैकअप एक लक्ष्य है। रैंसमवेयर सबसे पहले आपके बैकअप का शिकार करता है, इसलिए प्रतियों को अपरिवर्तनीय (immutable) और ऑफ़लाइन रखें।
• मेमोरी से नहीं, कोड से पुनर्निर्माण करें। यदि आप इन्फ्रास्ट्रक्चर को सोर्स से फिर से नहीं बना सकते, तो आप इसे विश्वसनीय रूप से पुनर्प्राप्त नहीं कर सकते।
• जिस पर आप निर्भर हैं उसे मैप करें। आप केवल उतनी ही तेज़ी से पुनर्प्राप्त कर सकते हैं जितनी तेज़ी आपकी सबसे धीमी अपस्ट्रीम निर्भरता की है।
• पुनर्प्राप्ति को किसी भी अन्य सिस्टम की तरह मापें। वास्तविक ड्रिल से प्राप्त वास्तविक RTO और RPO, न कि वे संख्याएँ जो आपने किसी स्लाइड पर लिखी थीं।

सिफारिशें

RTO और RPO को व्यावसायिक प्रभाव विश्लेषण से तय करें

हर पुनर्प्राप्ति निर्णय दो संख्याओं से उतरता है, इसलिए पहले उन्हें सही करें। रिकवरी टाइम ऑब्जेक्टिव (RTO) यह है कि नुकसान असहनीय होने से पहले कोई सिस्टम कितनी देर तक बंद रह सकता है। रिकवरी पॉइंट ऑब्जेक्टिव (RPO) यह है कि आप कितना डेटा खोना वहन कर सकते हैं, जिसे उस अंतिम अच्छी प्रति की उम्र के रूप में मापा जाता है जिस तक आप पुनर्स्थापित कर सकते हैं। एक भुगतान लेजर को मिनटों का RTO और लगभग शून्य के RPO की माँग हो सकती है; एक आंतरिक एनालिटिक्स डैशबोर्ड दोनों में से एक दिन को सहन कर सकता है। आप इन्हें इंजीनियरिंग में तय नहीं कर सकते। इन्हें एक बिज़नेस इम्पैक्ट एनालिसिस (BIA) से प्राप्त करें जो व्यावसायिक प्रक्रियाओं को उनके व्यवधान की लागत के अनुसार रैंक करता है और हर एक को उन सिस्टम और डेटा तक वापस ट्रेस करता है जिनकी उसे ज़रूरत है। सख्त उद्देश्यों की लागत अधिक होती है, इसलिए BIA ही वह चीज़ है जो आपको किसी तुच्छ सेवा को अत्यधिक सुरक्षित करने और किसी महत्वपूर्ण सेवा को कम-सुरक्षित रखने से रोकती है।

बैकअप सही ढंग से करें: 3-2-1 नियम, अपरिवर्तनीयता, और परीक्षण

बैकअप हर पुनर्प्राप्ति रणनीति के नीचे की नींव हैं, और अधिकांश संगठन इन्हें उससे भी बदतर तरीके से करते हैं जितना वे सोचते हैं। बैकअप के उस अनुशासन का पालन करें जिसे 3-2-1 नियम कहा जाता है: अपने डेटा की कम से कम तीन प्रतियाँ रखें, दो अलग-अलग मीडिया या सिस्टम पर, जिसमें एक प्रति ऑफ़-साइट हो। आधुनिक खतरे दो और आवश्यकताएँ जोड़ते हैं। कम से कम एक प्रति को अपरिवर्तनीय (immutable) रखें (एक बार लिखी गई, प्रतिधारण अवधि के लिए हटाई न जा सकने वाली) और आदर्श रूप से ऑफ़लाइन या एयर-गैप्ड, क्योंकि रैंसमवेयर अब खुद को घोषित करने से पहले जानबूझकर पहुँच योग्य बैकअप को एन्क्रिप्ट या हटा देता है। सबसे बढ़कर, एक निर्धारित समय-सारणी पर रीस्टोर का परीक्षण करें। एक अपरीक्षित बैकअप बैकअप नहीं है, यह एक अपरीक्षित धारणा है, और ड्रिल में आप जो विफलताएँ पाते हैं (दूषित आर्काइव, गुम एन्क्रिप्शन कुंजियाँ, गलत वॉल्यूम के बैकअप) वे ठीक वही हैं जो किसी वास्तविक घटना में आपका अंत कर देतीं।

लागत-बनाम-गति स्पेक्ट्रम के साथ एक DR रणनीति चुनें

DR रणनीतियाँ पुनर्प्राप्ति की गति के लिए पैसे का व्यापार करती हैं, और आपको हर चीज़ के लिए एक ही टियर खरीदने के बजाय हर सिस्टम के लिए उसके RTO और RPO के आधार पर चुनना चाहिए। चार पैटर्न इस स्पेक्ट्रम को टिकाए रखते हैं। बैकअप और रीस्टोर सबसे सस्ता और सबसे धीमा है: आपदा आने पर आप बैकअप से पुनर्निर्माण करते हैं, जिसका RTO घंटों से लेकर दिनों तक होता है। पायलट लाइट एक न्यूनतम कोर (प्रतिकृति बनाते डेटाबेस, कोर कॉन्फ़िगरेशन मौजूद) को गर्म लेकिन घटे हुए पैमाने पर रखता है, जो विस्तार के लिए तैयार होता है। वार्म स्टैंडबाय पूरे स्टैक की एक छोटी, हमेशा चालू रहने वाली प्रति चलाता है जिसे आप फेलओवर पर बड़ा करते हैं, जिससे RTO मिनटों तक घट जाता है। मल्टी-साइट एक्टिव-एक्टिव दो या अधिक स्थानों में पूरी क्षमता चलाता है जो लाइव ट्रैफ़िक की सेवा करती है, जो सबसे अधिक लागत और जटिलता पर लगभग-शून्य RTO देता है। टियर को उस संख्या से मिलाएँ जिस पर व्यवसाय ने सहमति दी है, और ऐसे सिस्टम के लिए एक्टिव-एक्टिव की कीमत न चुकाएँ जो पायलट लाइट को सहन कर सकता है।

कॉन्सिस्टेंसी ट्रेड-ऑफ़ को ध्यान में रखते हुए डेटा की प्रतिकृति बनाएँ

पुनर्प्राप्ति की गति इस बात पर निर्भर करती है कि आपका स्टैंडबाय डेटा कितना अद्यतन है, और यहाँ आप डिस्ट्रिब्यूटेड सिस्टम (अध्याय 3.3) की कठिन समस्याओं को विरासत में पाते हैं। सिंक्रोनस रेप्लिकेशन किसी लेखन को स्वीकार करने से पहले उसे दूसरे स्थान पर पुष्ट करता है, जिससे लगभग-शून्य RPO मिलता है लेकिन इसकी कीमत बढ़ी हुई राइट लेटेंसी और दूरी पर एक सख्त सीमा के रूप में चुकानी पड़ती है। असिंक्रोनस रेप्लिकेशन स्थानीय रूप से स्वीकार करता है और बाद में परिवर्तन भेजता है, इसलिए यह तेज़ और भौगोलिक रूप से लचीला है लेकिन एक रेप्लिकेशन लैग विंडो छोड़ जाता है जिसे आप फेलओवर पर खो देंगे। यहाँ कोई मुफ़्त विकल्प नहीं है: मज़बूत कॉन्सिस्टेंसी की कीमत लेटेंसी में चुकानी पड़ती है, कमज़ोर कॉन्सिस्टेंसी की कीमत डेटा में। हर डेटा स्टोर के लिए उसके RPO से निर्णय लें, और अपना सामान्य रेप्लिकेशन लैग जानें, क्योंकि बुरे दिन पर वही लैग आपका वास्तविक RPO होता है, न कि डिज़ाइन दस्तावेज़ में लिखी संख्या।

इन्फ्रास्ट्रक्चर एज़ कोड के साथ कोड से पुनर्निर्माण करें

आप हाथ से प्रोविज़न किए गए वातावरण को विश्वसनीय रूप से पुनर्प्राप्त नहीं कर सकते, क्योंकि किसी को भी हर क्लिक याद नहीं रहता। अपने वातावरण को इन्फ्रास्ट्रक्चर एज़ कोड (अध्याय 8.2) के रूप में परिभाषित करें ताकि पूरे स्टैक को एक ज्ञात-अच्छी स्थिति में वर्ज़न-नियंत्रित सोर्स से फिर से बनाया जा सके। यह पुनर्प्राप्ति को एक पुरातत्व परियोजना से एक दोहराए जाने योग्य पाइपलाइन रन में बदल देता है, आपके स्टैंडबाय क्षेत्र को ईमानदार रखता है (जब दोनों एक ही कोड से बनाए जाते हैं तो यह कम भटकता है), और किसी समझौते के बाद एक नए खाते या क्षेत्र में पुनर्प्राप्ति इन्फ्रास्ट्रक्चर खड़ा करने का एक स्वच्छ तरीका देता है। कोड, सीक्रेट्स संदर्भों, और रनबुक को कहीं ऐसी जगह संग्रहित करें जो आपके प्राथमिक वातावरण के नुकसान से भी बची रहे।

निर्भरताओं की ज़रूरत पड़ने से पहले उन्हें मैप करें

सिस्टम जालों में विफल होते हैं, अलगाव में नहीं, और पुनर्प्राप्ति उस निर्भरता पर अटक जाती है जिसे आप भूल गए थे। हर महत्वपूर्ण सिस्टम को कार्य करने के लिए क्या चाहिए, यह मैप करें: अपस्ट्रीम सेवाएँ, DNS, पहचान और प्रमाणीकरण, सर्टिफिकेट अथॉरिटीज़, मैसेज क्यू, और थर्ड-पार्टी API और SaaS प्रोवाइडर। पुनर्प्राप्ति क्रम को नोट करें, क्योंकि किसी एप्लिकेशन को उसके डेटाबेस या उसके पहचान प्रोवाइडर से पहले खड़ा करना केवल एक दूसरा आउटेज उत्पन्न करता है। बाहरी आपूर्तिकर्ताओं पर विशेष ध्यान दें, क्योंकि आपकी पुनर्प्राप्ति उनकी पुनर्प्राप्ति से सीमित होती है और हो सकता है कि आपको इसमें कोई दृश्यता न हो। यह मैपिंग सीधे रेज़िलिएंस और सुशोभित पतन (graceful degradation) (अध्याय 3.5) से जुड़ती है: किसी सिस्टम की जितनी कम कठोर निर्भरताएँ होंगी, वह उतनी ही तेज़ी से वापस आएगा।

पुनर्प्राप्ति को एक घटना नहीं, एक प्रथा के रूप में टेस्ट करें

एक DR योजना जिसका आपने अभ्यास नहीं किया है वह कल्पना है। परीक्षणों की एक सीढ़ी बनाएँ। एक टेबलटॉप एक्सरसाइज़ टीम को कागज़ पर एक परिदृश्य से गुज़ारती है ताकि भूमिकाओं, निर्णयों, और संचार में खामियाँ मिल सकें। एक गेम डे एक जीवंत-जैसे वातावरण में एक वास्तविक, नियंत्रित विफलता डालता है। एक पूर्ण फेलओवर ड्रिल वास्तव में पुनर्प्राप्ति साइट पर स्विच करता है और उस पर चलता है। इन्हें एक निर्धारित लय पर चलाएँ, परिदृश्यों को बदलते रहें (किसी प्रमुख व्यक्ति या आपूर्तिकर्ता के नुकसान सहित), और परिणाम को मापें: आपके द्वारा प्राप्त वास्तविक RTO और RPO को दर्ज करें और उनकी लक्ष्य से तुलना करें। मापी गई और वादा की गई पुनर्प्राप्ति के बीच का अंतर आपके पास मौजूद सबसे ईमानदार विश्वसनीयता मीट्रिक है, और इसे कम करना ही ड्रिल का पूरा मक़सद है।

साइबर-पुनर्प्राप्ति की अपने स्वयं के परिदृश्य के रूप में योजना बनाएँ

रैंसमवेयर और विनाशकारी साइबर हमले सामान्य DR की धारणाओं को तोड़ देते हैं, इसलिए इन्हें अलग से मानें। किसी प्राकृतिक आपदा में आपका डेटा कहीं और सुरक्षित रहता है; एक रैंसमवेयर घटना में आपका डेटा और अक्सर आपके बैकअप ही हथियार होते हैं, और आपका पुनर्प्राप्ति वातावरण स्वयं भी समझौता किया हुआ हो सकता है। एक क्लीन-रूम रिकवरी की योजना बनाएँ: एक अलग-थलग, विश्वसनीय वातावरण जहाँ आप अपरिवर्तनीय प्रतियों से पुनर्स्थापित करें, घुसपैठ के लिए स्कैन करें, और किसी भी चीज़ को फिर से जोड़ने से पहले पहचान और क्रेडेंशियल्स का पुनर्निर्माण करें। जानें कि कौन-सा बैकअप आपका अंतिम ज्ञात-स्वच्छ बिंदु है, और यह अपेक्षा करें कि उसे खोजने में फोरेंसिक समय लगेगा जिसका आपके सामान्य RTO ने कभी बजट नहीं रखा। यहीं पर अपरिवर्तनीय, ऑफ़लाइन प्रतियाँ अपनी लागत अर्जित करती हैं, और यह घटना प्रबंधन (अध्याय 9.3) और उल्लंघन प्रबंधन के लिए अनुपालन और गवर्नेंस दायित्वों (अध्याय 4.6) से सख्ती से जुड़ता है।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

DR strategy	Pros	Cons
बैकअप और रीस्टोर	सबसे सस्ती; सरल; कम चालू लागत	धीमा RTO (घंटों से दिनों तक); बड़ा RPO
पायलट लाइट	कम लागत; कोर डेटा गर्म और तैयार	मैन्युअल स्केल-अप; पुनर्प्राप्ति में फिर भी वास्तविक समय लगता है
वार्म स्टैंडबाय	तेज़ RTO (मिनट); पूरा स्टैक सिद्ध	दूसरे चालू वातावरण की निरंतर लागत
मल्टी-साइट एक्टिव-एक्टिव	लगभग-शून्य RTO; कोई एकल-साइट विफलता नहीं	सबसे अधिक लागत और जटिलता; कॉन्सिस्टेंसी कठिन है
सिंक्रोनस रेप्लिकेशन	लगभग-शून्य RPO	राइट लेटेंसी; दूरी-सीमित; कड़ा युग्मन
असिंक्रोनस रेप्लिकेशन	तेज़, लचीला, भौगोलिक रूप से मुक्त	रेप्लिकेशन लैग के बराबर डेटा हानि विंडो

केंद्रीय तनाव यह है कि पुनर्प्राप्ति की गति और डेटा की ताज़गी दोनों की कीमत पैसे और जटिलता में चुकानी पड़ती है, और किसी भी टियर पर कुछ भी मुफ़्त नहीं है। इसे प्रति संगठन के बजाय प्रति सिस्टम हल करें: व्यावसायिक प्रभाव विश्लेषण को हर महत्वपूर्ण सिस्टम को एक RTO और RPO सौंपने दें, फिर ठीक वही रणनीति खरीदें जो इसे पूरा करती है। किसी रिपोर्टिंग टूल पर एक्टिव-एक्टिव का पैसा खर्च करना उस लेजर को भूखा रखता है जिसे इसकी ज़रूरत थी, और इसका उल्टा लापरवाही है। अनुशासन खर्च को उस संख्या से मिलाना है जिसका व्यवसाय स्वामी है, और सिस्टम के महत्व बदलने पर उस मिलान को फिर से देखना है।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. आपके हर महत्वपूर्ण सिस्टम के लिए RTO और RPO क्या हैं, और व्यवसाय में किसने उन पर सहमति दी? यदि इंजीनियरिंग ने अकेले ये संख्याएँ गढ़ी हैं, तो वे अनुमान हैं, और अनुमानों को या तो बहुत उदारता से वित्तपोषित किया जाता है या बिल्कुल नहीं। रिकवरी टाइम और रिकवरी पॉइंट ऑब्जेक्टिव को एक व्यावसायिक प्रभाव विश्लेषण से निकलना चाहिए जो प्रक्रियाओं को उनके व्यवधान की लागत के अनुसार रैंक करता है, ताकि लेजर को मिनट मिलें और आंतरिक विकी को एक दिन। अपनी वर्तमान टियरिंग लाएँ और पूछें कि क्या हर व्यावसायिक प्रक्रिया के लिए जवाबदेह व्यक्ति वास्तव में उस डेटा हानि और डाउनटाइम को स्वीकार करेगा जिसके लिए आपने डिज़ाइन किया है। एक बड़े संगठन में यह बातचीत वही है जो सब कुछ समान रूप से सुरक्षित करने की महँगी गलती को रोकती है, जो कुछ भी अच्छी तरह सुरक्षित नहीं करती। यदि इंजीनियरिंग के बाहर कोई भी ये संख्याएँ नहीं बता सकता, तो आपके पास अभी उद्देश्य नहीं हैं, आपके पास उम्मीदें हैं।

2. आपने आखिरी बार वास्तविक रीस्टोर कब किया था, और क्या आपने अपने प्राप्त वास्तविक RTO और RPO को मापा? एक बैकअप जिसे आपने कभी पुनर्स्थापित नहीं किया वह एक अपरीक्षित धारणा है, और वे फेलियर मोड जो आपको मार देते हैं (दूषित आर्काइव, खोई हुई एन्क्रिप्शन कुंजियाँ, गलत वॉल्यूम का स्नैपशॉट, एक निर्भरता जो चालू नहीं होगी) केवल तभी सामने आते हैं जब आप कोशिश करते हैं। अपने पिछले टेबलटॉप का नहीं, बल्कि अपने पिछले पूर्ण फेलओवर ड्रिल की तारीख और परिणाम लाएँ, और उस पुनर्प्राप्ति के बीच का अंतर जो आपने प्राप्त किया और जो आपने वादा किया था। एक बड़ी टीम के लिए, एक सिस्टम का एक सफल रीस्टोर दूसरों को साबित नहीं करता, इसलिए पूछें कि पिछले वर्ष में कितने अनुपात के महत्वपूर्ण सिस्टम को आरंभ से अंत तक पुनर्प्राप्त किया गया है। मापा गया अंतर आपकी सबसे ईमानदार विश्वसनीयता संख्या है, और यदि आप इसे बता नहीं सकते, तो जब तक अन्यथा साबित न हो जाए, आपकी योजना कल्पना है।

3. यदि आज रात रैंसमवेयर ने आपके प्रोडक्शन को एन्क्रिप्ट कर दिया और आपके बैकअप तक पहुँच गया, तो आपकी अंतिम ज्ञात-स्वच्छ प्रति क्या है और आप कहाँ पुनर्निर्माण करेंगे? सामान्य डिज़ास्टर रिकवरी यह मान लेती है कि आपका डेटा कहीं और सुरक्षित है, और एक विनाशकारी साइबर हमला ठीक उसी धारणा को तोड़ देता है क्योंकि यह आपके डेटा और आपके बैकअप को ही हथियार बना देता है। पूछें कि क्या कम से कम एक बैकअप प्रति अपरिवर्तनीय और ऑफ़लाइन है, आप अंतिम स्वच्छ रीस्टोर बिंदु की पहचान कैसे करेंगे, और जब प्रोडक्शन स्वयं समझौता कर चुका हो तो एक विश्वसनीय क्लीन-रूम वातावरण कहाँ से आएगा। इस परिदृश्य को फोरेंसिक समय चाहिए जिसका आपके सामान्य RTO ने कभी बजट नहीं रखा, इसलिए यह ईमानदार अनुमान लाएँ कि स्वच्छ बिंदु खोजने में वास्तव में कितना समय लगता है। एंटरप्राइज़ और सरकारी टीमों के लिए यह एक अनुपालन घटना भी है (अध्याय 4.6) जिसमें समानांतर रूप से उल्लंघन-सूचना की घड़ियाँ चल रही होती हैं। यदि जवाब है “हम नवीनतम बैकअप को पुनर्स्थापित करेंगे,” तो आपने इसके लिए बिल्कुल भी योजना नहीं बनाई है।

4. आपके कौन-से सिस्टम एक ऐसे पुनर्प्राप्ति टियर के लिए भुगतान कर रहे हैं जिसे उनका व्यावसायिक प्रभाव विश्लेषण उचित नहीं ठहराता, और कौन-सा खतरनाक रूप से कम-सुरक्षित है? पुनर्प्राप्ति की गति और डेटा की ताज़गी दोनों की कीमत हर टियर पर पैसे में चुकानी पड़ती है, इसलिए एक व्यापक नीति या तो किसी रिपोर्टिंग टूल पर एक्टिव-एक्टिव बजट बर्बाद करती है या उस लेजर को भूखा रखती है जिसे वास्तव में इसकी ज़रूरत थी। प्रतिस्पर्धी खिंचाव वास्तविक है: कई टीमों के लिए एक मानक टियर संचालित करना कहीं अधिक सरल है, जबकि प्रति सिस्टम टियरिंग खर्च को मूल्य से मिलाती है लेकिन सिस्टम के महत्व बदलने पर निरंतर क्यूरेशन की माँग करती है। हर महत्वपूर्ण सिस्टम के लिए वर्तमान DR रणनीति, उसका लक्षित RTO और RPO, उसके स्टैंडबाय और रेप्लिकेशन की मासिक लागत, और वह तारीख लाएँ जब टियरिंग को एक ताज़ा प्रभाव विश्लेषण के विरुद्ध आखिरी बार फिर से देखा गया था। एक एंटरप्राइज़ या सरकारी सेटिंग में एक बेमेल टियर क्षेत्रों में गुणा हो जाता है और ऑडिट आपसे उस पैसे और उस जोखिम दोनों को उचित ठहराने के लिए कहेगा जिन्हें आप स्वीकार करते हैं, इसलिए एक अस्पष्ट एक्टिव-एक्टिव बिल और एक असुरक्षित महत्वपूर्ण सेवा दोनों का बचाव करना समान रूप से कठिन है।

5. क्या आप वास्तव में अपने महत्वपूर्ण सिस्टम का पुनर्प्राप्ति क्रम जानते हैं, और आपकी पुनर्प्राप्ति कितनी दूर तक उन आपूर्तिकर्ताओं पर निर्भर करती है जिन्हें आप टेस्ट नहीं कर सकते? सिस्टम जालों में विफल होते हैं, अलगाव में नहीं, और एक पुनर्प्राप्ति उस निर्भरता पर अटक जाती है जिसे किसी ने मैप नहीं किया: किसी एप्लिकेशन को उसके डेटाबेस, पहचान प्रोवाइडर, या DNS से पहले खड़ा करें और आप बस एक दूसरा आउटेज उत्पन्न करते हैं। निर्भरताओं को मैप करना थकाऊ है और मैप पुराना पड़ जाता है, लेकिन विकल्प यह है कि फेलओवर के दौरान लाइव पुनर्प्राप्ति क्रम की खोज करें, और कुछ गिने-चुने SaaS प्रोवाइडरों में सांद्रण जोखिम तब तक अदृश्य रहता है जब तक वे एक साथ विफल नहीं होते और आपकी पुनर्प्राप्ति को अपने तक सीमित नहीं करते। एक वर्तमान निर्भरता मैप, दस्तावेज़ीकृत पुनर्प्राप्ति क्रम, और उनकी बताई गई पुनर्प्राप्ति प्रतिबद्धताओं के साथ बाहरी आपूर्तिकर्ताओं की एक सूची लाएँ, और क्या आपने उनमें से किसी को कभी सत्यापित किया है। एक बड़े या सार्वजनिक संगठन के लिए, आपूर्तिकर्ता निरंतरता और सांद्रण जोखिम तेज़ी से एक खरीद और नियामक चिंता बनते जा रहे हैं, इसलिए वे पुनर्प्राप्ति दायित्व किसी विक्रेता की मार्केटिंग के बजाय अनुबंध में एक ऐसे रूप में होने चाहिए जिसकी आप ऑडिट कर सकें।

6. यदि आपने आज रात हर सर्वर को पुनर्स्थापित कर दिया, तो क्या व्यवसाय वास्तव में चलता रहेगा, और आपदा घोषित करने के लिए कौन अधिकृत है? डिज़ास्टर रिकवरी IT को पुनर्स्थापित करती है, लेकिन बिज़नेस कॉन्टिन्युइटी संगठन को कार्यशील रखती है: लोग, संचार, पेरोल, और वे निर्णय जो इस पर निर्भर करते हैं कि किसी के पास उन्हें लेने का अधिकार हो। आप हर सिस्टम को पुनर्प्राप्त कर सकते हैं और फिर भी अपने ग्राहकों को विफल कर सकते हैं यदि किसी को यह नहीं पता था कि आपदा कौन घोषित कर सकता है या सामान्य चैनल भी बंद होने पर स्टाफ़ तक कैसे पहुँचा जाए। इंजीनियरिंग पुनर्प्राप्ति की स्वामी है, फिर भी निरंतरता सुविधाओं, HR, संचार, और नेतृत्व उत्तराधिकार तक फैली होती है, और विभागों के बीच वे सीवनें ही ठीक वह जगह हैं जहाँ एक योजना चुपचाप सड़ती है। घोषणा प्राधिकार और एस्केलेशन चेन, फ़ॉलबैक संचार योजना, नामित उत्तराधिकारी और वैकल्पिक सुविधाएँ, और वह तारीख लाएँ जब व्यावसायिक पक्ष (केवल IT नहीं) ने आखिरी बार योजना का अभ्यास किया था। सरकार पर नामित उत्तराधिकारियों और आवश्यक कार्यों के साथ एक कानूनी कॉन्टिन्युइटी-ऑफ़-ऑपरेशंस कर्तव्य होता है, और एंटरप्राइज़ को नियामक निरंतरता दायित्वों का सामना करना पड़ता है, इसलिए दोनों को इस आधार पर आँका जाता है कि क्या व्यवसाय बुरे दिन से बचता है, न कि केवल सर्वर।

क्षेत्रीय दृष्टिकोण

स्टार्टअप। एक छोटी टीम और कम रनवे के साथ, आप एक गर्म दूसरा क्षेत्र वहन नहीं कर सकते, इसलिए उन सस्ते हिस्सों के बारे में जानबूझकर सोचें जो फिर भी आपको बचाते हैं। एक ईमानदार पुनर्प्राप्ति टियर तय करें, स्वचालित स्नैपशॉट और कम से कम एक अपरिवर्तनीय प्रति के साथ 3-2-1 नियम का पालन करें जिसे आपके अपने एडमिन भी नहीं हटा सकते, और पूरे वातावरण को इन्फ्रास्ट्रक्चर एज़ कोड के रूप में रखें ताकि आप सोर्स से पुनर्निर्माण कर सकें। विस्तृत योजना छोड़ें और इसके बजाय हर तिमाही एक स्क्रैच वातावरण में एक वास्तविक रीस्टोर चलाएँ, क्योंकि एक ही समयबद्ध ड्रिल आपको उससे अधिक सिखाती है जितना कोई बाइंडर सिखाता है जिसे कोई नहीं पढ़ता।

लघु व्यवसाय। बिना किसी समर्पित निरंतरता विशेषज्ञ और सीमित बजट के, पुनर्प्राप्ति को बनाने के बजाय खरीदने वाली चीज़ के रूप में मानें। अनुकूलित DR इन्फ्रास्ट्रक्चर खड़ा करने के बजाय अपने क्लाउड प्रोवाइडर के प्रबंधित बैकअप, स्नैपशॉट, और क्रॉस-रीजन रेप्लिकेशन पर निर्भर रहें, और ऐसे विक्रेता चुनें जिनके बैकअप अपरिवर्तनीय हों और जिनकी रीस्टोर प्रक्रिया आप वास्तव में स्वयं चला सकें। पूरे अभ्यास को दो प्रश्नों के इर्द-गिर्द तैयार करें जिनका उत्तर आप बिना किसी विशेषज्ञ के दे सकें: हम कितना डेटा खो सकते हैं, और हम कितनी देर तक बंद रह सकते हैं, और किसी रीस्टोर पर भरोसा करने से पहले साबित करें कि यह काम करता है।

एंटरप्राइज़। पैमाने पर समस्या कई टीमों में पोर्टफ़ोलियो गवर्नेंस की है: एक व्यावसायिक प्रभाव विश्लेषण जो हर सेवा को एक RTO और RPO सौंपता है, बैकअप-और-रीस्टोर से लेकर एक्टिव-एक्टिव तक टियर की गई पुनर्प्राप्ति रणनीतियाँ, और अपस्ट्रीम और आपूर्तिकर्ता निर्भरताओं का एक केंद्रीय दृश्य जिसमें सांद्रण जोखिम शामिल है। स्टैंडबाय, रेप्लिकेशन, और अपरिवर्तनीय-प्रति की लागतों का स्पष्ट रूप से बजट बनाएँ, एक निर्धारित लय पर नियामक-साक्षी पूर्ण फेलओवर चलाएँ, और एक ट्रैक की गई विश्वसनीयता मीट्रिक के रूप में लक्ष्य के विरुद्ध वास्तविक पुनर्प्राप्ति को मापें। साइबर-पुनर्प्राप्ति को अपरिवर्तनीय वॉल्ट प्रतियों और एक क्लीन-रूम रनबुक के साथ अपने स्वयं के कार्यक्रम के रूप में बनाए रखें, जिसका परीक्षण प्राकृतिक-आपदा ड्रिल से स्वतंत्र रूप से किया जाए।

सरकार। खरीद नियम, पारदर्शिता, और सार्वजनिक जवाबदेही हर विकल्प को आकार देते हैं, और निरंतरता अक्सर एक प्राथमिकता के बजाय एक कानूनी कर्तव्य होती है। एक कॉन्टिन्युइटी-ऑफ़-ऑपरेशंस कार्यक्रम बनाएँ जो आवश्यक कार्यों की पहचान करे, उनकी पुनर्प्राप्ति का क्रम तय करे, और उत्तराधिकारियों तथा वैकल्पिक सुविधाओं को नामित करे ताकि निर्णय कभी भी किसी अधिकृत व्यक्ति की कमी के कारण न रुकें, और इसे NIST SP 800-34 जैसे मान्यता प्राप्त मार्गदर्शन के साथ FISMA दायित्वों के समर्थन में संरेखित करें। एयर-गैप्ड बैकअप प्रतियाँ रखें, फिर से निर्माण के लिए एक वैकल्पिक क्षेत्र में इन्फ्रास्ट्रक्चर एज़ कोड परिभाषित करें, और एक वार्षिक पूर्ण अभ्यास और रैंसमवेयर टेबलटॉप ड्रिल चलाएँ जिनके मापे गए परिणाम आप निरीक्षण निकायों को इस प्रमाण के रूप में रिपोर्ट करते हैं कि आवश्यक सेवाएँ बच जाती हैं।

उदाहरण

स्टार्टअप। बारह लोगों की एक SaaS कंपनी एक गर्म दूसरा क्षेत्र वहन नहीं कर सकती, इसलिए यह सस्ते हिस्सों के बारे में जानबूझकर सोचती है। यह एक ईमानदार टियर तय करती है: ग्राहक डेटाबेस के लिए चार घंटे का RTO, पंद्रह मिनट का RPO। यह स्वचालित स्नैपशॉट के साथ 3-2-1 नियम का पालन करती है, एक प्रति दूसरे क्लाउड क्षेत्र में प्रतिकृत होती है और एक अपरिवर्तनीय प्रति एक लॉक की गई प्रतिधारण विंडो के साथ होती है जिसे इसके अपने एडमिन भी नहीं हटा सकते। इसका पूरा वातावरण इन्फ्रास्ट्रक्चर एज़ कोड (अध्याय 8.2) है, इसलिए यह सोर्स से एक नया स्टैक खड़ा कर सकती है। हर तिमाही में एक बार यह शुक्रवार दोपहर को एक स्क्रैच वातावरण में एक वास्तविक रीस्टोर चलाती है, इसका समय नापती है, और एक छोटा नोट दर्ज करती है। पहले ड्रिल में नौ घंटे लगे और एक गुम माइग्रेशन चरण मिला; उस सुधार के कारण अगले में केवल तीन घंटे लगे।

एंटरप्राइज़। एक बहुराष्ट्रीय बैंक नियामक पुनर्प्राप्ति आवश्यकताओं के अंतर्गत काम करता है जो महत्वपूर्ण सेवाओं के लिए परीक्षित निरंतरता अनिवार्य करती हैं। यह अपने कोर बैंकिंग प्लेटफ़ॉर्म के लिए दूसरे क्षेत्र में वार्म स्टैंडबाय चलाता है, जिसमें लगभग-शून्य RPO के लिए एक मेट्रो जोड़ी के भीतर सिंक्रोनस रेप्लिकेशन और क्षेत्रीय-आपदा से बचने के लिए एक दूर के क्षेत्र में असिंक्रोनस रेप्लिकेशन शामिल है। एक व्यावसायिक प्रभाव विश्लेषण हर सेवा को एक RTO और RPO सौंपता है, और एक केंद्रीय टीम अपस्ट्रीम निर्भरताओं को मैप करती है जिसमें दो SaaS प्रोवाइडर सांद्रण जोखिम के रूप में चिह्नित हैं। साल में दो बार यह एक पूर्ण नियामक-साक्षी फेलओवर करता है, वास्तविक की लक्ष्य से तुलना करता है, और खामियों को अगले चक्र में फ़ीड करता है। एक अलग साइबर-पुनर्प्राप्ति कार्यक्रम अपरिवर्तनीय वॉल्ट प्रतियों और एक क्लीन-रूम रनबुक को बनाए रखता है, जिसका परीक्षण प्राकृतिक-आपदा ड्रिल से स्वतंत्र रूप से किया जाता है।

सरकार। लाभ प्रदान करने वाली एक राष्ट्रीय एजेंसी एक कॉन्टिन्युइटी ऑफ़ ऑपरेशंस (COOP) कार्यक्रम बनाए रखती है जो किसी भी व्यवधान के दौरान अपने आवश्यक कार्यों को बनाए रखने के लिए बनाया गया है। कॉन्टिन्युइटी ऑफ़ ऑपरेशंस प्रथा और NIST SP 800-34 कंटिनजेंसी-प्लानिंग मार्गदर्शन का पालन करते हुए जो इसके FISMA दायित्वों का समर्थन करता है, यह आवश्यक कार्यों की पहचान करती है, उनकी पुनर्प्राप्ति का क्रम तय करती है, और उत्तराधिकारियों तथा वैकल्पिक सुविधाओं को नामित करती है ताकि किसी अधिकृत व्यक्ति की कमी के कारण निर्णय कभी न रुकें। नागरिक-सामना वाले सिस्टम में दस्तावेज़ीकृत RTO और RPO होते हैं, बैकअप एयर-गैप्ड प्रतियों के साथ 3-2-1 नियम का पालन करते हैं, और इन्फ्रास्ट्रक्चर को एक वैकल्पिक क्षेत्र में पुनर्निर्माण के लिए कोड के रूप में परिभाषित किया जाता है। एक वार्षिक पूर्ण अभ्यास, साथ ही रैंसमवेयर परिदृश्य के लिए टेबलटॉप ड्रिल, योजना को मापी गई पुनर्प्राप्ति के विरुद्ध टेस्ट करते हैं, और परिणाम निरीक्षण निकायों को इस प्रमाण के रूप में रिपोर्ट किए जाते हैं कि आवश्यक सेवाएँ बुरे दिन से बच जाती हैं।

बिज़नेस केस: प्रेरणाएँ, ROI, और TCO

DR और निरंतरता पर प्रतिफल टली हुई तबाही है, जिसका मूल्यांकन करना तब तक वास्तव में कठिन होता है जब तक आपको इसकी ज़रूरत न हो और जब ज़रूरत हो तो यह दर्दनाक रूप से ठोस हो जाता है। इसे जोखिम प्रबंधन के रूप में तैयार करें: किसी व्यवधान की अपेक्षित लागत उसकी संभावना गुणा उसके प्रभाव के बराबर होती है, और एक बड़े संगठन के लिए प्रभाव डाउनटाइम के प्रति घंटे खोए गए राजस्व से लेकर नियामक दंड, उल्लंघन-सूचना लागत, और उस प्रतिष्ठा-हानि तक फैला होता है जो आउटेज से भी अधिक समय तक बनी रहती है। एक भी अपुनर्प्राप्य रैंसमवेयर घटना कंपनियों का अंत कर चुकी है और, सार्वजनिक क्षेत्र में, आवश्यक नागरिक सेवाओं को हफ़्तों के लिए ऑफ़लाइन कर चुकी है। इसके मुकाबले, एक परीक्षित पुनर्प्राप्ति क्षमता की लागत मामूली और जानने योग्य है।

टोटल कॉस्ट ऑफ़ ओनरशिप (TCO) वास्तविक और निरंतर है: स्टैंडबाय इन्फ्रास्ट्रक्चर, रेप्लिकेशन बैंडविड्थ, बैकअप स्टोरेज (अपरिवर्तनीय और ऑफ़लाइन प्रतियों से गुणा), और ऑटोमेशन बनाने तथा ड्रिल चलाने में लगने वाला इंजीनियरिंग समय। यही ठीक वह कारण है कि आप हर जगह एक्टिव-एक्टिव खरीदने के बजाय RTO और RPO के अनुसार टियर करते हैं, ताकि खर्च एक व्यापक नीति के बजाय हर सिस्टम के मूल्य को ट्रैक करे। नेतृत्व के सामने पक्ष रखने के लिए, योजना को उनकी भाषा में अनुवादित करें: यह है वह डाउनटाइम और डेटा हानि जिसे हम आज सहन कर सकते हैं, यह है हमारे लक्ष्यों तक का अंतर, यह है इसे बंद करने की लागत, और यह है वह जोखिम जो हम नहीं करने पर उठाते हैं। सबसे प्रेरक कलाकृति एक मापी गई ड्रिल है, क्योंकि जो पुनर्प्राप्ति आपने प्रदर्शित की है वह एक ऐसी संख्या है जिस पर नेतृत्व भरोसा कर सकता है, और एक अपरीक्षित योजना एक परिसंपत्ति के भेष में एक देनदारी है।

एंटी-पैटर्न और नुकसान

• अपरीक्षित बैकअप। एक रीस्टोर जो आपने कभी नहीं किया वह एक उम्मीद है; ड्रिल वह जगह है जहाँ आप भ्रष्टाचार, गुम कुंजी, और गलत वॉल्यूम पाते हैं।
• प्रोडक्शन से पहुँच योग्य बैकअप। यदि रैंसमवेयर आपके बैकअप को एन्क्रिप्ट या हटा सकता है, तो आपके पास एक प्रति है, तीन नहीं। एक को अपरिवर्तनीय और ऑफ़लाइन रखें।
• हर चीज़ के लिए एक RTO और RPO। व्यापक टियर तुच्छ को अधिक-सुरक्षित और महत्वपूर्ण को कम-सुरक्षित करते हैं; एक व्यावसायिक प्रभाव विश्लेषण से टियर करें।
• DR को BCP के साथ भ्रमित करना। हर सर्वर को पुनर्स्थापित करना जबकि किसी को नहीं पता कि आपदा कौन घोषित करता है या स्टाफ़ तक कैसे पहुँचा जाए, एक पुनर्प्राप्त सिस्टम और एक विफल व्यवसाय है।
• हाथ से बनाए गए पुनर्प्राप्ति वातावरण। इन्फ्रास्ट्रक्चर जिसे आप कोड से पुनर्निर्मित नहीं कर सकते वह भटक जाता है, और यह भटकाव फेलओवर के बीच में खोजा जाता है।
• अनदेखी की गई निर्भरताएँ। किसी ऐप को उसके डेटाबेस, पहचान प्रोवाइडर, या DNS से पहले पुनर्प्राप्त करना केवल एक दूसरा आउटेज उत्पन्न करता है।
• योजना का सड़ना। एक बार लिखा गया और कभी अभ्यास न किया गया बाइंडर एक ऐसे सिस्टम का वर्णन करता है जो अब मौजूद नहीं है।
• आपूर्तिकर्ता अंधे धब्बे। आपकी पुनर्प्राप्ति आपके महत्वपूर्ण आपूर्तिकर्ताओं की पुनर्प्राप्ति से सीमित होती है, और सांद्रण जोखिम तब तक अदृश्य रहता है जब तक वे एक साथ विफल नहीं होते।

परिपक्वता मॉडल

• लेवल 1, प्रारंभ (Initiate): पुनर्प्राप्ति तदर्थ और प्रतिक्रियात्मक है। बैकअप चल सकते हैं लेकिन रीस्टोर अपरीक्षित हैं। कोई सहमत RTO या RPO नहीं है, कोई व्यावसायिक प्रभाव विश्लेषण नहीं है, और पुनर्प्राप्ति घटना के दौरान सुधारी जाती है। एक गंभीर डेटा हानि या रैंसमवेयर घटना संभवतः अपुनर्प्राप्य होगी।
• लेवल 2, विकास (Develop): बुनियादी प्रथाएँ मौजूद हैं लेकिन वे टीमों में असंगत हैं। कुछ महत्वपूर्ण सिस्टम में 3-2-1 नियम का पालन करने वाले बैकअप और सबसे महत्वपूर्ण सेवाओं के लिए दस्तावेज़ीकृत RTO और RPO हैं, और एक बुनियादी DR योजना मौजूद है जिसके रीस्टोर कभी-कभी परीक्षित किए जाते हैं। कवरेज आंशिक है, निर्भरताएँ मैप नहीं की गई हैं, ड्रिल तदर्थ हैं, और एक टीम का अनुशासन अगली टीम का संकेत नहीं देता।
• लेवल 3, मानकीकरण (Standardize): पुनर्प्राप्ति प्रथा पूरे संगठन में दस्तावेज़ीकृत और लागू है। एक व्यावसायिक प्रभाव विश्लेषण सिस्टम में टियर किए गए RTO और RPO चलाता है, पुनर्प्राप्ति रणनीतियों को उन टियर से मिलाया जाता है, वातावरण इन्फ्रास्ट्रक्चर एज़ कोड हैं, निर्भरताओं और पुनर्प्राप्ति क्रम को मैप किया गया है, और निर्धारित ड्रिल (टेबलटॉप, गेम डे, और फेलओवर) एक परिभाषित लय पर चलते हैं। अपरिवर्तनीय, ऑफ़लाइन प्रतियों वाली एक साइबर-पुनर्प्राप्ति योजना दस्तावेज़ीकृत है और व्यक्तिगत टीमों पर छोड़े जाने के बजाय संगत रूप से लागू की जाती है।
• लेवल 4, प्रबंधन (Manage): पुनर्प्राप्ति को बेसलाइन के विरुद्ध मापा और नियंत्रित किया जाता है। हर ड्रिल प्राप्त वास्तविक RTO और RPO को दर्ज करती है और लक्ष्य तक के अंतर को ट्रैक करती है, और रीस्टोर सफलता दर, पिछले वर्ष में आरंभ से अंत तक पुनर्प्राप्त किए गए महत्वपूर्ण सिस्टम का अनुपात, बैकअप कवरेज और अपरिवर्तनीयता, और वास्तविक RPO के रूप में निगरानी किया गया रेप्लिकेशन लैग जैसे मीट्रिक्स डैशबोर्ड पर रिपोर्ट किए जाते हैं। विचलन कार्रवाई को ट्रिगर करते हैं, टियरिंग को इस बारे में डेटा से फिर से निकाला जाता है कि सिस्टम वास्तव में कैसे उपयोग किए जाते हैं, और गो या नो-गो निर्णय स्लाइड पर लिखी संख्याओं के बजाय प्रमाण पर आधारित होते हैं।
• लेवल 5, ऑर्केस्ट्रेशन (Orchestrate): पुनर्प्राप्ति में निरंतर सुधार होता है, यह पूरे संगठन में एकीकृत है, और अनुकूलनीय है। फेलओवर और साइबर-पुनर्प्राप्ति क्लीन-रूम रीस्टोर को नियमित रूप से रिहर्स किया जाता है, आपूर्तिकर्ता और सांद्रण जोखिम को सक्रिय रूप से प्रबंधित किया जाता है, और निरंतरता को विश्वसनीयता (अध्याय 9.1) और घटना प्रतिक्रिया (अध्याय 9.3) के साथ एकीकृत किया जाता है ताकि संगठन उन विफलताओं से भी अनुमानित रूप से उबर सके जो उसने पहले कभी नहीं देखीं और जैसे-जैसे सिस्टम परिदृश्य और खतरे की तस्वीर बदलती है, अपनी पुनर्प्राप्ति स्थिति को फिर से परिभाषित करता रहे।

चर्चा के लिए विचार

1. आपके कौन-से महत्वपूर्ण सिस्टम को कभी भी आरंभ से अंत तक पुनर्स्थापित नहीं किया गया है, और यह साबित करने के लिए क्या करना होगा कि यह किया जा सकता है?
2. यदि आप अपना प्राथमिक क्लाउड क्षेत्र पूरे दिन के लिए खो देते हैं, तो कौन-सी व्यावसायिक प्रक्रियाएँ रुक जाएँगी, और आप किस क्रम में सिस्टम को वापस लाएँगे?
3. आपकी पुनर्प्राप्ति का कितना हिस्सा उन आपूर्तिकर्ताओं पर निर्भर करता है जिनकी अपनी पुनर्प्राप्ति आप देख या टेस्ट नहीं कर सकते?
4. आप किन जगहों पर एक ऐसे पुनर्प्राप्ति टियर के लिए भुगतान कर रहे हैं जिसे व्यावसायिक प्रभाव विश्लेषण उचित नहीं ठहराता, और आप कहाँ कम-सुरक्षा दे रहे हैं?
5. यदि आज रात आपके बैकअप पहुँच योग्य और एन्क्रिप्टेड होते, तो आपका वास्तविक अंतिम ज्ञात-स्वच्छ रीस्टोर बिंदु क्या है?
6. आपके वादा किए गए RTO और RPO तथा आपकी पिछली ड्रिल में वास्तव में प्राप्त किए गए RTO और RPO के बीच ईमानदार अंतर क्या है?

मुख्य निष्कर्ष

• निरंतरता लक्ष्य है; पुनर्प्राप्ति एक साधन है। बिज़नेस कॉन्टिन्युइटी प्लानिंग संगठन को चालू रखती है; डिज़ास्टर रिकवरी उस IT सिस्टम को पुनर्स्थापित करती है जिस पर यह निर्भर करती है।
• RTO और RPO सब कुछ तय करते हैं, और दोनों एक व्यावसायिक प्रभाव विश्लेषण से आते हैं, न कि इंजीनियरिंग के अनुमान से। सभी को समान रूप से सुरक्षित करने के बजाय सिस्टम को टियर करें।
• एक अपरीक्षित बैकअप बैकअप नहीं है। 3-2-1 नियम का पालन करें, रैंसमवेयर के विरुद्ध कम से कम एक अपरिवर्तनीय और ऑफ़लाइन प्रति रखें, और एक निर्धारित समय-सारणी पर रीस्टोर का परीक्षण करें।
• DR रणनीति को उस संख्या से मिलाएँ: बैकअप-और-रीस्टोर, पायलट लाइट, वार्म स्टैंडबाय, या एक्टिव-एक्टिव, जिसे हर सिस्टम के RTO और RPO से चुना जाए।
• रेप्लिकेशन कॉन्सिस्टेंसी को ताज़गी के लिए त्यागता है (अध्याय 3.3); आपका वास्तविक RPO आपका रेप्लिकेशन लैग है, न कि आपका डिज़ाइन दस्तावेज़।
• कोड से पुनर्निर्माण करें इन्फ्रास्ट्रक्चर एज़ कोड (अध्याय 8.2) के साथ, और अपनी निर्भरताओं की ज़रूरत पड़ने से पहले उन्हें मैप करें।
• टेबलटॉप एक्सरसाइज़, गेम डे, और पूर्ण फेलओवर ड्रिल से टेस्ट करें, और लक्षित RTO और RPO की तुलना में वास्तविक को मापें।
• साइबर-पुनर्प्राप्ति की अलग से योजना बनाएँ क्लीन-रूम रीस्टोर के साथ, और पूरी प्रथा को विश्वसनीयता (अध्याय 9.1), घटना प्रतिक्रिया (अध्याय 9.3), और अनुपालन (अध्याय 4.6) से जोड़ें।

संदर्भ और आगे पढ़ने के लिए

• ISO 22301, Security and resilience: Business continuity management systems: Requirements (BCP के लिए अंतरराष्ट्रीय मानक)।
• National Institute of Standards and Technology, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (सरकारी सिस्टम के लिए RTO, RPO, और पुनर्प्राप्ति रणनीतियाँ)।
• National Institute of Standards and Technology, SP 800-61 Rev. 2: Computer Security Incident Handling Guide (घटना और साइबर-पुनर्प्राप्ति प्रबंधन)।
• U.S. Federal Emergency Management Agency, Continuity Guidance Circular और फ़ेडरल COOP मार्गदर्शन (आवश्यक कार्य और कॉन्टिन्युइटी ऑफ़ ऑपरेशंस)।
• Federal Financial Institutions Examination Council (FFIEC), Business Continuity Management बुकलेट (वित्तीय संस्थानों के लिए नियामक पुनर्प्राप्ति अपेक्षाएँ)।
• Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, eds., Site Reliability Engineering: How Google Runs Production Systems (विश्वसनीयता और आपदा परीक्षण)।
• Kelly Shortridge and Aaron Rinehart, Security Chaos Engineering (जानबूझकर विफलता और पुनर्प्राप्ति का अभ्यास करना)।
• Cybersecurity and Infrastructure Security Agency (CISA), #StopRansomware Guide (रैंसमवेयर रोकथाम और पुनर्प्राप्ति प्रथा)।