बैकअप नीतियों के लिए सर्वोत्तम अभ्यास

आज मैं बैकअप और डिजास्टर रिकवरी प्रोसेस के कुछ महत्वपूर्ण सिद्धांतों को छूना चाहता हूं। विशेष रूप से, जैसे मुद्दे:

1. उत्पादक प्रणाली अद्यतन प्रक्रियाओं और इसकी बैकअप प्रक्रिया का परस्पर संबंध
2. बैकअप से परीक्षण पुनर्प्राप्ति
3. एक उत्पादक नेटवर्क के नेटवर्क बुनियादी ढांचे के तत्वों के साथ बैकअप प्रक्रिया की सहभागिता
4. आपदा वसूली का दस्तावेजीकरण

बैकअप

अपने सिस्टम को अपग्रेड करने से पहले वापस जाएं

एप्लिकेशन और ऑपरेटिंग सिस्टम अपडेट स्थापित करने से पहले, नए सॉफ़्टवेयर संस्करणों में अपग्रेड करना, उपकरण अपग्रेड करना और सिस्टम में अन्य महत्वपूर्ण परिवर्तन करना, बैक अप लेने की सलाह दी जाती है, क्योंकि यदि अपडेट विफल हो जाता है और सिस्टम गलत स्थिति में प्रवेश करता है, तो व्यवस्थापक के पास अवसर होगा व्यापार के लिए कम से कम नुकसान ( आरपीओ के संदर्भ में) के साथ वापस परिवर्तन और एक स्थिर स्थिति में लौटें।

निम्नलिखित परिदृश्य मान लें:

1. अनुसूचित बैकअप मंगलवार से बुधवार की रात को होता है
2. बुधवार से पहले, सिस्टम हमेशा की तरह उपयोग किया जाता है
3. बुधवार शाम को, सिस्टम अपडेट किया गया है (सिस्टम सॉफ़्टवेयर का एक नया संस्करण स्थापित है)। चूंकि रिलीज़ नोटों को रिलीज़ नोट्स स्थापित करने से पहले ध्यान से नहीं पढ़ा गया था, इसलिए सिस्टम अस्थिर अवस्था में प्रवेश करता है।
4. मंगलवार को अपने राज्य के समय डेटा हानि के साथ सिस्टम को फिर से इंस्टॉल किया गया है
5. गुरुवार को, उपयोगकर्ताओं को बुधवार के लिए बनाए गए सभी डेटा को फिर से बनाने के लिए मजबूर किया जाता है

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

एक महत्वपूर्ण सिस्टम अपग्रेड के तुरंत बाद एक पूर्ण बैकअप करें

एक उदाहरण:

1. शुक्रवार को एक पूर्ण बैकअप बनाया जाता है, बाकी दिनों में वृद्धिशील बैकअप बनाया जाता है।
2. बुधवार को, डेटाबेस सर्वर को एक नए संस्करण में अपडेट किया गया था, जो ऑपरेटिंग सिस्टम से संबंधित कुछ सामान्य सिस्टम फ़ाइलों के अपडेट के साथ था
3. वृद्धिशील बैकअप गुरुवार की रात को हमेशा की तरह प्राप्त किया गया था
4. गुरुवार की सुबह, एक महत्वपूर्ण खराबी हुई, जो सिस्टम पुनर्प्राप्ति की आवश्यकता थी
5. विफलता की प्रकृति की जांच करने के बाद, प्रशासक यह समझता है कि केवल सिस्टम फाइलें ही क्षतिग्रस्त हैं और सिस्टम के कामकाज को बहाल करने के लिए केवल अंतिम पूर्ण बैकअप का उपयोग करके सिस्टम फ़ाइलों (सिस्टम स्थिति) के बहुत सारे को पुनर्स्थापित करना पर्याप्त होगा। हालाँकि, यदि आप ऐसा करते हैं, तो डेटाबेस सर्वर का अद्यतन संस्करण काम करना बंद कर देगा, क्योंकि इसके लिए सिस्टम फ़ाइलों के नए संस्करणों (उदाहरण के लिए, .NET फ्रेमवर्क का नवीनतम संस्करण) की आवश्यकता होती है, जो इसके साथ इंस्टॉल किए गए थे। यह आवश्यक वृद्धिशील प्रतियों को देखकर पुनर्प्राप्ति प्रक्रिया को जारी रखने के लिए आवश्यक बनाता है जिसमें सिस्टम स्थिति में परिवर्तन होते हैं। यह अंततः SLA के उल्लंघन तक पुनर्प्राप्ति प्रक्रिया की जटिलता और RTO समय में वृद्धि की ओर जाता है।

