पूर आला तरी, 1C चालला पाहिजे! आम्ही DR वरील व्यवसायाशी सहमत आहोत

कल्पना करा: तुम्ही एका मोठ्या शॉपिंग सेंटरच्या आयटी इन्फ्रास्ट्रक्चरची सेवा करत आहात. शहरात पावसाला सुरुवात झाली. पावसाच्या धारा छत फुटतात, किरकोळ आवारात घोटभर पाणी तुंबते. आम्ही आशा करतो की तुमची सर्व्हर रूम तळघरात नाही, अन्यथा समस्या टाळता येणार नाहीत.  

वर्णन केलेली कथा ही कल्पनारम्य नाही तर २०२० च्या काही घटनांचे एकत्रित वर्णन आहे. मोठ्या कंपन्यांमध्ये, आपत्ती पुनर्प्राप्ती योजना, किंवा आपत्ती पुनर्प्राप्ती योजना (DRP), या प्रकरणात नेहमीच हाताशी असते. कॉर्पोरेशनमध्ये, ही व्यवसाय निरंतरता तज्ञांची जबाबदारी आहे. परंतु मध्यम आणि लहान कंपन्यांमध्ये अशा समस्या सोडवणे आयटी सेवांवर येते. तुम्हाला व्यवसायाचे तर्कशास्त्र स्वतः समजून घेणे आवश्यक आहे, काय अयशस्वी होऊ शकते हे समजून घेणे आणि कुठे, संरक्षणासह येणे आणि ते अंमलात आणणे आवश्यक आहे. 

जर आयटी तज्ञ व्यवसायाशी वाटाघाटी करू शकतील आणि संरक्षणाच्या गरजेबद्दल चर्चा करू शकतील तर ते चांगले आहे. परंतु मी एकापेक्षा जास्त वेळा पाहिले आहे की एखाद्या कंपनीने डिझास्टर रिकव्हरी (DR) सोल्यूशनमध्ये कसे दुर्लक्ष केले कारण ते निरर्थक आहे. जेव्हा एखादी दुर्घटना घडली तेव्हा, दीर्घ पुनर्प्राप्तीमुळे नुकसान होण्याची भीती होती आणि व्यवसाय तयार नव्हता. आपण आपल्या आवडीनुसार पुनरावृत्ती करू शकता: "मी तुम्हाला तसे सांगितले आहे," परंतु आयटी सेवेला सेवा पुनर्संचयित करावी लागतील.

आर्किटेक्टच्या पदावरून, मी तुम्हाला ही परिस्थिती कशी टाळायची ते सांगेन. लेखाच्या पहिल्या भागात, मी तयारीचे काम दर्शवेल: सुरक्षा साधने निवडण्यासाठी ग्राहकांशी तीन प्रश्नांची चर्चा कशी करावी: 

• आम्ही कशाचे रक्षण करत आहोत?
• आपण कशापासून संरक्षण करत आहोत?
• आम्ही किती संरक्षण करतो? 

दुसऱ्या भागात, आम्ही प्रश्नाचे उत्तर देण्याच्या पर्यायांबद्दल बोलू: स्वतःचा बचाव कसा करायचा. भिन्न ग्राहक त्यांचे संरक्षण कसे तयार करतात याची उदाहरणे मी देईन.

आम्ही काय संरक्षित करतो: महत्त्वपूर्ण व्यवसाय कार्ये ओळखणे 

आणीबाणीनंतरच्या कृती आराखड्याबद्दल व्यावसायिक ग्राहकांशी चर्चा करून तयारी सुरू करणे चांगले. येथे मुख्य अडचण एक सामान्य भाषा शोधणे आहे. आयटी सोल्यूशन कसे कार्य करते याकडे ग्राहक सहसा लक्ष देत नाही. सेवा व्यावसायिक कार्ये करू शकते आणि पैसे मिळवू शकते की नाही याची त्याला काळजी आहे. उदाहरणार्थ: साइट कार्यरत असल्यास, परंतु पेमेंट सिस्टम डाउन असल्यास, क्लायंटकडून कोणतेही उत्पन्न मिळत नाही आणि "अत्यंतवादी" अजूनही आयटी विशेषज्ञ आहेत. 

