ऐसा बैकअप बनाएं जिसे आप वास्तव में पुनर्स्थापित कर सकें

आपको जिस रिकवरी की आवश्यकता है उससे शुरू करें

बैकअप योजना दो व्यावहारिक प्रश्नों से शुरू होती है: आप हाल के कितने काम को खो सकते हैं, और सेवा कितने समय तक अनुपलब्ध रह सकती है? ये उत्तर शेड्यूल, शामिल किए जाने वाले डेटा और पुनर्स्थापन विधि निर्धारित करते हैं। दैनिक प्रति एक कम बदलने वाली वेबसाइट के लिए उपयुक्त हो सकती है जबकि व्यस्त एप्लिकेशन के लिए बहुत बड़ा अंतराल छोड़ सकती है।

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

विफलता सीमा के बाहर एक प्रति रखें

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

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

एक सुसंगत एप्लिकेशन स्थिति कैप्चर करें

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

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

पृथक परिवेश में पुनर्स्थापन का परीक्षण करें

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

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

एक व्यावहारिक परिदृश्य: लॉन्च से पहले रिकवरी का अभ्यास

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

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

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

विफलता को दृश्यमान और प्रतिधारण को जानबूझकर बनाएं

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

अपनी चुनी हुई SwissOctet सेवा पर किसी भी बैकअप विकल्प का दायरा पढ़ें और पुनर्स्थापन प्रक्रिया की पुष्टि करें। Vault Storage को क्षमता घटक माना जा सकता है, लेकिन अकेला स्टोरेज उत्पाद पूरी रिकवरी नीति नहीं है। तय करें कि आपको क्या पुनर्स्थापित करना है, प्रति को स्वतंत्र रखें और सेवा के महत्वपूर्ण होने से पहले प्रक्रिया सिद्ध करें।