क्या मुझे अभी भी बैकअप की आवश्यकता है अगर मेरे पास रोलबैक क्षमताओं के साथ एक अतिरेक भंडारण प्रणाली है?


32

मेरे संगठन ने हाल ही में एक भंडारण प्रणाली खरीदी। इसमें RAID6 के साथ 1.5Petabyte है, और एक भौतिक भिन्न स्थान में एक ऑनलाइन सिंक किया गया दर्पण है।

सिस्टम 30 दिनों तक डिफ़ॉल्ट रूप से रोलबैक / फ़ाइल रिकवरी की अनुमति देता है, लेकिन इसे बढ़ाया जा सकता है।

यदि केवल संग्रहण पर रहने वाले डेटा के लिए हमें किसी प्रकार के अतिरिक्त बैकअप की आवश्यकता है, तो चर्चा चल रही है।

प्रणाली में अतिरेक का बहुत अच्छा स्तर है, इसमें भौगोलिक अतिरेक है और कुछ हद तक रोलबैक की अनुमति देता है जिसका अर्थ है कि हम परिभाषित समय (डिफ़ॉल्ट रूप से 30 दिन) पुराने डेटा या गलती से हटाए गए डेटा तक पुनर्प्राप्त कर सकते हैं।

इस परिदृश्य को देखते हुए यह "पारंपरिक" बैकअप के लिए अभी भी समझ में आता है? पारंपरिक रूप से, मेरा मतलब है कि एक समर्पित बैकअप सिस्टम, स्नैपशॉट के साथ जो हम कुछ गलत होने पर प्राप्त कर सकते हैं।

क्या हमें वास्तव में इसकी आवश्यकता है? क्या मैं कुछ भूल रहा हूँ? क्या मैं सिर्फ पारंपरिक तरीके से सोच रहा हूं और जोश में हूं?


यदि यह आपको स्नैपशॉट को किसी अन्य डिवाइस पर बंद करने की अनुमति देता है, तो आप उन समस्याओं को दूर कर सकते हैं जो स्वेन अपने जवाब में उल्लेख करता है।
Drifter104

4
निश्चित रूप से संबंधित, लेकिन शायद भौगोलिक अलगाव और स्नैपशॉट रोलबैक क्षमता के कारण एक समान डुप्लिकेट नहीं है: RAID एक बैकअप क्यों नहीं है?
बजे एक सीवी

जब तक आप यह भी जगह में हर कीबोर्ड से "हटाएँ" कुंजी को हटाने के रूप में, आप सुनहरा ;-)
टॉम न्यूटन

1
निश्चित रूप से नहीं होने से बेहतर है। मैं अभी भी पसंद करूंगा कि बैकअप "लोगों की गलतियों" से दूर एक माध्यम पर रहते हैं। फिर भी, आप अपने प्रश्न का उत्तर जानते हैं, लेकिन इसमें आपके डेटा की कीमत शामिल है। सौभाग्य।
टॉम न्यूटन

7
क्या आपकी "रोलबैक" क्षमता भी वॉल्यूम में बदलाव को कवर करती है? उदाहरण के लिए, क्या यह पुनर्प्राप्त करने में सक्षम होगा यदि कोई व्यक्ति सभी संस्करणों को हटा देता है?
vhu

जवाबों:


40

आप जो वर्णन करते हैं, वह भौगोलिक रूप से वितरित RAID के लिए आवश्यक है और एक RAID कभी बैकअप नहीं था

ऑनलाइन सिंक का आमतौर पर मतलब है कि आप प्राथमिक स्टोरेज पर जो कुछ भी करते हैं, वह तुरंत बैकअप सिस्टम में रिप्लाई हो जाता है, जिसमें किसी हमलावर द्वारा या (केवल) एक एडमिन त्रुटि या डिलीट (जैसे) स्नैपशॉट और जैसे ऑपरेशन शामिल हैं।


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

8
सच। लक्ष्य यह है कि कोई भी व्यक्ति स्वचालित स्नैपशॉट का प्रबंधन करने में सक्षम नहीं होगा। कि गलतियों के खिलाफ लचीलापन का स्तर देना चाहिए। बेशक गलती से भी कोई बैकअप हटा सकता है।
nsn

2
@ आपके डिवाइस प्रबंधन में बग या आपकी प्रबंधन स्क्रिप्ट में बग जैसी कई अन्य सहसंबद्ध विफलताएं हैं। बैकअप के बिना कहीं और आप अपनी नौकरी वेंडर को सौंप रहे हैं ... क्या आप ऐसा करने को तैयार हैं? नुकसान की स्थिति में क्षति की मात्रा भी निर्धारित करें। शायद जवाब इस बात पर निर्भर करता है कि डेटा कितना मूल्यवान है। क्या कंपनी इसके बिना चली गई?
usr

2
@ nsn > बेशक कोई बैकअप गलती से भी हटा सकता है। < - हाँ लेकिन यह तब और अधिक कठिन हो जाता है जब बैकअप को ऑफलाइन लिया जाता है और उदाहरण के लिए सुरक्षित, ऑफ़साइट स्टोरेज में रखा जाता है।
रॉब मोइर

7

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

यदि यह आपकी स्थिति के लिए मामला नहीं है, तो आपको अच्छा होना चाहिए।


