पिक्सर केस या फिर बैकअप परीक्षण के महत्व पर

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

... और फिर अचानक वह दिन आ गया जब कर्मचारियों में से एक (गलती से या जानबूझकर) ने सर्वर पर "/ bin / rm -r -f *" (या समान) कमांड लॉन्च किया, जिसने 100,000 एनीमेशन स्रोत फ़ाइलों का 90% हटा दिया। कंपनी के कर्मचारियों में से एक, लैरी कटलर, केवल एनीमेशन स्रोतों के साथ फ़ोल्डर फ़ाइलों को देख रहे थे, वुडी की टोपी के मॉडल में कुछ को सही करने के बारे में, जब उन्होंने देखा कि फ़ोल्डर में केवल 40 फाइलें बाकी थीं ... तो 4 ... और एक दूसरे के बाद बिल्कुल नहीं छोड़ा। लैरी ने आईटी सेवा को कॉल किया और कहा कि " बड़े पैमाने पर डेटा हानि हुई थी " और " बहाली के लिए पूर्ण बैकअप की आवश्यकता होगी ... ", जो कि थोड़ी देर बाद निकला, उनके पास दैनिक बैकअप के बावजूद नहीं था।


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

मैं विश्लेषण करना चाहूंगा: ऊपर वर्णित लोगों के समान समस्याओं को कम करने के लिए क्या कार्रवाई की जानी चाहिए।

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

यह अनुशंसा की जाती है कि आप नियमित रूप से बैकअप रिकवरी परीक्षण करें।

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

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

पुनर्प्राप्ति प्रक्रिया को अतिरिक्त चरणों की आवश्यकता हो सकती है जो किसी कारण से बैकअप उत्पाद द्वारा स्वयं के लिए नहीं किए जा सकते हैं: उदाहरण के लिए, DNS सेट करना, डेटाबेस स्क्रिप्ट चलाना, आदि। बैकअप कार्य बनाते समय, व्यवस्थापक "मानव कारक" के कारण इन चरणों के बारे में भूल सकता है (आखिरकार, वर्णित अतिरिक्त चरणों को सिस्टम पुनर्प्राप्ति चरण में आवश्यक है, और बैकअप चरण में नहीं)।

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

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

उत्पादक नेटवर्क विफलता के लिए धमकी मॉडलिंग

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

• शारीरिक पूर्ण डिस्क विफलता
• एक ही उपयोगी फ़ाइल को हटाएँ
• फ़ाइलों का वायरस संक्रमण
• एक सक्रिय निर्देशिका डोमेन नियंत्रक, DNS सर्वर, वीपीएन सर्वर, एक्सचेंज सर्वर या अन्य महत्वपूर्ण बुनियादी ढांचे की विफलता एक उत्पादक सर्वर फ़ाइल पर विफलता के रूप में एक ही समय में
• मुख्य साइट / कार्यालय में एक अलग सर्वर की विफलता और, एक ही समय में साइट / कार्यालय बैकअप के साथ संचार का नुकसान
• डबल विफलता - बैकअप सर्वर की बाद की विफलता के साथ उत्पादक सर्वर की विफलता, जो वसूली करता है

आप पोस्ट में धमकी मॉडलिंग के बारे में और अधिक पढ़ सकते हैं " डेटा को क्रैश से बचाने में खतरा मॉडल ।"

उत्पादक नेटवर्क पुनर्प्राप्ति परीक्षण कैसे न करें

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

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

संक्षेप में कहना

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

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

डेटा रिकवरी के परीक्षण के लिए, उत्पादक नेटवर्क डेटा को अनुचित जोखिम के संपर्क में नहीं लाया जाना चाहिए।

अतिरिक्त सामग्री

• SureBackup - बैकअप से डेटा को पुनर्स्थापित करने की संभावना का स्वचालित सत्यापन
• बैकअप और आपदा वसूली नीति सिफारिशें
• वर्चुअल लैब हाइपर-वी के लिए वीम बैकअप और प्रतिकृति v7 के साथ
• विफलताओं से आधुनिक डेटा संरक्षण के 5 मौलिक सिद्धांत (अंग्रेजी में)
• पिक्सर एनिमेशन स्टूडियो: क्या पिक्सर ने उत्पादन के दौरान गलती से टॉय स्टोरी 2 को हटा दिया था?
• कैसे पिक्सर की टॉय स्टोरी 2 को दो बार डिलीट किया गया था, एक बार तकनीक के द्वारा और फिर अपने अच्छे के लिए