RAID बैकअप नहीं है: 3-2-1-1-0 को व्यवहार में लागू करें

RAID उपलब्धता के लिए है, पुराने संस्करण सुरक्षित रखने के लिए नहीं

RAID डेटा और अतिरिक्त सुरक्षा को कई ड्राइव में बाँटता है। चुने गए स्तर की विफलता-सहन क्षमता के भीतर, एक ड्राइव खराब होने के बाद भी सिस्टम चल सकता है। इससे रुकावट कम होती है, लेकिन स्वतंत्र ऐतिहासिक प्रति नहीं बनती। डेटा मिटाना, रैनसमवेयर एन्क्रिप्शन, अनुप्रयोग का खराब डेटा लिखना या दोषपूर्ण स्क्रिप्ट तुरंत ऐरे के मौजूदा डेटा को प्रभावित कर सकते हैं।

कंट्रोलर की खराबी, बिजली से नुकसान, ऑपरेटर की गलती और चोरी पूरे ऐरे को प्रभावित कर सकते हैं। RAID उपलब्धता की योजना का हिस्सा है; बैकअप पुनर्प्राप्ति की योजना का। दोनों एक-दूसरे के पूरक हैं, लेकिन जोखिम मूल्यांकन या बजट में उनकी सुरक्षा को एक-दूसरे का विकल्प नहीं गिनना चाहिए।

रीबिल्ड के दौरान जोखिम बढ़ता है

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

विफलता-सहन क्षमता, लिखने के काम, रीबिल्ड समय और संचालन की ज़रूरतों के आधार पर स्तर चुनें। RAID 1 मिरर बनाता है, RAID 5 सामान्यतः एक ड्राइव की विफलता, RAID 6 दो की विफलता सहता है, और RAID 10 मिररिंग तथा स्ट्राइपिंग जोड़ता है। इनमें से कोई भी तार्किक डेटा भ्रष्टाचार या समझौता किए गए प्रशासक खाते से नहीं बचाता।

3-2-1-1-0 को एक प्रक्रिया की तरह समझें

इस नियम का अर्थ है: चालू डेटा सहित तीन प्रतियाँ, दो प्रकार के माध्यम, एक दूसरी जगह की प्रति, एक ऑफ़लाइन या अपरिवर्तनीय प्रति और रिस्टोर की शून्य ऐसी त्रुटियाँ जिनकी जाँच बाकी हो। संस्करण इतिहास से घटना से पहले की स्थिति में लौट सकते हैं। WORM या Object Lock सुरक्षित रखे संस्करणों को बचा सकते हैं; एयर गैप ऑफ़लाइन प्रति को अलग रखता है।

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

लक्ष्य, संरक्षण अवधि और जिम्मेदारियाँ तय करें

RPO स्वीकार्य डेटा हानि बताता है, जैसे एक या 24 घंटे; RTO स्वीकार्य रुकावट बताता है, जैसे चार घंटे। नीति में लिखा होना चाहिए कि कौन, किस डेटा का, कब और कहाँ बैकअप लेता है। एक उदाहरण कार्यक्रम में रोज़ इन्क्रिमेंटल, हर सप्ताह पूर्ण बैकअप और RPO के अनुसार उचित होने पर महत्वपूर्ण डेटाबेस की हर घंटे सुरक्षा होती है। 30, 90 और 365 दिन की संरक्षण अवधि सुरक्षा श्रेणी चुनने के उदाहरण हैं, सार्वभौमिक आवश्यकताएँ नहीं।

डेटा को भेजते और रखते समय एन्क्रिप्ट करें, उचित KMS/HSM व्यवस्था से कुंजियाँ सँभालें और बैकअप की भूमिकाएँ सामान्य प्रशासन से अलग रखें। डीडुप्लिकेशन और कंप्रेशन लागत नियंत्रित करने में मदद कर सकते हैं। असफल जॉब, क्षमता और लक्ष्य से विचलन की निगरानी करें; कुंजियाँ और बैकअप एक साथ खुले न छोड़ें और किसी एक खाते को हर प्रति का असीमित नियंत्रण न दें।

छोटे व्यवसाय के लिए एक उदाहरण व्यवस्था

उपयुक्त एजेंट या हाइपरवाइज़र एकीकरण से फ़ाइल, डेटाबेस और वर्चुअल मशीन सुरक्षित करें। तेज़ रिस्टोर के लिए संस्करणों वाला स्थानीय NAS या उपकरण, Object Lock वाली एन्क्रिप्टेड बाहरी S3 प्रति और महत्वपूर्ण डेटा के लिए हर सप्ताह तैयार ऑफ़लाइन माध्यम रखें।

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

• स्रोत: सुरक्षित किए जाने वाले अनुप्रयोग कार्यभार।
• मुख्य गंतव्य: संस्करणों वाला स्थानीय NAS या उपकरण।
• दूसरी जगह की प्रति: उचित संरक्षण सुरक्षा वाला एन्क्रिप्टेड ऑब्जेक्ट स्टोरेज।
• एयर गैप: महत्वपूर्ण डेटा की नियंत्रित ऑफ़लाइन प्रति।
• ऑडिट: तय समय पर रिस्टोर, समय मापना और दर्ज की गई व्यावसायिक जाँच।

पुनर्प्राप्ति का पूरा क्रम करके दिखाएँ

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

सबसे हाल के रिस्टोर, उसकी अनसुलझी त्रुटियाँ और अगला निर्धारित परीक्षण दर्ज करें। सिर्फ RAID, स्नैपशॉट या सफल जॉब की हरी रिपोर्ट वास्तविक घटना के लिए तैयारी साबित नहीं करती।