3
हाँ सच। 30 केवल डिफ़ॉल्ट है हम अन्य मान सेट कर सकते हैं। वैसे भी, ऑफलाइन स्टोरेज में पैसे भी खर्च होते हैं और हमेशा के लिए नहीं टिकते। हमेशा एक दिन होगा n + 1
nsn

2
मुझे 30 दिनों का रोल करना पसंद है, साथ ही पिछले साल के लिए मासिक, साथ ही एक वार्षिक। मेरे पास कई फाइलें हैं (जो महत्वपूर्ण और पुरानी थीं) लुप्त हो गईं और रोलिंग समय अवधि के भीतर पता नहीं लगा। वार्षिक बैकअप जीवन रक्षक हो सकता है।
ब्रायन नोब्लुच

@BrianKnoblauch: हाँ, उस तरह की योजना एक अच्छा विचार है, ऑनलाइन स्नैपशॉट या ऑफ़लाइन बैकअप के लिए।
बेन वोइगट

6

भौगोलिक रूप से अलग मशीनों के होने से दोनों का डेटा अच्छा है।

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

तो, यह नीचे आता है कि डेटा कितना महत्वपूर्ण / मूल्यवान है? यदि यह समाप्त हो गया तो संगठन क्या करेगा?


3
यदि आपके पास दो स्थान हैं और आप दोनों खो देते हैं तो आपने शायद अपना बैकअप भी खो दिया है। इस उत्तर में से अधिकांश दो से अधिक साइटों पर प्रतिकृति के लिए एक तर्क है, समर्थन के पक्ष में तर्क नहीं।
बेन

2
वह हमेशा के लिए चला जाता है। हर बार जब आप अतिरेक का स्तर जोड़ते हैं, तो आप इसे असफल होने की उम्मीद कर सकते हैं (या तो भौगोलिक, या बस डिस्क)। यदि आपके पास निरर्थक डिस्क हैं, तो आप हमेशा पूछ सकते हैं "क्या होगा अगर n + 1 टूटता है"। आपके सर्वर रूम में और आपके बैकअप रूम में भी आग लग सकती है। अंदर की नौकरी भी दोनों पर हमला कर सकती है। 100% विफल कैफे सिस्टम नहीं हैं। यहाँ यह जानना है कि क्या ऐसा सेटअप "पारंपरिक" सर्वर + बैकअप के बराबर हो सकता है
nsn

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

@ क्लिक करें, मुझे लगता है कि आपके पास एक बहुत ही मान्य टिप्पणी है। मैं इसका जवाब दूंगा।
nsn

4

यहाँ सवाल यह है कि डिस्कनेक्ट और भौगोलिक रूप से आपके डेटा की एक प्रतिकृति प्रतिलिपि को बैकअप और उच्च उपलब्धता / अतिरेक अवसंरचना नहीं होने से पहले अलग-अलग होना चाहिए। मेरी आंत यह है कि आप करीब हैं, लेकिन अभी भी एक बैकअप की जरूरत है।

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

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

यह सब कहा, मैं फिर से दोहराऊंगा कि आपका बैकअप आपके डेटा से अलग बुनियादी ढांचे पर होना चाहिए। यहां अलगाव के कई स्तर हैं, लेकिन मुझे लगता है कि प्रत्यक्ष प्रतिकृति के माध्यम से जुड़ा कुछ भी बैकअप होने के करीब है। आप इसके अतिरिक्त कुछ चाहते हैं।


1

अनुमान: भंडारण प्रणाली का उपयोग कई अनुप्रयोगों द्वारा किया जाएगा।

मुझे लगता है कि आप एक अलग बैकअप सिस्टम के साथ बहुत बेहतर करेंगे।

RAID और मिररिंग बैकअप नहीं हैं, लेकिन बिलिन रोलबैक सुविधा पारंपरिक बैकअप सिस्टम को बदल सकती है।

परंतु:

मैं पुनर्प्राप्ति नीतियों को अनुप्रयोग / डेटा आधारित होना चाहता हूं, क्योंकि भंडारण आधारित नहीं है:

  1. अनुप्रयोगों में डेटा की पुनर्प्राप्ति और स्वीकार्य हानि से संबंधित विभिन्न आवश्यकताएं हैं (उनमें से कुछ विभिन्न नियमों द्वारा लगाए गए हैं: केवल-पढ़ने के लिए माध्यम, एन्क्रिप्शन, पिछले X वर्ष, आदि रखें)
  2. कुछ अनुप्रयोगों में बहुत अच्छा बैकअप और रिकवरी टूल (oracle, mssql) buildin होता है और बैकअप / रिकवरी भाग (Oracle डीबीए के रूप में, मुझे पसंद है और मैं rman के साथ Oracle से संबंधित अपने सभी बैकअप करूँगा) करने का तरीका सुझा रहा हूँ।
  3. विकास, आपके अंतरिक्ष का उपयोग बहुत तेजी से विकास कर सकता है, तो आप उम्मीद करते हैं, अब यह प्रणाली रोलबैक डेटा के 30 दिनों को समायोजित कर सकती है, भविष्य में इसकी गारंटी नहीं है
  4. सस्ता, कई वर्षों के विकास के बाद, बैकअप / रिकवरी नीतियों को समायोजित करने के लिए बड़े टेपों का उपयोग करने की लागत छोटी होगी, फिर उसी रोलबैक विंडो का सम्मान करने के लिए नए, बड़े डिस्क खरीदने की लागत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.