स्नैपशॉट किसी समय-बिंदु का प्रतिनिधित्व है जिसकी सुरक्षा उसके कार्यान्वयन से तय होती है। बैकअप रणनीति जानबूझकर रिटेंशन, पहुँच पृथक्करण और परीक्षित रिकवरी जोड़ती है। कुछ स्नैपशॉट बैकअप होते हैं; अन्य मूल स्टोरेज पर निर्भर करते हैं। पूछें कि डिलीशन, समझौता या प्राथमिक वातावरण के नुकसान पर क्या बचता है।
प्रतिलिपि को नाम देने से पहले उसका वर्णन करें
स्नैपशॉट शब्द बताता है कि किसी समय-बिंदु का प्रतिनिधित्व हुआ है, लेकिन यह नहीं कि पुनर्प्राप्त करने योग्य डेटा कहाँ रखा है या उसे कौन हटा सकता है। मूल स्टोरेज पर फ़ाइलसिस्टम स्नैपशॉट और प्रदाता-प्रबंधित ब्लॉक स्नैपशॉट की विफलता सीमाएँ अलग हो सकती हैं। लेबल को सार्वभौमिक वादा मानने के बजाय कार्यान्वयन से शुरू करें।
AWS, EBS स्नैपशॉट को अपने वॉल्यूम के इंक्रीमेंटल पॉइंट-इन-टाइम बैकअप के रूप में दस्तावेज़ित करता है। यह एक विशिष्ट कार्यान्वयन है, इस बात का प्रमाण नहीं कि हर स्नैपशॉट विकल्प एक जैसा व्यवहार करता है। किसी भी सेवा के लिए पूछें कि क्या पुनर्स्थापन मूल वॉल्यूम पर निर्भर है, क्या प्रतियाँ प्राथमिक विफलता डोमेन से बाहर जाती हैं और स्रोत हटने पर क्या होता है।
उन विफलताओं की तुलना करें जिनसे आपको उबरने की अपेक्षा है
अपडेट के बाद त्वरित रोलबैक और खाता खोने के बाद रिकवरी अलग समस्याएँ हैं। स्थानीय स्नैपशॉट पहले के लिए सुविधाजनक हो सकता है, जबकि दूसरे के लिए बहुत कम पृथक्करण देता है। स्वतंत्र प्रतियाँ सुरक्षा बढ़ा सकती हैं, लेकिन तभी जब उनका स्टोरेज, पहुँच और डिलीशन पथ उस घटना से पर्याप्त अलग हों जिसके लिए आप तैयारी कर रहे हैं।
विफलता और आवश्यक परिणाम लिखें। यह उदाहरणात्मक तुलना निर्णय में सहायक है, SwissOctet के लिए सुविधा सूची नहीं। यह प्रतियों और नियंत्रण पर प्रश्न प्रोत्साहित करती है, इस दावे पर नहीं कि एक तकनीक हमेशा श्रेष्ठ है। वास्तविक परिणाम कॉन्फ़िगरेशन और ऑपरेटर की दस्तावेज़ित रिकवरी प्रक्रिया पर निर्भर करता है।
| परिदृश्य | स्नैपशॉट के लिए प्रश्न | बैकअप के लिए प्रश्न |
|---|---|---|
| खराब अनुप्रयोग अपडेट | क्या मैं इच्छित बिंदु पर लौट सकता हूँ? | उपयोगी पुनर्स्थापन में कितना समय लगता है? |
| प्राथमिक डिस्क खो गई | क्या प्रतिलिपि उस डिस्क पर निर्भर है? | क्या मैं नए स्टोरेज पर पुनर्स्थापित कर सकता हूँ? |
| प्रशासनिक खाते से समझौता | क्या यह खाता हर प्रतिलिपि हटा सकता है? | क्या डिलीशन अधिकार अलग हैं? |
| त्रुटि हफ्तों बाद पता चली | क्या वह बिंदु अब भी रिटेन है? | क्या रिटेंशन खोज में हुई देरी को कवर करता है? |
अनुप्रयोग की संगति जाँचें
डिस्क फ़ाइलें कैप्चर कर सकती है जबकि अनुप्रयोग उन्हें अभी बदल रहा हो। सॉफ़्टवेयर और स्नैपशॉट प्रक्रिया के आधार पर परिणाम क्रैश-संगत स्थिति का प्रतिनिधित्व कर सकता है, समन्वित अनुप्रयोग स्थिति का नहीं। यह न मानें कि पढ़ने योग्य फ़ाइलों का अर्थ डेटाबेस और उससे जुड़े अपलोड सहमत हैं। अनुप्रयोग या डेटाबेस द्वारा दस्तावेज़ित बैकअप विधि का उपयोग करें।
PostgreSQL का निरंतर-संग्रहण डिज़ाइन अंतर दिखाता है: रिकवरी के लिए उपयुक्त बेस बैकअप और आवश्यक write-ahead log फ़ाइलों का निरंतर क्रम चाहिए। डेटाबेस चलते समय लापरवाही से कॉपी की गई डायरेक्टरी समतुल्य प्रक्रिया नहीं है। यदि अनुप्रयोग डेटाबेस के बाहर भी फ़ाइलें रखता है, तो योजना बनाएँ कि वे दोनों डेटासेट एक साथ कैसे पुनर्प्राप्त होंगे।
रिटेंशन को रिकवरी विंडो मानें
रिटेंशन में यह ध्यान रखें कि त्रुटि कितने समय तक अनदेखी रह सकती है। दस दिन की विंडो उस गलती से हुए डिलीशन में मदद नहीं करती जो महीने बाद पता चले। हर प्रतिलिपि अनिश्चित काल तक रखने से अलग समस्या बनती है: लागत, संवेदनशील-डेटा जोखिम में वृद्धि और अस्पष्ट डिलीशन नीति। ठोस परिचालन और डेटा-हैंडलिंग आवश्यकताओं से रिटेंशन चुनें।
रिकवरी बिंदुओं को उपयोगी संदर्भ के साथ लेबल करें, जैसे अनुप्रयोग संस्करण और पूर्ण जॉब समय, बिना रहस्य एम्बेड किए। अच्छी स्थिति को क्षतिग्रस्त से अलग करने के लिए पर्याप्त इतिहास रखें। प्रूनिंग से पहले पुष्ट करें कि चुना गया सिस्टम साझा या इंक्रीमेंटल डेटा को कैसे संभालता है; लेबल किया गया बिंदु हटाना साधारण स्टैंडअलोन फ़ाइल हटाने के समान नहीं हो सकता।
सफल जॉब को सत्यापित डेटा से अलग रखें
बैकअप टूल का सफलता बताना यह स्थापित करता है कि उसकी प्रक्रिया उसके नियमों के तहत पूरी हुई। यह स्वतः प्रमाणित नहीं करता कि सभी महत्वपूर्ण अनुप्रयोग डेटा चुना गया, हर संग्रहीत बाइट सुरक्षित है या नया सर्वर परिणाम का उपयोग कर सकता है। ये अलग जाँचें हैं। परिचालन योजना में रिपॉज़िटरी स्वास्थ्य, चयन समीक्षा और प्रतिनिधि पुनर्स्थापन शामिल करें।
Restic अपने डिफ़ॉल्ट रिपॉज़िटरी चेक और संग्रहीत pack डेटा पढ़ने वाले सत्यापन के बीच अंतर बताता है। पूर्ण डेटा-पठन जाँच अधिक समय और बैंडविड्थ ले सकती है। यह उदाहरण योजना बिंदु को ठोस बनाता है: तय करें कि सत्यापन वास्तव में क्या पढ़ता है और कार्य का बजट बनाएँ। यह न मानें कि check नाम वाले हर कमांड का कवरेज समान है; टूल दस्तावेज़ देखें।
छोटी, पूर्ण रिकवरी का परीक्षण करें
ऐसे प्रकाशन की कल्पना करें जिसमें डेटाबेस, अपलोड की गई छवियाँ और कॉन्फ़िगरेशन हों। तीनों को निजी परीक्षण वातावरण में पुनर्स्थापित करें, फिर एक लेख खोलें और उसके अटैचमेंट सत्यापित करें। अभ्यास के दौरान निर्धारित मेल, भुगतान और प्रकाशन एकीकरण अक्षम रखें। केवल एक यादृच्छिक टेक्स्ट फ़ाइल का परीक्षण उन संबंधों को चूक जाएगा जो अनुप्रयोग को उपयोगी बनाते हैं।
आवश्यक समय मापें और दर्ज करें कि कौन-से क्रेडेंशियल, पैकेज संस्करण या बाहरी निर्भरताएँ अनुपस्थित थीं। पुनर्प्राप्त फ़ाइलों की अनुमतियों की समीक्षा करें, केवल उनकी सामग्री की नहीं। रिकवरी अभ्यास अक्सर बताता है कि डेटा मौजूद है, लेकिन उसका उपयोग करने के निर्देश या पहुँच परिचालन योजना के साथ कभी संरक्षित नहीं किए गए।
वैकल्पिक बैकअप को एक विशिष्ट सेवा के रूप में पढ़ें
SwissOctet कॉन्फ़िगर करते समय परिवार के लिए सटीक बैकअप विकल्प और रिटेंशन अवधि देखें। पूछें कि यह किन वॉल्यूम और अनुप्रयोग डेटा को कवर करता है, क्या रिकवरी स्व-सेवा है और प्राथमिक कॉन्फ़िगरेशन बदलने पर क्या होता है। केवल विकल्प लेबल स्वतंत्र प्रतिलिपि, अपरिवर्तनीय रिपॉज़िटरी या डेटाबेस-संगत रिकवरी बिंदु स्थापित नहीं करता।
स्नैपशॉट का उपयोग वहाँ करें जहाँ वे कार्यभार के अनुकूल हों और उन विफलताओं के लिए व्यापक बैकअप रणनीति रखें जिन्हें वे कवर नहीं करते। महत्वपूर्ण डेटा के लिए स्वतंत्र रिकवरी मार्ग दर्ज करें, प्रतियाँ मिटाने वाले क्रेडेंशियल की सुरक्षा करें और प्रक्रिया का परीक्षण करें। सबसे मजबूत विकल्प वह है जो आपके तय परिदृश्य में टिकता है, न कि सबसे भरोसा दिलाने वाले नाम वाला।
आपकी व्यावहारिक चेकलिस्ट।
- पहचानें कि पुनर्प्राप्त करने योग्य डेटा कहाँ रहता है।
- उन विफलताओं की सूची बनाएँ जिनसे प्रतिलिपि को उबरना है।
- अनुप्रयोग-समर्थित संगति विधि का उपयोग करें।
- खोज विंडो के लिए रिटेंशन चुनें।
- डिलीशन अधिकारों की अलग से सुरक्षा करें।
- पूर्ण अनुप्रयोग को अलग वातावरण में पुनर्स्थापित करें।
महत्वपूर्ण विवरण।
क्या स्नैपशॉट कभी बैकअप नहीं होता?+
कुछ स्नैपशॉट कार्यान्वयन बैकअप होते हैं। उपयोगी अंतर उनकी स्टोरेज निर्भरता, रिटेंशन, पहुँच मॉडल और परीक्षित रिकवरी है, केवल लेबल नहीं।
क्या सफल अखंडता जाँच प्रमाणित करती है कि अनुप्रयोग काम करेगा?+
यह केवल वही प्रमाणित करती है जो वह जाँच कवर करती है। अनुप्रयोग पुनर्स्थापन, कॉन्फ़िगरेशन, अनुमतियाँ और डेटा संबंध अलग से परखें।
क्या मुझे बैकअप उसी सर्वर पर रखना चाहिए?+
समान सर्वर पर प्रतिलिपि सीमित गलतियों में मदद कर सकती है, लेकिन महत्वपूर्ण विफलताएँ साझा करती है। महत्वपूर्ण डेटा के लिए उस विफलता सीमा के बाहर रिकवरी मार्ग चाहिए जिससे आपको उबरना है।
स्रोत पर जाएं।
ये संदर्भ इस गाइड में तकनीकी अवधारणाओं का समर्थन करते हैं। उत्पादन प्रणाली बदलने से पहले वर्तमान दस्तावेज़ का पालन करें।
- Amazon EBS: स्नैपशॉट docs.aws.amazon.com
- PostgreSQL: निरंतर संग्रहण और पॉइंट-इन-टाइम रिकवरी www.postgresql.org
- Restic: रिपॉज़िटरी और अखंडता जाँच के साथ कार्य restic.readthedocs.io
SwissOctet द्वारा संपादकीय मार्गदर्शन। उदाहरण केवल दृष्टांत हैं। सेवा विशिष्टताएं, उपलब्ध विकल्प और संविदात्मक शर्तें अलग से सत्यापित की जानी चाहिए।