आयटी व्यावसायिकांना अनेक कारणांमुळे अशा वाटाघाटींमध्ये अडचण येऊ शकते:

• IT सेवा व्यवसायातील माहिती प्रणालीची भूमिका पूर्णपणे समजत नाही. उदाहरणार्थ, व्यवसाय प्रक्रिया किंवा पारदर्शक व्यवसाय मॉडेलचे कोणतेही वर्णन उपलब्ध नसल्यास. 
• संपूर्ण प्रक्रिया आयटी सेवेवर अवलंबून नाही. उदाहरणार्थ, जेव्हा कामाचा काही भाग कंत्राटदारांद्वारे केला जातो आणि आयटी तज्ञांचा त्यांच्यावर थेट प्रभाव पडत नाही.

मी या संभाषणाची रचना करेन: 

1. आम्‍ही व्‍यवसायांना समजावून सांगतो की अपघात प्रत्येकालाच होतात आणि पुनर्प्राप्तीसाठी वेळ लागतो. सर्वात चांगली गोष्ट म्हणजे परिस्थिती दर्शवणे, हे कसे घडते आणि कोणते परिणाम शक्य आहेत.
2. आम्ही दाखवतो की सर्व काही IT सेवेवर अवलंबून नाही, परंतु तुम्ही तुमच्या जबाबदारीच्या क्षेत्रातील कृती योजनेत मदत करण्यास तयार आहात.
3. आम्ही व्यावसायिक ग्राहकाला उत्तर देण्यास विचारतो: जर सर्वनाश झाला, तर कोणती प्रक्रिया प्रथम पुनर्संचयित केली जावी? त्यात कोण आणि कसा सहभागी होतो? 

   व्यवसायाकडून एक साधे उत्तर आवश्यक आहे, उदाहरणार्थ: कॉल सेंटरला २४/७ अर्जांची नोंदणी करणे आवश्यक आहे.

4. आम्ही सिस्टमच्या एक किंवा दोन वापरकर्त्यांना या प्रक्रियेचे तपशीलवार वर्णन करण्यास सांगतो. 
   तुमच्‍या कंपनीकडे विश्‍लेषकाचा समावेश असल्‍यास मदत करण्‍यासाठी अधिक चांगले.

   सुरुवातीला, वर्णन असे दिसू शकते: कॉल सेंटरला फोनद्वारे, मेलद्वारे आणि वेबसाइटवरील संदेशांद्वारे विनंत्या प्राप्त होतात. मग तो वेब इंटरफेसद्वारे त्यांना 1C मध्ये प्रवेश करतो आणि उत्पादन तेथून अशा प्रकारे घेऊन जाते.

5. मग आम्ही कोणत्या हार्डवेअर आणि सॉफ्टवेअर सोल्यूशन्स प्रक्रियेस समर्थन देतात ते पाहू. सर्वसमावेशक संरक्षणासाठी, आम्ही तीन स्तर विचारात घेतो: 
   • साइटमधील अनुप्रयोग आणि प्रणाली (सॉफ्टवेअर स्तर),   
   • साइट स्वतः जिथे सिस्टम चालतात (पायाभूत सुविधा स्तर), 
   • नेटवर्क (ते अनेकदा त्याबद्दल विसरतात).

6. आम्ही अपयशाचे संभाव्य मुद्दे शोधतो: सिस्टम नोड्स ज्यावर सेवेचे कार्यप्रदर्शन अवलंबून असते. आम्ही इतर कंपन्यांद्वारे समर्थित नोड्स स्वतंत्रपणे लक्षात ठेवतो: दूरसंचार ऑपरेटर, होस्टिंग प्रदाते, डेटा केंद्रे इ. यासह, आपण पुढील चरणासाठी व्यावसायिक ग्राहकाकडे परत येऊ शकता.

