क्या स्नैपशॉट + RAID एक अच्छे ऑन-साइट बैकअप समाधान के रूप में गिना जाता है?


19

जब मैं बैकअप लेने के लिए सोच सकता हूं, तो दो मुख्य कारणों पर ध्यान दिया जाना चाहिए जब मैं स्नैपशॉट और RAID दोनों का एक साथ उपयोग करता हूं। (यहां RAID द्वारा, मेरा मतलब है RAID1 या 10)

  • डेटा का आकस्मिक विलोपन: स्नैपशॉट इस मामले को कवर करता है
  • एक ड्राइव और बिट सड़ांध की विफलता
    • पूर्ण विफलता: RAID इस मामले को शामिल करता है
    • खराब डेटा लौटाते हुए ड्राइव करें: RAID + btrfs की त्रुटि सुधारने की सुविधा इस मामले को कवर करती है

इसलिए ऑन-साइट बैकअप समाधान के रूप में, यह ठीक काम करता है, और इसके लिए इसे अलग डेटा स्टोरेज डिवाइस की भी आवश्यकता नहीं है!

हालांकि, मैंने सुना है कि RAID और स्नैपशॉट दोनों को उचित बैकअप नहीं माना जाता है, इसलिए मैं सोच रहा हूं कि क्या मैंने कुछ भी याद नहीं किया है।

Btrfs के अलावा अभी तक एक परिपक्व तकनीक नहीं है, क्या आप कुछ भी सोच सकते हैं जो मैंने याद किया है? या क्या मेरी सोच सही है और यह एक वैध ऑन-साइट बैकअप समाधान है?


2
हम आपके जैसे ही काम करते हैं: RAID 5 छाया प्रति के साथ; हालाँकि हमारे पास दो ऑफ-साइट USB हार्ड ड्राइव हैं जो हर रात रोबोकॉपी का उपयोग करके बैकअप लेते हैं (सप्ताह में दो बार ड्राइव को घुमाते हैं ताकि एक हमेशा ऑफ-साइट हो)। यह हमें आपदा वसूली के लिए बैकअप प्रदान करता है, लेकिन दीर्घकालिक अभिलेखागार नहीं है, जिसे हमारे छोटे संगठन को वास्तव में आवश्यकता नहीं है। आपको कम से कम अपने सर्वर पर डेटा की ऑफ-साइट प्रतिलिपि अपग्रेड करनी चाहिए जैसे कि आपका RAID सरणी मर जाता है, आप अपने स्नैपशॉट भी खो देंगे।
ऑस्टिन '' डेंजर '' पॉवर्स

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

हां, हमारे पास पहले से ही ऑफ-साइट बैकअप और अधिक "पारंपरिक" ऑन-साइट समाधान है। मैंने यह सवाल इसलिए पूछा क्योंकि मैंने btrfs और ZFS की विशेषताओं के बारे में पढ़ा था, और सोच रहा था कि क्या यह ऑन-साइट बैकअप के लिए प्रतिस्थापन के रूप में उपयुक्त है।

जवाबों:


42

नहीं यह नहीं।

क्या होता है जब आपका फाइल सिस्टम या RAID वॉल्यूम दूषित हो जाता है? या आपके सर्वर में आग लग जाती है? या कोई गलती से गलत सरणी प्रारूपित करता है?

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


इस समाधान के बारे में कैसे, क्योंकि मैं अक्सर इसमें भाग लेता हूं? क्या स्थानीय स्नैपशॉट + दूरस्थ स्नैपशॉट किसी अन्य सर्वर (ऑनसाइट या ऑफ़साइट) + RAID दोनों सिस्टम पर पारंपरिक बैकअप के लिए एक प्रतिस्थापन है?
इविती

5
@ फिर से मान लें कि वे पुन: परीक्षण किए गए हैं, और आपके डेटा की एक पूरी प्रतिलिपि दूरस्थ प्रणाली पर मौजूद है, निश्चित है। फिर यह मूल रूप से डिस्क-टू-डिस्क बैकअप है ... और मैं डिस्क-टू-डिस्क बैकअप से प्यार करता हूं।
हॉपलेसनब बी

11

