अनुभवी छोटी चीजें -4, या "चलो इसे बैकअप का सामना करते हैं?"

"प्रायोगिक छोटी चीज़ों" की निरंतरता। पिछले भाग: एक , दो , तीन ।

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

बैकअप एक दुर्घटना बीमा कंपनी है। बैकअप बनाना भी एक नियम नहीं है, यह एक स्वयंसिद्ध है। जो कुछ भी जला हुआ व्यवस्थापक है, कभी-कभी उसका "हाथ कांपना" कभी-कभी हो सकता है, और एक स्क्रिप्ट जो गलत तरीके से लिखी गई है, या एक यादृच्छिक रूप से दबाया गया बटन बहुत परेशानी कर सकता है, अकेले एचडीडी, आग और अन्य आपदाएं दें। हां, बैकअप महंगे हैं (समय, संसाधन, उपकरण), उनका क्षणिक प्रभाव स्पष्ट नहीं है, लेकिन मुख्य बात यह है कि वे कंपनी के जोखिम का बीमा करते हैं। और यह बहुत लायक है। ऐसा लगता है कि बयान सभी के लिए समझ में आते हैं, लेकिन अक्सर ऐसी स्थिति उत्पन्न होती है जब सर्वर क्रैश हो जाता है, बैकअप होता है, लेकिन कुछ भी नहीं किया जा सकता है, सिस्टम को बहाल नहीं किया जा रहा है। और एक ऑर्केस्ट्रा के साथ एक टैम्बोरिन के लिए नृत्य शुरू होता है, कम से कम कुछ डेटा को बाहर खींचता है, आदि। आनन्द।

सबसे पहले, आइए परिचय और स्पष्ट रूप से अलग अवधारणाओं जैसे कि संग्रह और बैकअप। उदाहरण के लिए, इस तरह:

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

संग्रह

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

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

बैकअप

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

बैकअप सिस्टम

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

• बैकअप से पुनर्स्थापित करने के लिए आपको ABLE होना चाहिए। कहीं भी, कभी भी अभ्यास करें, लेकिन आप इसे करने के लिए पर्याप्त होना चाहिए।
• सोचें कि आप वास्तव में क्या बैकअप लेते हैं। यह सार्वभौमिक सर्वरों के लिए महत्वपूर्ण है, जब, उदाहरण के लिए, एक डेटाबेस एक सर्वर पर घूम रहा है, आपकी इंट्राकॉर्पोरेट साइट और वॉल्यूम अतिरिक्त रूप से फ़ाइल संसाधनों से जुड़ा हुआ है। ऐसी स्थिति में, आपको जटिल-कॉन्फ़िगर SQL + आपकी साइट लिंक का समर्थन करने के लिए उसी समय 1,500 टीबी की दूसरी फ़ाइल मात्रा को वापस नहीं करना चाहिए। सामान्य तौर पर, "एक कार्य, एक सर्वर" स्थिति के लिए प्रयास करें, सब कुछ, सब कुछ, एक मशीन पर सब कुछ लटका न दें, और यदि आप इसे लटकाते हैं, तो इसे "व्यवस्थित रूप से" बैकअप दें।
• आपका सॉफ़्टवेयर अन्य हार्डवेयर से पुनर्प्राप्त करने में सक्षम होना चाहिए जो वर्तमान से अलग है। और आपको इसे कम से कम एक बार आज़माना चाहिए!
• "सिस्टम" बैकअप, विशेष रूप से सिस्टम जो लगातार उपयोग किए जाते हैं, उन्हें एक सप्ताह से अधिक समय तक संग्रहीत नहीं किया जाना चाहिए। अपने लिए सोचें कि आपको एक महीने पहले अपने डोमेन नियंत्रक के बैकअप की आवश्यकता क्यों है? आपातकाल के मामले में, आपको MOST ताज़ा बैकअप की आवश्यकता होगी। और बाकी सभी एक सुरक्षा जाल है, अगर किसी कारण से "सबसे ताज़ा" काम नहीं किया। इस तरह के सुरक्षा जाल में 1-2 से अधिक पुनरावृत्तियों को आवंटित करना, मेरी राय में, अतार्किक और अनावश्यक रूप से व्यर्थ है।
• ऐसी प्रणालियाँ हैं जो पूरे बुनियादी ढांचे के साथ जटिल रूप से जुड़ी हुई हैं, और उन्हें पुनर्स्थापित करना, यहां तक ​​कि हाथ में एक विशिष्ट सर्वर का एक नया "सिस्टम बैकअप" होना आसान नहीं है। ऑफहैंड: सक्रिय निर्देशिका, विनिमय, आदि। समय लें, प्रलेखन का अध्ययन करें, और एक परीक्षण वातावरण में, कम से कम एक बार - लेकिन ABSOLUTELY EVERYTHING को पुनर्स्थापित करने का प्रयास करें! यह सीखने के लिए बेहतर है कि अपने सिर पर गुस्से वाले बॉस की तुलना में इंटरनेट पर एक शांत वातावरण में ऐसा कैसे करें।

डेटा बैकअप

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