आम्ही कशापासून संरक्षण करतो: जोखीम

पुढे, आम्ही व्यावसायिक ग्राहकाकडून प्रथम कोणत्या जोखमीपासून स्वतःचे संरक्षण करतो हे शोधून काढतो. सर्व जोखीम दोन गटांमध्ये विभागली जाऊ शकतात: 

• सेवा डाउनटाइममुळे वेळेचे नुकसान;
• भौतिक प्रभाव, मानवी घटक इत्यादींमुळे डेटाचे नुकसान.

व्यवसायांना डेटा आणि वेळ दोन्ही गमावण्याची भीती वाटते - या सर्वांमुळे पैशाचे नुकसान होते. म्हणून आम्ही पुन्हा प्रत्येक जोखीम गटासाठी प्रश्न विचारतो: 

• या प्रक्रियेसाठी, आम्ही अंदाज लावू शकतो की डेटा गमावणे आणि वेळेचे नुकसान किती पैसे खर्च करते? 
• आम्ही कोणता डेटा गमावू शकत नाही? 
• आम्ही कुठे डाउनटाइमला परवानगी देऊ शकत नाही? 
• कोणत्या घटना आपल्यासाठी बहुधा आणि सर्वात धोकादायक आहेत?

चर्चेनंतर, अपयशाच्या मुद्यांना प्राधान्य कसे द्यावे हे आपण समजू. 

आम्ही किती संरक्षण करतो: RPO आणि RTO 

जेव्हा अपयशाचे गंभीर मुद्दे स्पष्ट असतात, तेव्हा आम्ही RTO आणि RPO निर्देशकांची गणना करतो. 

मी तुम्हाला याची आठवण करून देतो आरटीओ (पुनर्प्राप्ती वेळेचे उद्दिष्ट) - अपघाताच्या क्षणापासून सेवा पूर्णपणे पुनर्संचयित होईपर्यंत हा स्वीकार्य वेळ आहे. व्यावसायिक भाषेत, हे स्वीकार्य डाउनटाइम आहे. प्रक्रियेत किती पैसे आले हे आम्हाला माहित असल्यास, आम्ही डाउनटाइमच्या प्रत्येक मिनिटापासून झालेल्या नुकसानाची गणना करू शकतो आणि स्वीकार्य नुकसानाची गणना करू शकतो. 

RPO (रिकव्हरी पॉइंट उद्दिष्ट) - वैध डेटा पुनर्प्राप्ती बिंदू. आम्ही डेटा गमावू शकतो ते वेळ निर्धारित करते. व्यवसायाच्या दृष्टिकोनातून, डेटा गमावल्यास दंड होऊ शकतो, उदाहरणार्थ. अशा नुकसानाचे रूपांतर पैशातही होऊ शकते. 

अंतिम वापरकर्त्यासाठी पुनर्प्राप्ती वेळेची गणना करणे आवश्यक आहे: तो किती काळ सिस्टममध्ये लॉग इन करण्यास सक्षम असेल. म्हणून प्रथम आम्ही साखळीतील सर्व लिंक्सची पुनर्प्राप्ती वेळ जोडतो. येथे अनेकदा चूक केली जाते: ते SLA कडून प्रदात्याचा RTO घेतात आणि उर्वरित अटी विसरतात.