के लिए साइट पर बैकअप, स्नैपशॉट हो सकता है , अच्छा पर्याप्त हो , बशर्ते कि आप नियमित रूप से 'निर्यात' कहीं और स्नैपशॉट, जहां यह निष्क्रिय डेटा के रूप में मौजूद है।

और, नियमित रूप से परीक्षण करें कि क्या आपका 'भेज दिया स्नैपशॉट' बहाल किया जा सकता है।

यह है कि मैंने अपने कुछ सर्वरों का त्वरित बैकअप कैसे लागू किया है: ZFS पर डेटा संग्रहीत करें, ZFS स्नैपशॉट लें, डेल्टा को किसी अन्य सर्वर पर भेजें , जहां पूरे फाइल सिस्टम को फिर से बनाया गया है (वास्तविक सेवा चल रही है)।

बेशक, सबसे अच्छा बैकअप हमेशा ऑफ-साइट है। इस प्रकार, स्नैपशॉट को अलग सिस्टम पर 'शिपिंग' करने के बाद, नियमित रूप से स्नैपशॉट का 'टेप-आउट' करें।

इसलिए, मेरे सिस्टम में, जो सर्वर स्नैपशॉट डेल्टा प्राप्त करता है, नियमित रूप से अपने सभी ZFS पूल (पहले के स्नैपशॉट सहित) को टेप करने के लिए डंप करता है।

और हां, यह सुनिश्चित करने के लिए अपने टेप-आउट का परीक्षण करें कि इसे बहाल किया जा सकता है।

नोट: आप चाहते हैं कि स्नैपशॉट क्विज़र्ड डिस्क गतिविधि के दौरान हो, और अधिमानतः सुनिश्चित करने के लिए डेटाबेस (यदि कोई हो) के साथ समन्वय में; अन्यथा, बीमारी से इलाज बदतर हो सकता है। यही कारण है कि NetApp और EMC 'लाइव स्नैपशॉट' सुविधा बहुत उपयोगी है: वे LUN के स्नैपशॉट को स्थगित कर देंगे जब तक कि LUN का उपयोग करने वाले डेटाबेस ने संकेत नहीं दिया कि स्नैपशॉट को बाहर ले जाना सुरक्षित है।


क्या आप विस्तार से बता सकते हैं कि आपने अपने ZFS स्नैपशॉट को टेप करने के लिए कैसे डंप किया?
इविहित

@ फिर भी आप हमेशा .zfs/snapshotsडायरेक्टरी का बैकअप ले सकते हैं , या टेप-आउट करने के लिए किसी एक स्नैपशॉट को माउंट कर सकते हैं । तो यह अलग स्नैपशॉट के लिए एक अलग बैकअप है।
पेपोलुआन

मैं यह zvols के साथ कर रहा हूँ, वास्तव में ... तो मैं करने के लिए एक .zfs निर्देशिका नहीं है cd
इविहित

@ewwhite आह, मैं देख रहा हूँ ... उस मामले में, आप कर सकते हैं का उपयोग कर सकेंगे zfs send $SNAPSHOT_NAME > $YOUR_TAPE_DEVICE, और बाद में एक ऐसा zfs receive $RESTORE_NAME < $YOUR_TAPE_DEVICE। हालांकि, मैं ईमानदारी से zvols समर्थन के साथ अनुभव नहीं है, हालांकि ...
पेपोलुआन

8

HopelessN00b ने क्या कहा। नहीं।

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

(उपाख्यान चेतावनी: मैंने एक बार किसी ऐसे व्यक्ति के बारे में सुना था जिसने नवीनतम फेडोरा को ऑटो-इंस्टाल करने के लिए पीएक्सई सेट किया था। उसका यूपीएस विफल हो गया। पावर आउटेज के बाद, उसके सर्वर ने रिबूट किया और पीएक्सई बूट पर सेट किया गया और ... फेडोरा को अपने डेटा पर स्थापित किया। बिंदु; अजीब चीजें होती हैं। सौभाग्य से, उसके पास उचित बैकअप था। '

अधिमानतः, आपके पास अपने डेटा की कम से कम तीन प्रतियां हैं, डेटा सेंटर के जलने की स्थिति में एक पूरी तरह से ऑफसाइट संग्रहीत होती है।


6

उचित रूप से लागू किए गए स्नैपशॉट आपके स्टोरेज द्वारा समर्थित होने चाहिए क्योंकि एक बैकअप जॉब बनाने के पहले चरण के रूप में सभ्य बैकअप उनका उपयोग करते हैं। हालांकि प्राथमिक बैकअप के लिए स्नैपशॉट का उपयोग करना एक बुरा विचार है। कारण:

1) स्नैपशॉट और बैकएंड स्टोरेज विफल हो सकते हैं। इसलिए असली बैकअप को अलग-अलग स्पिंडल सेट का उपयोग करना चाहिए या एक ही समय में प्राथमिक कार्य सेट और बैकअप डेटा दोनों को खोने का एक शानदार मौका है।