1. सप्ताहांत पर, सभी डेटा का एक पूर्ण बैकअप बनाया जाता है। भंडारण की गहराई 28 दिन है, अर्थात चार स्वतंत्र पूर्ण बैकअप हैं। इस प्रकार, पिछले महीने में हम किसी भी दिन के लिए डेटा को पुनर्स्थापित करने में सक्षम होंगे।
2. कार्य दिवसों पर, एक अंतर बैकअप बनाया जाता है, जिसमें 14 दिनों की भंडारण गहराई होती है। इस प्रकार, पिछले दो हफ्तों में, हम किसी भी दिन डेटा को पुनर्स्थापित कर सकते हैं।
3. प्रत्येक महीने के पहले सप्ताहांत पर, बाकी के काम से अलग, एक मासिक बैकअप बनाया जाता है, जिसमें 12 महीने की भंडारण गहराई होती है। यह बैकअप और आर्काइव के बीच का अंतर है। एक तरफ, शेल्फ जीवन काफी बड़ा है, दूसरे पर - एक स्थिति अक्सर होती है जब आपको "कुछ महीने पहले, अधिकतम छह महीने" डेटा को पुनर्स्थापित करने की आवश्यकता होती है। वैकल्पिक रूप से, आप एक अलग काम के रूप में एक मासिक बैकअप नहीं कर सकते हैं, लेकिन बस एक उपयुक्त साप्ताहिक बैकअप की प्रतिलिपि बनाएँ।

इसके अलावा, मैं इन नियमों का पालन करने की कोशिश करता हूं:

• मैं अंतर का उपयोग करता हूं, लेकिन वृद्धिशील बैकअप नहीं। (यदि आप नहीं जानते कि यह क्या है - प्रलेखन को पढ़ना सुनिश्चित करें, ये बहुत महत्वपूर्ण अवधारणाएं हैं)। पुनर्प्राप्ति की गति में लाभ मेरे लिए बैकअप की मात्रा की तुलना में अधिक महत्वपूर्ण है।
• मैं बैकअप समय की योजना बनाता हूं ताकि मैं सुबह तक बना रह सकूं। यदि बैकअप अधिक समय लेता है, तो मैं इसे कई नौकरियों, कई सर्वरों में तोड़ देता हूं, या अन्य, अधिक उच्च गति वाले उपकरणों के बारे में सवाल उठाता हूं।
• बैकअप शेड्यूल में मैं सप्ताह (7 दिन, 28 दिन, आदि) से जुड़े अंतराल का पालन करने की कोशिश करता हूं और "महीने के पहले / आखिरी दिनों" से जुड़ा नहीं होता। एक सप्ताह काफी स्थिर मूल्य है, 7 दिन और ज्यादातर मामलों में शनिवार, रविवार दिन बंद हैं।
• मैं डिस्क का उपयोग करता हूं, टेपों का नहीं। मुझे बैकअप और फ़ाइल स्टोरेज में डेटा के बीच महंगा स्ट्रीमर मध्यस्थ पसंद नहीं है। यदि किसी कारण से यह काम नहीं करता है, तो पूरे बैकअप सिस्टम का लंबे समय तक उल्लंघन किया जाएगा। यदि आप हार्ड ड्राइव का उपयोग करते हैं, तो इससे बचा जा सकता है।
• मैं यह सुनिश्चित करने की कोशिश करता हूं कि डेटा का एक तार्किक रूप से स्वतंत्र हिस्सा एक अलग बैकअप में है। उदाहरण के लिए, अगर हम Symantec Backup Exec की बात करें, तो एक नौकरी = एक मीडिया। मैं वास्तव में उस स्थिति को पसंद नहीं करता जब एक काम कई फाइलों में "फैल गया" होता है। यह न केवल सिस्टम में भ्रम की स्थिति का परिचय देता है, बल्कि गलती से किसी एक फाइल ("हाथ कांपना") की ओवरराइटिंग की स्थिति में, यह न केवल एक नौकरी को परेशान करता है, बल्कि सभी पड़ोसी लोगों को भी परेशान करता है।
• बिना असफल मैं मेल द्वारा सूचनाओं के साथ सॉफ्टवेयर का उपयोग करता हूं। यदि यह एक स्व-लिखित स्क्रिप्ट है - कोई भी एक टुकड़ा जोड़ने के लिए परेशान नहीं करता है जो कम से कम एक नए बैकअप, उसके आकार और मेल द्वारा डेटा भेजने की जांच करेगा। यह बैकअप की निगरानी में बहुत समय बचाता है।

अन्य बातों के अलावा, तथाकथित का उपयोग करना भी फैशनेबल है। "इंस्टेंट" बैकअप, छोटी गहराई का (1-2 दिन) विंडोज में ला वीएसएस सेवा, जब उपयोगकर्ता स्वयं चुन सकते हैं कि दस्तावेज़ के नवीनतम संस्करणों से क्या पुनर्स्थापित किया जाए। यह बहुत मदद करता है जब उपयोगकर्ता ने सुबह दस्तावेज़ को संपादित किया और दोपहर के भोजन के समय इसे हटा दिया और सुबह के संस्करण को पुनर्स्थापित करने के लिए कहा।
आप DFS सिस्टम को एक स्थायी ऑनलाइन बैकअप के रूप में भी उपयोग कर सकते हैं, लेकिन यह एक अलग पोस्ट में वर्णित है, जिसे मैं बाद में करूंगा।

जारी रखा जाए।

PS मुझे याद दिलाएं, मैं नियम निर्धारित नहीं करता हूं, लेकिन अपने अनुभव, गैर-सार्वभौमिक अनुभव को छोटे संगठनों (30-500 पीसीएस) में प्राप्त करने के लिए साझा करता हूं। यदि आपके लिए यह करने के लिए प्रथागत है, तो मैं टिप्पणियों में खुशी के साथ इसके बारे में पढ़ूंगा।