चला एक विशिष्ट उदाहरण पाहू. वापरकर्ता 1C मध्ये लॉग इन करतो, सिस्टम डेटाबेस त्रुटीसह उघडते. तो सिस्टम प्रशासकाशी संपर्क साधतो. डेटाबेस क्लाउडमध्ये स्थित आहे, सिस्टम प्रशासक सेवा प्रदात्यास समस्येचा अहवाल देतो. समजा सर्व संप्रेषणांना १५ मिनिटे लागतात. क्लाउडमध्ये, या आकाराचा डेटाबेस एका तासात बॅकअपमधून पुनर्संचयित केला जाईल, म्हणून, सेवा प्रदात्याच्या बाजूने आरटीओ एक तास आहे. परंतु ही अंतिम मुदत नाही; वापरकर्त्यासाठी, समस्या शोधण्यासाठी त्यात 15 मिनिटे जोडण्यात आली आहेत. 
 
पुढे, सिस्टम प्रशासकाला डेटाबेस बरोबर असल्याचे तपासणे आवश्यक आहे, ते 1C शी कनेक्ट करा आणि सेवा सुरू करा. यासाठी आणखी एक तास लागतो, याचा अर्थ प्रशासकाच्या बाजूने आरटीओ आधीच 2 तास 15 मिनिटे आहे. वापरकर्त्याला आणखी 15 मिनिटांची आवश्यकता आहे: लॉग इन करा, आवश्यक व्यवहार दिसून आले आहेत का ते तपासा. या उदाहरणातील एकूण सेवा पुनर्प्राप्ती वेळ 2 तास 30 मिनिटे आहे.

पुनर्प्राप्ती कालावधी कोणत्या बाह्य घटकांवर अवलंबून आहे यावर ही गणना व्यवसाय दर्शवेल. उदाहरणार्थ, जर कार्यालयात पूर आला असेल, तर आपल्याला प्रथम गळती शोधून त्याचे निराकरण करण्याची आवश्यकता आहे. यास वेळ लागेल, जो आयटीवर अवलंबून नाही.  

आम्ही संरक्षण कसे करतो: विविध जोखमींसाठी साधने निवडणे

सर्व मुद्यांवर चर्चा केल्यानंतर, ग्राहकाला आधीच व्यवसायासाठी अपघाताची किंमत समजते. आता तुम्ही साधने निवडू शकता आणि बजेटवर चर्चा करू शकता. क्लायंट केसेसची उदाहरणे वापरून, मी तुम्हाला दाखवेन की आम्ही वेगवेगळ्या कामांसाठी कोणती साधने ऑफर करतो. 

चला जोखमीच्या पहिल्या गटापासून सुरुवात करूया: सेवा डाउनटाइममुळे होणारे नुकसान. या समस्येचे निराकरण करण्यासाठी चांगले आरटीओ प्रदान केले पाहिजे.

1. क्लाउडमध्ये अनुप्रयोग होस्ट करा 

   सुरुवातीला, आपण फक्त क्लाउडवर जाऊ शकता - प्रदात्याने आधीच उच्च उपलब्धतेच्या मुद्द्यांचा विचार केला आहे. वर्च्युअलायझेशन होस्ट एका क्लस्टरमध्ये एकत्र केले जातात, पॉवर आणि नेटवर्क आरक्षित केले जातात, डेटा फॉल्ट-सहिष्णु स्टोरेज सिस्टमवर संग्रहित केला जातो आणि सेवा प्रदाता डाउनटाइमसाठी आर्थिकदृष्ट्या जबाबदार असतो.

   उदाहरणार्थ, तुम्ही क्लाउडमध्ये डेटाबेससह व्हर्च्युअल मशीन होस्ट करू शकता. अनुप्रयोग डेटाबेसशी बाह्यरित्या स्थापित चॅनेलद्वारे किंवा त्याच क्लाउडवरून कनेक्ट होईल. क्लस्टरमधील एका सर्व्हरमध्ये समस्या उद्भवल्यास, VM शेजारच्या सर्व्हरवर 2 मिनिटांपेक्षा कमी वेळात रीस्टार्ट होईल. त्यानंतर, त्यात DBMS सुरू होईल आणि काही मिनिटांत डेटाबेस उपलब्ध होईल.

   आरटीओ: मिनिटांत मोजले. या अटी प्रदात्यासह करारामध्ये निर्दिष्ट केल्या जाऊ शकतात.
   खर्च: आम्ही तुमच्या अर्जासाठी क्लाउड संसाधनांची किंमत मोजतो. 
   ज्यापासून ते तुमचे संरक्षण करणार नाही: प्रदात्याच्या साइटवर मोठ्या प्रमाणात अपयश, उदाहरणार्थ, शहर स्तरावरील अपघातांमुळे.