सामान्य अनुशंसा निम्नानुसार तैयार की जा सकती है: यदि वृद्धिशील बैकअप की संचयी मात्रा एक पूर्ण बैकअप की मात्रा से अधिक है, तो एक अनिर्धारित पूर्ण बैकअप बनाने के लिए तर्कसंगत है।

सिस्टम पुनर्प्राप्ति के बाद एक पूर्ण बैकअप IMMEDIATELY करें

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

"एक पत्थर से दो पक्षियों का पीछा मत करो" या "आधुनिकीकरण बुराई है"

आपको विफलताओं के बाद सिस्टम पुनर्प्राप्ति की प्रक्रिया और इसके आधुनिकीकरण की प्रक्रिया को संयोजित नहीं करना चाहिए। इस तथ्य के बावजूद कि यह स्पष्ट प्रतीत हो सकता है, सिस्टम के निरंतर उत्पादन संचालन के दौरान तकनीकी प्रक्रियाओं के लिए समय की कमी, साथ ही साथ (यहां तक ​​कि आवश्यक) परिवर्तन करने की अनिच्छा "सामान्य रूप से काम कर रही है", सिस्टम डाउनटाइम के क्षण का उपयोग करने की इच्छा हो सकती है। आधुनिकीकरण करने में विफलता के दौरान, इसलिए "एक के लिए" बोलना।

आइए इस बारे में कुछ उदाहरण देखें:

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

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

सब कुछ के बारे में थोड़ा

एक बैकअप स्थापित करने से पहले प्रलेखन पढ़ें

अनुप्रयोगों का बैकअप लेने और पुनर्स्थापित करने की प्रक्रिया में विभिन्न बारीकियां हो सकती हैं जिन्हें ध्यान में रखा जाना चाहिए और जो हमेशा स्पष्ट नहीं होती हैं। इन बारीकियों को आमतौर पर केवल आवेदन प्रलेखन से सीखा जा सकता है, हालांकि, जैसा कि अक्सर होता है, प्रलेखन समय पर नहीं पढ़ा जाता है (या बिल्कुल नहीं पढ़ा जाता है)।

इस तरह की "बारीकियों" का एक उदाहरण:

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

वसूली प्रक्रिया प्रशासकों द्वारा की जानी चाहिए।

सामान्य मामले में कंपनी में सिस्टम रिकवरी नेटवर्क प्रशासकों, हेल्पडेस्क विशेषज्ञों और स्वयं उपयोगकर्ताओं द्वारा की जा सकती है। मैं बाद के विकल्प को केवल छोटी कंपनियों के लिए या आईटी उद्योग के लिए विशेषता नहीं मानूंगा। हेल्पडेस्क विशेषज्ञों के लिए, वे आम तौर पर व्यक्तिगत फ़ाइलों की वसूली सहित एक बुनियादी स्तर की सामान्य समस्याओं को हल कर सकते हैं। लेकिन, अगर हम एक पूरे के रूप में सिस्टम को बहाल करने की बात करते हैं, तो प्रशासनिक शक्तियों वाले व्यक्ति को ऐसा काम सौंपना बेहतर है:

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

रिकवरी परीक्षण नियमित रूप से किया जाना चाहिए।

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

नेटवर्क इन्फ्रास्ट्रक्चर घटकों पर निर्भरता पर विचार करें

मान लें कि विफलता DNS सर्वर पर हुई। पुनर्प्राप्ति प्रक्रिया शुरू करने के बाद, यह पता चला कि बैकअप उत्पाद का उपयोग DNS अपने स्वयं के बुनियादी ढांचे के हिस्से के रूप में करता है (उदाहरण के लिए, यह सर्वर नाम के FQDN का उपयोग करके बैकअप रिपॉजिटरी से जोड़ता है)। परिणाम एक "परिपत्र निर्भरता" है जो विफलता के बाद स्वचालित रूप से पुनर्स्थापित नहीं करता है। एक डोमेन नियंत्रक के साथ एक समान स्थिति देखी जा सकती है (लेकिन यह बचाता है कि आमतौर पर एक कंपनी में कई डोमेन नियंत्रक होते हैं)।

इस तरह के परिपत्र निर्भरता से बचा जाना चाहिए। उत्पादक नेटवर्क से अलग सैंडबॉक्स में बैकअप की बहाली का परीक्षण करके उन्हें पहचाना जा सकता है, उदाहरण के लिए, वीम श्योरबैक तकनीक का उपयोग करके।

वसूली चरण प्रक्रियाओं का दस्तावेजीकरण

सटीक रूप से दस्तावेज़ आपदा वसूली

दो चीजों से बचना चाहिए:

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

एक विफलता की स्थिति में बनाने के लिए अनुशंसित प्रलेखन के उदाहरण:

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

विफलताओं के बाद वसूली प्रक्रिया की जांच के हिस्से के रूप में क्या परीक्षण करना है?

