आप एक भंडारण सर्वर का बैकअप कैसे लेते हैं?

Question

मैं कई अन्य सर्वरों (सभी लिनक्स-आधारित) के लिए लाइव एनएएस के रूप में उपयोग किए जाने वाले एक बहुत बड़े भंडारण सर्वर को लागू करने पर विचार कर रहा हूं।

बहुत बड़े पैमाने पर, मेरा मतलब 4TB और 20TB प्रयोग करने योग्य स्थान के बीच है (हालांकि इसकी संभावना नहीं है कि हम वास्तव में इसे 20TB बना देंगे)।

भंडारण सर्वर डेटा सुरक्षा और प्रदर्शन के लिए RAID 10 होगा, लेकिन हमें अभी भी बैकअप समाधान की आवश्यकता होगी जिसमें ऑफ-साइट बैकअप भी शामिल है।

मेरा सवाल है: आप इतना डेटा कैसे बैकअप करते हैं !?

ऐसा नहीं है कि मैं सिर्फ एक पोर्टेबल हार्ड-ड्राइव कनेक्ट कर सकता हूं और फाइलों को स्थानांतरित कर सकता हूं। वर्तमान में हमारे पास इस स्टोरेज स्पेस के साथ कोई अन्य डिवाइस नहीं है।

क्या मुझे दूसरे, ऑफ-साइट स्टोरेज सर्वर के लिए बजट की आवश्यकता है या कोई बेहतर उपाय है?

Comments

मैं ऑफ़लाइन होने के कारण अपनी सामान्य टिप्पणी को छोड़ देता हूँ। मैं एक बैकअप प्रणाली के बारे में वास्तव में घबरा जाता हूं जो हर समय "लाइव और ऑनलाइन" होती है। यदि कोई हमलावर आपके उत्पादन प्रणाली और आपके बैकअप पर पहुंच सकता है, तो वे आपके बैकअप को आपके उत्पादन सिस्टम को ट्रैश करने के बाद ठीक से रद्दी कर सकते हैं।

— इवान एंडरसन

@ इवान में मैं दोनों को शामिल करूंगा, टेप से पुनर्स्थापित करने में कई घंटे लग सकते हैं, लेकिन स्थानीय, या प्रत्यक्ष-संलग्न डिस्क को मिनटों में बहाल किया जा सकता है।

— टॉम ओ'कॉनर

जब आप इसे प्राप्त कर सकते हैं @Tim O'Connor: D2D2T बढ़िया है। ध्यान रखें कि डिस्क या टेप से अलग-अलग आइटम को पुनर्स्थापित करना बहुत तेज हो सकता है। डिस्क-आधारित बैकअप से बहाल करने के लिए तेज़ होने के लिए एक प्रतिष्ठा है, लेकिन ज्यादातर लोग "बी 2 डी मीडिया से सीधे डेटा तक पहुंच" सोच रहे हैं "जब वे कहते हैं कि" इसे पुनर्स्थापित नहीं करें। यदि आपको डिस्क-आधारित बैकअप सिस्टम से डेटा के टीबी के एक जोड़े को पुनर्स्थापित करना है, तो कहें, एक प्रतिस्थापन SAN आपके द्वारा आग में जलने के बाद उस डेटा को कॉपी करने के लिए "मिनट" नहीं होने जा रहा है। डेटा ट्रांसफर स्पीड के मामले में डिस्क और हाई-एंड टेप, बहुत समान हैं।

— इवान एंडरसन

Answer 1

डेटा को संभालने के कई तरीके हैं जो आकार का है। इसका बहुत कुछ आपके पर्यावरण पर और आपके द्वारा खर्च किए जाने वाले धन पर निर्भर करता है। सामान्य तौर पर सर्वर की रणनीतियों से डेटा प्राप्त करने के लिए कुछ समग्र होते हैं:

• ईथरनेट की तरह यह बॉक्स पर कहता है, डेटा को हैंडलिंग के लिए कुछ व्हेयर एल्स में स्ट्रीम किया जाता है। 20GB को 1GbE से अधिक समय लगेगा, लेकिन यह किया जा सकता है। हार्डवेयर मदद कर सकता है (जैसे 10GbE लिंक, या कुछ मामलों में एनआईसी बॉन्डिंग)।
• स्टोरेज सबसिस्टम पर यदि आप फाइबर चैनल पर हैं, तो इसे FC नेटवर्क पर किसी अन्य डिवाइस पर भेजें। यदि आपने एसएएस प्राप्त किया है, तो इसे एसएएस-संलग्न डिवाइस पर भेजें। आमतौर पर ईथरनेट की तुलना में तेजी से।
• इसे किसी अन्य डिस्क सरणी पर भेजें इसे एक ही सर्वर से जुड़े भंडारण के दूसरे हंक पर भेजें।

यह 100Km दृश्य है। एक बार जब आप चीजों को ज़ूम करना शुरू करते हैं तो बहुत अधिक खंडित हो जाते हैं। जैसा कि पहले ही उल्लेख किया गया है, LTO5 एक विशिष्ट टेप तकनीक है जो इस प्रकार के उच्च-घनत्व भार के लिए डिज़ाइन की गई है। एक और समान भंडारण सरणी एक अच्छा लक्ष्य है, खासकर यदि आप डेटा का उपयोग करने के लिए GlusterFS या DRBD जैसी किसी चीज़ का उपयोग कर सकते हैं। इसके अलावा, यदि आपको बैकअप रोटेशन की जरूरत है या बस फेल होने की क्षमता है तो एरे फेल होने पर जो आप डालते हैं उसे प्रभावित करेगा।

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

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

सरल प्रतिकृति करने में सबसे आसान है। यह वही है जो DRBD करने के लिए डिज़ाइन किया गया है। एक बार प्रारंभिक कॉपी हो जाने के बाद, यह सिर्फ परिवर्तन भेजता है। यहां जटिल कारक नेटवर्क स्थानीयता हैं, यदि आपका दूसरा सरणी प्राथमिक DRBD के पास नहीं है तो संभव नहीं है। आपको पहले की तरह कम से कम अधिक संग्रहण स्थान के साथ 2 संग्रहण सर्वर की आवश्यकता होगी।

---

टेप बैकअप के बारे में ...

LTO5 डेटा w / o कम्प्रेशन की 1.5TB पकड़ सकता है। इन राक्षसों को खिलाने के लिए बहुत तेज़ नेटवर्किंग की आवश्यकता होती है, जो कि या तो फाइबर चैनल या 6Gb SAS है। चूंकि आपको एक अजीब में 1.5TB से अधिक का बैकअप लेने की आवश्यकता होती है, इसलिए आपको ऑटोलॉजर्स में देखने की जरूरत है (यहां एक उदाहरण है: लिंक , एचपी से 24 स्लॉट 1-ड्राइव ऑटोलैडर)। सॉफ्टवेयर जो उनका समर्थन करता है, वे आपके लिए टैप-मिड-बैकअप बदलने का काम करेंगे। वे बहुत अच्छे है। आपको अभी भी ऑफ-साइट पर भेजने के लिए टेप को बाहर निकालना होगा, लेकिन यह एक लानत दृष्टि है जो रात भर अपने आप को लटकाए रखने से बेहतर है कि जब टेप उनके लिए कॉल करे।

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

---

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

Comments

लंबे और विचारशील उत्तर के लिए धन्यवाद। आपने मुझे बहुत कुछ दिया है: --p

— एंड्रयू एनस्ले

Answer 2

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

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

Comments

मैं टेप सिस्टम से परिचित नहीं हूँ। मैं अनुमान लगा रहा हूं कि वृद्धिशील बैकअप करने का कोई तरीका नहीं है। इसके अलावा, इसमें कई घंटे नहीं लगेंगे और इसमें एक के बाद एक टेप ड्राइव को मैन्युअल रूप से बदलना शामिल होगा? यह आदर्श नहीं होगा क्योंकि मैं केवल महीने में एक बार उस तरह का समय पाऊंगा, और हम वास्तव में एक महीने के डेटा को जोखिम में नहीं डालना चाहते हैं। क्या मुझे कुछ याद आ रहा है, या ये टेप बैकअप सिस्टम की केवल स्वीकृत असुविधाएँ / जोखिम / सीमाएँ हैं?