2. अनुप्रयोग क्लस्टर करा  

   तुम्हाला RTO सुधारायचे असल्यास, तुम्ही मागील पर्याय मजबूत करू शकता आणि क्लाउडमध्ये क्लस्टर केलेले अॅप्लिकेशन ताबडतोब ठेवू शकता.

   तुम्ही सक्रिय-निष्क्रिय किंवा सक्रिय-सक्रिय मोडमध्ये क्लस्टर लागू करू शकता. आम्ही विक्रेत्याच्या आवश्यकतांवर आधारित अनेक VM तयार करतो. अधिक विश्वासार्हतेसाठी, आम्ही त्यांना वेगवेगळ्या सर्व्हर आणि स्टोरेज सिस्टमवर वितरित करतो. डेटाबेसपैकी एकासह सर्व्हर अयशस्वी झाल्यास, बॅकअप नोड काही सेकंदात लोड घेते.

   आरटीओ: सेकंदात मोजले.
   खर्च: नियमित क्लाउडपेक्षा किंचित जास्त महाग, क्लस्टरिंगसाठी अतिरिक्त संसाधने आवश्यक असतील.
   ज्यापासून ते तुमचे संरक्षण करणार नाही: तरीही मोठ्या प्रमाणावर ऑन-साइट अपयशांपासून संरक्षण करणार नाही. पण स्थानिक व्यत्यय फार काळ टिकणार नाही.

   सरावातून: रिटेल कंपनीकडे अनेक माहिती प्रणाली आणि वेबसाइट्स होत्या. सर्व डेटाबेस कंपनीच्या कार्यालयात स्थानिक पातळीवर स्थित होते. सलग अनेकवेळा कार्यालयात वीज नसल्याशिवाय डीआरचा विचार झाला नाही. वेबसाइट क्रॅश झाल्यामुळे ग्राहक नाखूष होते. 
    
   क्लाउडवर गेल्यानंतर सेवा उपलब्धतेची समस्या सोडवली गेली. शिवाय, आम्ही नोड्स दरम्यान रहदारी संतुलित करून डेटाबेसवरील लोड ऑप्टिमाइझ करण्यात व्यवस्थापित केले.