विफलताओं से उबरने की प्रक्रिया में उपयोग किए जाने वाले निर्देशों के लिए जितना संभव हो उतना सही होने के लिए, "प्रशिक्षण पुनर्स्थापन" किया जाना चाहिए। पुनर्प्राप्ति प्रक्रिया का परीक्षण करने की प्रक्रिया में, आपको कम से कम ऐसे प्रश्नों पर ध्यान देने की आवश्यकता है:

1. साइट के पूर्ण विनाश की स्थिति में, क्या बैकअप में उसकी बहाली के लिए आवश्यक सभी जानकारी होगी?
2. यदि मुख्य सिस्टम व्यवस्थापक अनुपलब्ध है (तो मान लें, विदेश में छुट्टी पर है) तो पुनर्प्राप्ति प्रक्रिया कैसे चलेगी?
3. यदि पुनर्प्राप्ति प्रक्रिया में उपयोग के लिए सबसे उपयुक्त बैकअप प्रति है जिसमें संग्रहण माध्यम (टेप / डिस्क) होता है तो क्या होता है?
4. तथाकथित के मामले में क्या होगा "माध्यमिक विफलता"? यही है, इस मामले में, जब वसूली प्रक्रिया के सफल समापन के बाद, यह पता चला है कि बहाल प्रणाली काम नहीं करती है?
5. क्या रिकवरी प्रक्रिया पर खर्च होने वाला समय सहमत SLA में फिट होता है? क्या प्रक्रिया में शामिल लोग SLA और उसके मापदंडों के अस्तित्व के बारे में जानते हैं, और क्या वे इसे अपने काम में ध्यान में रखते हैं?
6. पुनर्प्राप्ति प्रक्रिया किसी उत्पादक नेटवर्क (मेल सर्वर, त्वरित संदेश सर्वर, DNS, डोमेन नियंत्रक, आदि) के बुनियादी ढांचे के घटकों की विफलता को कैसे प्रभावित करेगी।
7. प्रलेखन की गुणवत्ता: एक अप्रशिक्षित प्रशासक लिखित निर्देशों का पालन करके एक उत्पादक प्रणाली को बहाल कर सकता है?
8. कंपनी की प्रतिक्रिया की गति, यदि सूचना के विनाश का कारण एक वायरस (किसी भी प्रकार का) था। इस खतरे की ख़ासियत यह है कि वायरस उनकी उपलब्धता का उल्लंघन किए बिना डेटा और एप्लिकेशन को विकृत कर सकता है, जिसके परिणामस्वरूप गलती सहिष्णुता सिस्टम एक विफलता को ठीक नहीं करता है, इसके अलावा, डेटा परिवर्तनों की प्रतिकृति के लिए कॉन्फ़िगर किए गए तंत्र स्वचालित रूप से इन विकृतियों को अन्य प्रतिकृति भागीदारों (या) में फैलाएंगे क्लस्टर / जियोक्लस्टर नोड्स)।
9. क्या पुनर्प्राप्ति प्रक्रिया विशिष्ट उपकरणों पर निर्भर करती है (जो पुनर्प्राप्ति के समय विफल हो सकती है)?
10. क्या पूरी तरह से दूरस्थ रूप से पुनर्प्राप्ति प्रक्रिया का संचालन करना संभव है?
11. यदि कंपनी की बैकअप साइटों को जोड़ने वाला चैनल बाधित हो जाए तो क्या होगा?

बेशक, एक उत्पादक प्रणाली के स्वास्थ्य के लिए खतरों की एक सूची का संकलन करते समय, किसी को इन खतरों की संभावना को भी ध्यान में रखना चाहिए और प्रत्येक मामले में सिस्टम डाउनटाइम से संभावित नुकसान के साथ उनकी तुलना करना चाहिए।

सामान्य निष्कर्ष

आरटीओ को कम करने और एसएलए शर्तों को पूरा करने के लिए योजना और परीक्षण बैकअप और रिकवरी एक महत्वपूर्ण कारक है। बैकअप से पुनर्प्राप्ति के परीक्षण के स्वचालन के संदर्भ में बैकअप उत्पाद में कार्यक्षमता की उपस्थिति अत्यंत महत्वपूर्ण है।

परीक्षण बैकअप और पेटेंट Veeam SureBackup प्रौद्योगिकी के बारे में अधिक जानकारी के लिए, यहां पढ़ें:

1. Veeam वेबसाइट पर वर्णन: VMware के लिए Veeam vPower Technology
2. वेबिनार: वर्चुअलाइज्ड पर्यावरण के लिए आधुनिक डेटा संरक्षण
3. पोस्ट " SureBackup - बैकअप से डेटा को पुनर्स्थापित करने की संभावना का स्वचालित सत्यापन "
4. पोस्ट " बैकअप से डेटा रिकवरी परीक्षण "