एन्क्रिप्टेड बैकअप जिन्हें आप वास्तव में रिस्टोर कर सकते हैं।

रिपॉज़िटरी सीमा चुनें

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

सुसंगत डेटा कैप्चर करें

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

हटाना कठिन बनाएँ

केवल-जोड़ें या अपरिवर्तनीय गंतव्य पर विचार करें जहाँ स्रोत मशीन हर ऐतिहासिक प्रति मिटा न सके। जहाँ संभव हो, प्रतिधारण और प्रूनिंग क्रेडेंशियल अलग रखें। केवल एन्क्रिप्शन किसी समझौता-ग्रस्त सर्वर को लिखने योग्य रिपॉज़िटरी हटाने से नहीं रोकता।

जाँच और पुनर्स्थापन अभ्यास निर्धारित करें

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

प्रतिलिपि जोड़ने को इतिहास हटाने से अलग रखें

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

• रिपॉज़िटरी रखरखाव क्रेडेंशियल्स को प्रोडक्शन मशीन से दूर रखें
• हटाने की अनुमति देने से पहले एक रिटेंशन ड्राई रन चलाएँ
• प्रत्येक रिकवरी अभ्यास के लिए एक नया खाली लक्ष्य उपयोग करें

restic check
restic snapshots
restic restore latest --target /srv/restore-drill

आधिकारिक दस्तावेज़: Restic प्रतिधारण और प्रूनिंग

पास शर्त के साथ एक रिस्टोर ड्रिल

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

• पहले परीक्षण के रूप में लाइव एप्लिकेशन पर पुनर्स्थापित न करें
• पुष्टि करें कि एन्क्रिप्शन क्रेडेंशियल स्वतंत्र रूप से पुनर्प्राप्त करने योग्य हैं
• यदि नवीनतम सफल बैकअप आपके रिकवरी लक्ष्य से अधिक हो तो चेतावनी दें

बहिष्करण चुनने से पहले एक रिकवरी मैनिफ़ेस्ट बनाएँ

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

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

आधिकारिक दस्तावेज़: Borg: एन्क्रिप्शन, संगति और पुनर्स्थापन

संग्रहीत डेटा के साथ-साथ रिपॉज़िटरी मेटाडेटा की भी जाँच करें

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

restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drill

आधिकारिक दस्तावेज़: restic: रिपॉज़िटरी जाँच और डेटा सत्यापन

रखरखाव को समझौता किए गए क्लाइंट की पहुँच से बाहर रखें

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

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

आधिकारिक दस्तावेज़: Borg: केवल-जोड़ने वाला संचालन और रखरखाव · restic: प्रतिधारण और केवल-जोड़ें संबंधी विचार