3. आपत्ती-पुरावा ढगावर जा

   मुख्य साइटवरील नैसर्गिक आपत्ती देखील तुमच्या कामात व्यत्यय आणत नाही याची तुम्हाला खात्री करायची असल्यास, तुम्ही आपत्ती-प्रतिरोधक क्लाउड निवडू शकता. या पर्यायामध्ये, प्रदाता वर्च्युअलायझेशन क्लस्टरला 2 डेटा केंद्रांमध्ये पसरवतो. डेटा सेंटर्समध्ये एक-एक करून, सतत सिंक्रोनस प्रतिकृती उद्भवते. डेटा केंद्रांमधील चॅनेल आरक्षित आहेत आणि वेगवेगळ्या मार्गांवर जातात, म्हणून अशा क्लस्टरला नेटवर्क समस्यांपासून भीती वाटत नाही. 

   आरटीओ: 0 कडे झुकते.
   खर्च: सर्वात महाग क्लाउड पर्याय. 
   ज्यापासून ते तुमचे संरक्षण करणार नाही: हे डेटा भ्रष्टाचार, तसेच मानवी घटकांपासून मदत करणार नाही, म्हणून एकाच वेळी बॅकअप घेण्याची शिफारस केली जाते. 

   सरावातून: आमच्या ग्राहकांपैकी एकाने सर्वसमावेशक आपत्ती पुनर्प्राप्ती योजना विकसित केली आहे. त्याने निवडलेली ही रणनीती आहे: 

   • आपत्ती-सहिष्णु मेघ पायाभूत सुविधा स्तरावरील अपयशांपासून अनुप्रयोगाचे संरक्षण करतो. 
   • दोन-स्तरीय बॅकअप मानवी त्रुटीच्या बाबतीत संरक्षण प्रदान करते. बॅकअपचे दोन प्रकार आहेत: "थंड" आणि "गरम". "कोल्ड" बॅकअप अक्षम स्थितीत आहे आणि तैनात होण्यास वेळ लागतो. एक "हॉट" बॅकअप वापरासाठी आधीच तयार आहे आणि जलद पुनर्संचयित केला जातो. हे विशेष समर्पित स्टोरेज सिस्टमवर साठवले जाते. तिसरी प्रत टेपवर रेकॉर्ड केली जाते आणि दुसर्या खोलीत ठेवली जाते. 

   आठवड्यातून एकदा, क्लायंट संरक्षणाची चाचणी करतो आणि टेपसह सर्व बॅकअपची कार्यक्षमता तपासतो. दरवर्षी कंपनी संपूर्ण आपत्ती-प्रतिरोधक क्लाउडची चाचणी करते. 

4. दुसर्‍या साइटवर प्रतिकृती आयोजित करा 

   मुख्य साइटवर जागतिक समस्या कशा टाळायच्या यावरील दुसरा पर्याय: भौगोलिक-आरक्षण प्रदान करा. दुसऱ्या शब्दांत, दुसऱ्या शहरातील साइटवर बॅकअप व्हर्च्युअल मशीन तयार करा. DR साठी विशेष उपाय यासाठी योग्य आहेत: आमच्या कंपनीमध्ये आम्ही VMware vCloud Availability (vCAV) वापरतो. त्याच्या मदतीने, तुम्ही अनेक क्लाउड प्रदाता साइट्स दरम्यान संरक्षण कॉन्फिगर करू शकता किंवा ऑन-प्रिमाइस साइटवरून क्लाउडवर पुनर्संचयित करू शकता. मी आधीच vCAV सह काम करण्याच्या योजनेबद्दल अधिक तपशीलवार बोललो आहे येथे. 

   RPO आणि RTO: 5 मिनिटांपासून. 

   खर्च: पहिल्या पर्यायापेक्षा अधिक महाग, परंतु आपत्ती-पुरावा क्लाउडमध्ये हार्डवेअर प्रतिकृतीपेक्षा स्वस्त. किंमतीमध्ये vCAV परवान्याची किंमत, प्रशासन शुल्क, क्लाउड संसाधनांची किंमत आणि PAYG मॉडेलनुसार राखीव संसाधने (स्विच ऑफ केलेल्या VM साठी कार्यरत संसाधनांच्या किंमतीच्या 10%) असतात.

   सरावातून: क्लायंटने मॉस्कोमधील आमच्या क्लाउडमध्ये वेगवेगळ्या डेटाबेससह 6 आभासी मशीन ठेवल्या. सुरुवातीला, बॅकअपद्वारे संरक्षण प्रदान केले गेले: काही बॅकअप प्रती मॉस्कोमधील क्लाउडमध्ये संग्रहित केल्या गेल्या आणि काही आमच्या सेंट पीटर्सबर्ग साइटवर संग्रहित केल्या गेल्या. कालांतराने, डेटाबेस आकारात वाढला आणि बॅकअपमधून पुनर्संचयित करण्यास अधिक वेळ लागला. 
    
   VMware vCloud उपलब्धतेवर आधारित प्रतिकृती बॅकअपमध्ये जोडली गेली. व्हर्च्युअल मशीन्सच्या प्रतिकृती सेंट पीटर्सबर्गमधील बॅकअप साइटवर संग्रहित केल्या जातात आणि दर 5 मिनिटांनी अद्यतनित केल्या जातात. मुख्य साइटवर बिघाड झाल्यास, कर्मचारी स्वतंत्रपणे सेंट पीटर्सबर्गमधील व्हर्च्युअल मशीनच्या प्रतिकृतीवर स्विच करतात आणि त्यासह कार्य करणे सुरू ठेवतात. 

