क्लिफहेंजर: बैकअप सही हैं ... यहाँ ... सही?

28

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

लेकिन तब, जब आप एक विशिष्ट बैकअप के लिए पूछते हैं, तो आधा समय वे वहां नहीं होते हैं:

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

कुछ हफ़्ते पहले, आपदा वास्तविक रूप से करीब आ गई थी क्योंकि एक सर्वर ने बहुत सारे छापे खो दिए थे। सौभाग्य से एक डिस्क अभी भी डेटा को कॉपी करने के लिए पर्याप्त थी, अगर आपने बहुत बार कोशिश की थी।

लेकिन उस निकट आपदा के बाद भी, मैं स्थिति को सुधारने के लिए सीसडैमिन को मना नहीं कर सकता। तो मैं सोच रहा हूँ, लोगों की आँखें खोलने के लिए कोई सुझाव? ऐसा लगता है कि हम एक चट्टान के किनारे पर चल रहे हैं।

backup

— Andomar
स्रोत

17

तो आप कह रहे हैं कि न केवल आपके sysadmins अक्षम करने के लिए पर्याप्त हैं RAID सेट खोने के लिए, वे भी बेकार हैं कि सिस्टम के लिए बैकअप नहीं है? कुछ नए व्यवस्थापक प्राप्त करने के लिए एक अच्छे मामले की तरह लगता है।

— पॉवरऐप

24

आपको हमेशा इन चीजों को ऊपर से तय करना होगा।

क्या वर्तमान बैकअप रणनीति प्रबंधन द्वारा समर्थित और समझी गई है? यदि नहीं, तो यह बेकार है।

कार्यकारी प्रबंधन को समस्याओं के बारे में जानने की जरूरत है और क्या जोखिम शामिल हैं (वित्तीय डेटा को खोने के लिए जिसे आपको जीवित रहने के लिए कानूनी रूप से बाहर लाने की जरूरत है, या ग्राहक डेटा जिसे इकट्ठा करने में वर्षों लगे हैं?) और कार्यों पर निर्णय लेने में, या निर्णय लेने के लिए तौलना चाहिए। किसी (जैसे आप) को कार्रवाई करने देना।

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

— ओस्कर डुवॉर्न
स्रोत

मुझे पूरी तरह से काम की राजनीति से नफरत है, और लोग "शुरुआती तूफान", लेकिन अगर आप "शीर्ष पर जाने" की स्थिति और अन्य "तूफान" शुरुआत के बारे में ईमानदार सच्चाई बता रहे हैं तो शायद सबसे अच्छा / एकमात्र तरीका है।

— बेनामी कायर

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

— Oskar Duveborn

14

कहाँ से शुरू करें? यह एक आपदा होने की प्रतीक्षा है। एक Sysadmins प्राथमिक नौकरी कार्य यह सुनिश्चित करने के लिए है कि डेटा बैकअप और पुनर्प्राप्त करने योग्य है। बाकी सब कुछ गौण है। नहीं तो नहीं, लेकिन नहीं।

यहाँ कुछ चीजें हैं जो आप कर सकते हैं:

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

गंभीरता से - एक उपद्रव लात। इस तरह की सामग्री किसी कंपनी को नष्ट कर सकती है।

— PowerApp101
स्रोत

बस तीन प्रयासों के अपने "आँकड़ों" पर एक बीटा वितरण का उपयोग करने के लिए मत भूलना : -Pysts.stackexchange.com/q/47771/9487

— Tobias Kienzler

5

प्रस्तावित (न्यूनतम) वार्षिक आपदा वसूली परीक्षण। परीक्षण को सफलतापूर्वक निष्पादित करने के लिए आवश्यक कार्य कमियों को प्रकट करना चाहिए।

— aharden
स्रोत

5

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

बिग बॉस को शामिल करें, उसे याद दिलाएं कि अगर आपदा आ गई, तो वह उस साल (या बदतर!) बोनस से बाहर हो जाएगा और इसलिए शायद इसी तरह की आपदा वसूली अभ्यास का आयोजन करना समझदारी होगी। इसमें अधिक समय या लागत नहीं लगनी चाहिए - प्रवेशकर्ताओं को अपने ऑफसाइट बैकअप टेप के साथ भेज दिया जाता है और उनसे एक समान कार्यालय वातावरण लाने के लिए कहा जाता है।

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

— gbjbaanb
स्रोत

1

यह बहुत बढ़िया है!

— ओस्कर डुवॉर्न

4

प्रवेश को दोष देना आसान है - हालांकि ओस्कर के पास यह अधिकार है: ये चीजें ऊपर से संचालित होती हैं। यदि प्रबंधन बैकअप को प्राथमिकता बनाने के लिए रुपये खर्च नहीं करेगा, तो आमतौर पर sysadmins भाग्य से बाहर हैं और वे अपने पास मौजूद संसाधनों के साथ सबसे अच्छा कर सकते हैं।

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

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

उसी समय आपको आविष्कारशील होना होगा और ग्राहक जो भी संसाधन प्रदान कर सकता है उसके साथ जोखिम को कम करने के लिए कड़ी मेहनत करनी होगी।

हालांकि कुछ मामलों में व्यवस्थापक दोषी हो सकते हैं, प्रबंधन हमेशा जिम्मेदार होता है: या तो जोखिम को जानने के लिए और इसे कम करने के लिए पर्याप्त नहीं करने के लिए, या उन लोगों को काम पर रखने के लिए जो उन्हें इन जोखिमों के लिए सचेत नहीं करते हैं।

— डेविड मैकिन्टोश
स्रोत

3

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

मैं बैकअप कॉन्फ़िगर करता हूं ताकि पूरा होने पर यह एक (VBScript) स्क्रिप्ट चलाता है जो बैकअप लॉग के माध्यम से दिखता है, बैकअप बैकअप के साथ केंद्रीय डेटाबेस में रिकॉर्ड काम करता है या नहीं, यह रिकॉर्ड करता है। फिर प्रधान कार्यालय में मैं एक स्क्रिप्ट चलाता हूं जो इस डेटाबेस पर सवाल उठाता है और मुझे उन साइटों की सूची के साथ प्रस्तुत करता है जहां या तो बैकअप में त्रुटि की सूचना थी या साइट से कोई रिपोर्ट नहीं थी।

अंतिम परिणाम यह है कि जब मैं अपनी डेस्क पर बैठता हूं तो मेरे पास उन सभी साइटों की एक सूची होती है, जहां मुझे बैकअप की जांच करने की आवश्यकता होती है।

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

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

जे आर

PS 99% बैकअप विफलताओं का कारण यह है कि उपयोगकर्ता बैकअप टेप को बदलना भूल गए। क्या आपको सिर्फ लूज़र पसंद नहीं है :-)

— जॉन रेनी
स्रोत

या रोबोट ने टेप को गिरा दिया (लानत है रोबोट) ^ ^ (अधिक बार ऐसा लगता है कि एक से अधिक होगा)

— ऑस्कर डुवॉर्न

2

एक बैकअप जिसका परीक्षण नहीं किया गया है, वह कोई भी बैकअप नहीं है।

— डेव चेनी
स्रोत