2) स्नैपशॉट्स "चबाने योग्य स्थान" को चबाते हैं। यह वर्तमान हॉट डेटा और ऑफ-लोड स्नैपशॉट और बैकअप के लिए महंगे और तेज़ स्टोरेज का उपयोग करने के लिए समझ में आता है, जो कुछ सस्ते और धीमे स्टोरेज के लिए बर्फ का ठंडा डेटा है। यह 1) BTW के साथ बहुत अच्छी तरह से काम करता है।

3) स्नैपशॉट आमतौर पर पूरे प्रॉसेस को धीमा कर देते हैं। अधिकांश सिस्टम कॉपी-ऑन-राइट का उपयोग करते हैं और यह दृष्टिकोण विखंडन पैदा करता है। रीडायरेक्ट-ऑन-राइट तेज़ हैं लेकिन A LOT को खाएं। बहुत कम विक्रेताओं ने स्नैपशॉट को ठीक से लागू किया है। CASL के साथ WAFL और निम्बल स्टोरेज के साथ NetApp (मैं उनमें से किसी के साथ भी प्रभावित नहीं हूं)। बहुत ज्यादा हर कोई मुद्दों है। उदाहरण के लिए डेल इक्वलोगिक ट्रिगर हर एक बाइट पर 15 एमबी पेज अपडेट (और अपशिष्ट) बदल गया। वो तो महंगा है।


6

हाँ यही है। यह बैकअप स्टोर करने का एक सही तरीका है। कुछ और की जरूरत नहीं है, बिल्ली, यहां तक ​​कि निपुणता की जाँच भी समय बर्बाद कर रहे हैं।

बस पुष्टि करने के लिए - इससे पहले कि मैं और अधिक सलाह दूं ... आप मेरे एक प्रतियोगी के लिए काम करते हैं, है ना? तुम सच में, यकीन है? नहीं? ओह।

क्षमा करें, एनयूटीएस। नहीं, बिलकुल नहीं। माफ करना दोस्त।

समस्या यह है कि आप किसी भी त्रुटि के लिए पूरी तरह से खुले हैं जो (a) सिस्टम और (b) ऑपरेटिंग सिस्टम स्तर पर होता है। आप मूल रूप से केवल किसी डेटा को हटाने वाले किसी व्यक्ति से बचाते हैं। अच्छा लगा। यह अक्सर एक त्रुटि होती है।

आप किससे रक्षा नहीं कर रहे हैं:

  • मशीन को पोंछते हुए एक पावर स्पाइक। वहां देखा, देखा कि।
  • डिस्क पर कुछ दोषपूर्ण छापे नियंत्रक या मेमोरी राइटिंग ** - कुछ भी हो जाता है।

और अन्य चीजों की एक लंबी सूची।

यह है - स्वाभाविक रूप से, जब तक आप मेरे एक प्रतियोगी के लिए काम नहीं करते हैं - आप हमेशा एक बैकअप बनाते हैं:

  • दूसरे कंप्यूटर पर
  • कि आप कम से कम पावर स्पाइक्स से अलग हो जाते हैं (भले ही आप एक यूएसवी को आगे बढ़ाते हों)।

यही कारण है कि टेप रॉक - वे जुड़े हुए नहीं हैं और कुछ भी कम ओए आग या बाढ़ उन्हें चोट नहीं पहुंचाएगी। पावर स्पाइक - वहाँ टेप रीडर और शायद रोबोट जाता है, लेकिन रीडर में नहीं टेप प्रभावित होने वाले नहीं हैं।