विचारात घेतलेले सर्व उपाय उच्च उपलब्धता प्रदान करतात, परंतु रॅन्समवेअर व्हायरसमुळे किंवा कर्मचार्‍यांच्या अपघाती त्रुटीमुळे डेटा गमावण्यापासून संरक्षण करत नाहीत. या प्रकरणात, आम्हाला बॅकअपची आवश्यकता असेल जे आवश्यक RPO प्रदान करतील.

5. बॅकअप बद्दल विसरू नका

प्रत्येकाला माहित आहे की तुमच्याकडे सर्वात छान आपत्ती-पुरावा उपाय असला तरीही तुम्हाला बॅकअप घेणे आवश्यक आहे. म्हणून मी तुम्हाला थोडक्यात काही मुद्द्यांची आठवण करून देतो.

काटेकोरपणे बोलणे, बॅकअप DR नाही. आणि म्हणूनच: 

• बराच वेळ आहे. डेटा टेराबाइटमध्ये मोजला असल्यास, पुनर्प्राप्तीसाठी एक तासापेक्षा जास्त वेळ लागेल. आपल्याला पुनर्संचयित करणे आवश्यक आहे, नेटवर्क नियुक्त करणे, ते चालू आहे हे तपासा, डेटा क्रमाने आहे हे पहा. त्यामुळे थोडासा डेटा असेल तरच तुम्ही चांगला आरटीओ देऊ शकता. 
• डेटा प्रथमच पुनर्संचयित केला जाऊ शकत नाही आणि आपल्याला क्रिया पुनरावृत्ती करण्यासाठी वेळ द्यावा लागेल. उदाहरणार्थ, डेटा केव्हा गमावला हे आपल्याला माहित नसते. समजू की नुकसान 15.00 वाजता लक्षात आले आणि प्रत्येक तासाला प्रती तयार केल्या जातात. 15.00 पासून आम्ही सर्व पुनर्प्राप्ती बिंदू पाहतो: 14:00, 13:00 आणि असेच. प्रणाली महत्वाची असल्यास, आम्ही पुनर्प्राप्ती बिंदूचे वय कमी करण्याचा प्रयत्न करतो. परंतु जर ताज्या बॅकअपमध्ये आवश्यक डेटा नसेल तर आम्ही पुढील बिंदू घेतो - हा अतिरिक्त वेळ आहे. 

या प्रकरणात, बॅकअप शेड्यूल आवश्यक प्रदान करू शकते RPO. बॅकअपसाठी, मुख्य साइटसह समस्या असल्यास भौगोलिक-आरक्षण प्रदान करणे महत्त्वाचे आहे. काही बॅकअप प्रती स्वतंत्रपणे संग्रहित करण्याची शिफारस केली जाते.

अंतिम आपत्ती पुनर्प्राप्ती योजनेत किमान 2 साधने असावीत:  

• 1-4 पर्यायांपैकी एक, जो सिस्टमचे अपयश आणि पडण्यापासून संरक्षण करेल.
• डेटाचे नुकसान होण्यापासून संरक्षण करण्यासाठी बॅकअप. 

मुख्य इंटरनेट प्रदाता कमी झाल्यास बॅकअप संप्रेषण चॅनेलची काळजी घेणे देखील योग्य आहे. आणि - व्हॉइला! - किमान वेतनावरील DR आधीच तयार आहे. 

स्त्रोत: www.habr.com