— एंड्रयू एनस्ले

आधुनिक टेप बैकअप सिस्टम अत्यधिक स्वचालित और रोबोट हैं :)

— फोएबस

हां, टेप बैकअप आमतौर पर वृद्धिशील बैकअप के लिए अनुमति देते हैं। एक अच्छी बैकअप रणनीति पूर्ण बैकअप (लंबे, धीमे, बहुत सारे टेप) मासिक या द्वि-वार्षिक करना है, और दैनिक वृद्धिशील या अंतर बैकअप को बीच में करना है।

— ब्रेंट

टेप रोबोट यथोचित मूल्य हैं और कई टेपों को धारण करते हैं। जहां तक ​​बैकअप करने की बात है, तो इंक्रीमेंट करने का कोई तरीका क्यों नहीं होगा? अंत में, ज्यादातर लोग बैकअप को घंटों के दौरान चलाने के लिए ट्रिगर करते हैं। यदि आपके पास वे नहीं हैं, तो यह विनिर्देश का एक महत्वपूर्ण हिस्सा है।

— Slartibartfast

हाँ, हमारे पास वास्तव में घंटे नहीं हैं। हमारे पास ऐसे घंटे हैं जहां यह सिस्टम के अनुपलब्ध होने के लिए अधिक स्वीकार्य होगा (जैसे कि शनिवार सुबह 4 बजे), लेकिन संभावित रूप से सैकड़ों उपयोगकर्ताओं द्वारा प्रभावित सिस्टम का उपयोग 24/7 किया जाएगा।

— एंड्रयू एनस्ले

Answer 3

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

निश्चित रूप से अंतर या वृद्धिशील बैकअप का लाभ उठाएं - केवल आपके लिए जो भी समझ में आता है, उसमें परिवर्तन का समर्थन करता है।

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

जब आप उस डेटा के साथ काम कर रहे होते हैं, तो यह आपके बैकअप को छोटे बैकअप नौकरियों में तोड़ने के लिए भी समझ में आता है , और यदि वे हर दिन बैकअप नहीं ले सकते हैं, तो अपने बैकअप को स्टैगर करें ताकि सेट एक दिन में वापस हो जाए, और अगले बी सेट करें।

हमेशा पुनर्स्थापना प्रक्रिया के बारे में सोचें । हमें एक बार ठोकर लगी जब हमें कई सौ-सौ-गज बैकअप नौकरी से एक फ़ाइल को पुनर्स्थापित करना पड़ा, जिसने बैकअप इंडेक्स को फिर से बनाने और पुनर्स्थापित करने के लिए बहुत सारी मेमोरी और बहुत समय लिया। अंत में हम इसे एक दिन में पूरा नहीं कर सके, और हमारे मुख्य बैकअप सर्वर को रात के काम को जारी रखने की अनुमति देने के लिए एक समर्पित पुनर्स्थापना सर्वर का निर्माण करना पड़ा!

--added--

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

Comments

के लिए +1 thinking about the restore procedure। तथास्तु!

— स्टीवन सोमवार

बहुत बढ़िया टिप्स। धन्यवाद। मेरे पास करने के लिए बहुत सोच है।

— एंड्रयू एन्स्ले

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

— इवान एंडरसन

@ इवान: निष्पक्ष होने के लिए, उन्होंने पहले वाक्य में टेपों का उल्लेख किया।

— एंड्रयू एनस्ले

Answer 4

सबसे पहले, उन जोखिमों की गणना करें जिनसे आप बचाव कर रहे हैं। कुछ सामान्य जोखिम:

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

फिर विभिन्न जोखिम परिहार समाधानों की लागत का मूल्यांकन करें, जैसे:

• ऑफ-साइट, ऑन-लाइन बैकअप (दूरस्थ दर्पण): आपदा से सुरक्षित, कुछ (लेकिन सभी नहीं) मानव त्रुटि (यह अभी भी ऑन-लाइन है)।
• ऑफ-साइट ऑफ-लाइन स्टोरेज (टेप): आपदा से सुरक्षित, डेटा को जल्दी से पुनर्प्राप्त करना कठिन।
• ऑन-साइट ऑन-लाइन बैकअप (दर्पण): कुछ मानवीय त्रुटि से सुरक्षित, कुछ हार्डवेयर विफलता, आपदा की चपेट में।
• ऑन-साइट ऑफ-लाइन बैकअप (टेप चेंजर में टेप): अधिकांश मानव त्रुटि, अधिकांश हार्डवेयर विफलता से सुरक्षित।

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

फिर जो आपका डेटा है, उसे चुनें।

Comments

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

— एंड्रयू एनस्ले

मैं खुश हूं कि मैं मदद कर सका। आपके चुने हुए समाधान के बारे में कुछ टिप्पणियां: यह बिना कहे चल सकती है, लेकिन बैकअप साइट संभवतः किसी अन्य राज्य में या आपके द्वारा किए जा रहे tbe तूफान से अच्छी तरह से संरक्षित जगह पर होनी चाहिए। आप एक लंबी 'पूंछ' (अतीत में तारीखों की एक विस्तृत श्रृंखला से बैकअप) होने से भ्रष्टाचार की चिंताओं को कम कर सकते हैं। एक ऑनलाइन बैकअप के साथ, आप डेटा को पुनर्स्थापित करने के बजाय गलती से हटाने के खतरे पर भी विचार करना चाहते हैं। अंत में, हमेशा अपनी पुनर्स्थापना प्रक्रिया का परीक्षण करें।

— Slartibartfast

Answer 5

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

Answer 6

ऑफ-साइट, ऑन-लाइन बैकअप (दूरस्थ दर्पण)

rsync का उपयोग करें यद्यपि ssh (केवल परिवर्तन) - पहला बैकअप स्थानीय रूप से किया जाना है, लेकिन उसके बाद बैकअप परिवर्तन के आधार पर एक हवा होगी

यदि आपको परिवर्तनों के साथ संस्करण रखने की आवश्यकता है- rdiff-backup

http://www.nongnu.org/rdiff-backup/

लिनक्स में btrfs फाइल सिस्टम आशाजनक लगता है, लेकिन फिर भी भारी विकास पर है

Comments

मुझे rdiff की ओर इशारा करने के लिए धन्यवाद। मैं पहले से ही rsync का उपयोग करता हूं, और यह उसी से परिपूर्ण कदम की तरह दिखता है।

— एंड्रयू एन्स्ले

Answer 7

अपनी वास्तविक "सामग्री" पर एक नज़र डालें और अपनी रणनीति की योजना बनाने से पहले यह कितनी बार बदलता है। कई बार लोग बिना किसी अच्छे कारण के एक ही डेटा को साप्ताहिक रूप से टेप करने के लिए मंथन करते हैं।

कुछ विक्रेताओं से Deduplication प्रौद्योगिकियां स्नैपशॉटिंग को आपको व्यक्तिगत फ़ाइल पुनर्स्थापना से बचाने की अनुमति दे सकती हैं लेकिन आपको सुरक्षा के लिए हमेशा ऑफ़साइट की आवश्यकता होगी।

Comments

इस प्रणाली का उपयोग हजारों संभवत: हजारों दैनिक उपयोगकर्ता प्रपत्रों को दर्ज करने और जानकारी अपडेट करने में करेंगे। यह अत्यधिक गतिशील डेटा है। मुझे उस प्रश्न में उल्लेख करना चाहिए था।

— एंड्रयू एनस्ले

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

— SpacemanSpiff

मैं सहमत हूँ। जैसा कि मैंने पहले कहा, ड्राइव RAID 10 में होंगे, इसलिए हम हार्ड ड्राइव की विफलता के मामले में शामिल हैं, और मेरे पास स्थानीय बैकअप / स्नैपशॉट भी होंगे। ऑफसाइट बैकअप सबसे खराब स्थिति के लिए है जैसे कि एक उल्का सह-ट्रेस को मारता है या कोई गलती से स्टोर सर्वर पर rm -rf / * चला रहा है।

— एंड्रयू एनस्ले

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

— SpacemanSpiff