बैकअप रणनीति: 3-2-1 नियम से परीक्षण की हुई रिकवरी तक

एक प्रति अकेली व्यावसायिक प्रक्रिया वापस नहीं लाती

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

परिणाम यह होना चाहिए कि खास प्रक्रिया तय समय में स्वीकार्य डेटा स्थिति के साथ फिर काम करे। छोटे कारीगर व्यवसाय और चौबीसों घंटे ऑर्डर लेने वाले सिस्टम की ज़रूरत अलग हो सकती है। आर्थिक योजना इसी अंतर से शुरू होती है।

बैकअप कार्यक्रम से पहले स्वीकार्य हानि चुनें

Recovery Point Objective (RPO) स्वीकार्य डेटा हानि को समय में सीमित करता है। चार घंटे के RPO का अर्थ है कि विफलता के समय उपलब्ध पुनर्प्राप्ति बिंदु चार घंटे से पुराना न हो। Recovery Time Objective (RTO) सेवा लौटने तक लक्ष्य समय बताता है। केवल रात का बैकअप चार घंटे का RPO पूरा नहीं करता, और तेज़ डाउनलोड RTO सिद्ध नहीं करता।

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

• प्रोजेक्ट दस्तावेज़: RPO चार घंटे, RTO एक कार्यदिवस; रोज़ कई बिंदु और चुने हुए फ़ोल्डर की बहाली।
• मौजूदा ऑर्डर: RPO एक घंटा, RTO चार घंटे; डेटाबेस सुरक्षा और तुरंत उपलब्ध पुनर्प्राप्ति परिवेश।
• सार्वजनिक वेबसाइट: RPO 24 घंटे, RTO आठ घंटे; सामग्री, अनुप्रयोग, कॉन्फ़िगरेशन और डोमेन प्रशासन साथ सुरक्षित करें।

3-2-1 में सचमुच स्वतंत्र प्रतियाँ चाहिए

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

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

अपरिवर्तनीयता की सीमाएँ उत्पाद पर निर्भर हैं। S3 Object Lock खास ऑब्जेक्ट संस्करण तय अवधि तक सुरक्षित करता है, जबकि नए संस्करण बन सकते हैं। संरक्षण जाँचें और उसे स्टोरेज बजट तथा पुनर्प्राप्ति प्रक्रिया के अनुरूप रखें।

फ़ाइल, डेटाबेस और क्लाउड सेवा को अलग तरीके चाहिए

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

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

पूरे पुनर्प्राप्ति रास्ते की लागत निकालें

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

यह बैंडविड्थ गणना उदाहरण है: लगातार पूरी तरह उपयोग योग्य 100 Mbit/s कनेक्शन पर 1 TB भेजने में दशमलव इकाइयों और प्रोटोकॉल ओवरहेड को छोड़कर लगभग 22.2 घंटे लगते हैं। अनपैकिंग, डेटाबेस शुरू करना और सत्यापन में और समय लगता है। चार घंटे की पुनर्प्राप्ति के लिए तेज़ रास्ता या पहले से नज़दीक रखी प्रतियाँ चाहिए।

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

सत्यापित परिणाम वाला अभ्यास करें

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

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

अलर्ट के बाद कार्रवाई होनी चाहिए

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

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

हस्तांतरण स्वीकृति का हिस्सा है

पुनर्प्राप्ति योजना खराब सर्वर या एक व्यक्ति के ज्ञान के बिना उपलब्ध होनी चाहिए। संपर्क, उत्पाद और संस्करण, निर्भरताओं का क्रम और कुंजियों तथा लॉगिन की सुरक्षित पहुँच लिखें। पासवर्ड नियंत्रित आपातकालीन पहुँच वाले उचित मैनेजर में रखें, सामान्य पुस्तिका में खुले नहीं।

दूसरा व्यक्ति केवल दस्तावेज़ से सीमित रिस्टोर कर सके। ज्ञान की कमी दर्ज करें। अभ्यास की आवृत्ति बदलाव और महत्व के अनुसार हो: वार्षिक दस्तावेज़ित समीक्षा शुरुआत हो सकती है, जबकि बार-बार बदलते मुख्य सिस्टम या छूटे लक्ष्य अधिक जाँच माँगते हैं।