BEST बैकअप ऑफसाइट होगा (क्या मैंने आग और बाढ़ जैसे सामान का पहले ही उल्लेख किया है?) (फिर, जब आप एक प्रतियोगी के लिए काम करते हैं - बिल्डिंग फायर जैसी कोई चीज नहीं है, यह पूरी तरह से आवश्यक नहीं है, जैसा कि अग्नि बीमा है, कृपया;) उस पैसे को बचाओ)।

अब, आप सोच सकते हैं "ओह, बाढ़ कभी नहीं होती है"। सुनिश्चित करें कि आप सुनिश्चित हैं। देखिए, यहां एक 09.09.09 वोडाफोन डाटासेंटर की बाढ़ का वीडियो है। मुझे यकीन है कि आप समझ जाएंगे कि यह मुद्दा इंसर्ट / कंप्यूटर बैकअप में कहां है:

http://www.youtube.com/watch?v=ttcQy3bCiiU


तूफान सैंडी तस्वीरें: theverge.com/2012/11/17/3655442/…
कैथरीन विलिअर्ड

4

सबक एक दूसरे के आधे घंटे में नाकाम रहने दो RAID -1 ड्राइव से सीखा: RAID है नहीं , एक बैकअप तंत्र नहीं किसी भी तरह से, आकार या रूप में।

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


1
हार्डवेयर विफलता के कुछ वर्गों के मामले में । यदि RAID कार्ड विफल हो जाता है, तो आपके कंटेनर चले गए हैं।
mfinni

3

कई अनुभवी प्रशासक बैकअप के 3-2-1 नियम के रूप में जाने जाते हैं:

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

  • आपको कम से कम दो अलग-अलग बैकअप विधियों का उपयोग करना चाहिए।

  • आपके पास अपने डेटा की कम से कम एक ऑफ-साइट कॉपी होनी चाहिए।

स्नैपशॉट तीनों भागों का उल्लंघन करते हैं:

  • आप केवल एक ही भौतिक मशीन का उपयोग करते हैं। पूरी मशीन को प्रभावित करने वाली कोई भी चीज़, जैसे कि PSU की विफलता, आपके सभी डेटा को अपने साथ ले जा सकती है।

  • आप केवल अपने बैकअप के लिए एक ही विधि का उपयोग कर रहे हैं। यदि इसके साथ कुछ भी गलत है, तो आप केवल एक संकट की स्थिति में बैकअप को पुनर्स्थापित करते समय पता लगाएंगे।

  • आपके पास कोई बैकअप ऑफ-साइट नहीं है। बाढ़ और आग केवल दूसरों के लिए ही होती है, जब तक कि वे आपके साथ न हों ...

इसलिए:

  • आपको अपने LAN पर एक अलग मशीन पर कम से कम एक बैकअप रखना होगा ।

  • आपको कम से कम एक बैकअप रखना होगा जो स्नैपशॉट का उपयोग करके उत्पन्न नहीं होता है। शायद एक अच्छा-पुराना वृद्धिशील tarसंग्रह क्रम में हो सकता है? या एक rsyncआधारित प्रति?

  • आप अपने वर्तमान स्थान से कम से कम एक दूरदराज के बैकअप, जहाँ तक संभव हो और करने की जरूरत है निश्चित रूप से एक ही इमारत में नहीं।

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

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

अंत में, ध्यान रखें कि अभी हम केवल आपके वर्तमान डेटा की प्रतियों के बारे में बात कर रहे हैं । विफलताओं (या उस मामले के लिए सुरक्षा उल्लंघनों) के खिलाफ चौकसी करने के लिए, जो कुछ समय के लिए अनिर्धारित हो जाते हैं, आपको कुछ समय पहले अपने डेटा की कई पिछली प्रतियां भी रखनी होंगी।


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

2

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

यह निश्चित रूप से एक अधिक गोल उपलब्धता + बैकअप समाधान का एक बहुत ही मूल्यवान हिस्सा हो सकता है:

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

इसके अलावा: सुनिश्चित करें कि आप नियमित रूप से अपने बैकअप का परीक्षण करते हैं। अपने बैकअप को खोजने के लिए सबसे खराब समय काम नहीं कर रहा है, जब आपको उनसे कुछ प्राप्त करने की आवश्यकता होती है ...

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.