क्या डेटा की एक पेटाबाइट बैकअप और इसे स्टोर करने का एक अच्छा तरीका है?


19

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

स्पष्ट मुद्दा यह है कि एंटरप्राइज़-क्लास स्टोरेज, हेक, यहां तक ​​कि सिर्फ RAID-5 का उपयोग करके, उस डेटा के कई बैकअपों को संग्रहीत करना बहुत महंगा है।

मेरे द्वारा देखे गए विकल्प इस प्रकार हैं:

  1. किसी अन्य डेटा-सेंटर में डेटा की एक मिरर कॉपी बनाएं, और इसे लगातार अंतर करें (जो भी तंत्र आपके डेटा स्रोत के लिए उपलब्ध है - जैसे लॉग-शिपिंग या SQL सर्वर के साथ मिररिंग का उपयोग करके)
  2. एक नियमित संपीड़न एल्गोरिथ्म का उपयोग करके नियमित बैकअप लें (संभवतः केवल तभी उपयुक्त हो जब डेटा भारी रूप से संकुचित होने के लिए अच्छी तरह से उधार देता है )
  3. डेटा के महत्वपूर्ण / बदलते भागों के टुकड़े का बैकअप लें।
  4. डेटा का बैकअप न लें और भ्रष्टाचार-देवताओं पर भरोसा करें।

मैं विकल्प 4 को डिफ़ॉल्ट के रूप में अपनाया जा रहा हूं, और एक HA / DR विशेषज्ञ के रूप में यह वास्तव में डरावना है, लेकिन मैं एक विकल्प के रूप में क्या सलाह देता हूं? मुझे लगता है कि # 1 सबसे अच्छा दृष्टिकोण है, लेकिन "मुझे ऐसा नहीं लगता" सामान्य उत्तर है जब # 4 के अलावा कोई विकल्प और संभवतः # 3 का सुझाव दिया जाता है।

अब, निश्चित रूप से यह डेटा की परिवर्तन-दर और आलोचना पर निर्भर करता है। इस बात का जवाब देने की आवश्यकता नहीं है कि जैसा कि मैंने Microsoft पर काम करते समय SQL सर्वर के सभी HA फीचर्स के लिए ज़िम्मेदार हुआ करता था, इसलिए मैं 'यह निर्भर करता है ’तर्कों पर अच्छी तरह से वाकिफ है - यह मेरा कैच-वाक्यांश है :-)

मैं किसी भी ऐसे विकल्प के बारे में सुनने में दिलचस्पी लेता हूँ जिसे मैंने याद किया है, या यह सुनने के लिए कि हर कोई एक ही नाव में है और अधिक भंडारण पर बहुत सारे पैसे खर्च करने का कोई वास्तविक विकल्प नहीं है।

अग्रिम धन्यवाद - उचित क्रेडिट सभी सुविचारित और व्यक्त उत्तरों को दिया जाएगा।


डेटाबेस को अपडेट के पैमाने के बारे में कुछ विचार होने से बैकअप विकल्पों में अंतर होगा।
डेव डस्टिन

1
और अनुवर्ती सवाल - क्या पेटाबाइट डेटाबेस का बैकअप बहाल करने का एक अच्छा तरीका है?
रोब बोके

"यह निर्भर करता है" जोएल स्पोल्स्की का कैच वाक्यांश भी है। इसके लिए आपको उससे लड़ना पड़ सकता है!
निक कावडिया

मुझे बस इतना पसंद है कि "डेटा को कैसे स्टोर करें" के मुख्य प्रश्न को "आप डेटा को स्टोर करने की आवश्यकता क्यों है?" यह हथौड़ा के बारे में मजाक जैसा है: क्या आपके पास हथौड़ा है जो मैं उधार ले सकता हूं? तुम्हें यह क्यों चाहिए? मुझे एक कील हथौड़ा करने की आवश्यकता है। आपको ऐसा करने की आवश्यकता क्यों है? छत गिराने के लिए। आपको छत की आवश्यकता क्यों है? ताकि मेरे घर में बारिश न हो। ओह - माफ करना, मेरे पास हथौड़ा नहीं है।
एंड्री Drozdyuk

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

जवाबों:


6

दीवार के विचार से - क्या संग्रहित सभी जानकारी आवश्यक है या उपयोगी भी है?

सूचना वास्तव में कितनी है? यह स्पष्ट रूप से हास्यास्पद है कि डेटा के लायक होने से अधिक प्रबंधन और प्रबंधन में खर्च करना मुश्किल है।

क्या डेटाबेस में डेटा डेटाबेस में भंडारण के लिए उपयुक्त है? उदाहरण के लिए, समर्थन संगठन के डेटाबेस में बहु-गीगाबाइट कोर फ़ाइलों को रखने से वास्तव में कोई वास्तविक लाभ मिलता है?

क्या डेटाबेस में बहुत अधिक डुप्लिकेट डेटा है? उदाहरण के लिए, क्या एक साप्ताहिक 10MB समाचार पत्र में दस प्रतियाँ रखने वाले एक हजार लोग हैं?

क्या कुछ डेटा की "समाप्ति तिथि" होती है जिसके बाद यह कोई मूल्य प्रदान नहीं करता है? समर्थन संगठन के उदाहरण पर लौटना, विभिन्न कारणों से एक फिक्स डिलीवरी के बाद कुछ महीनों से अधिक ग्राहक कोर फ़ाइलों को रखने में कोई लाभ नहीं है।

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


6

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

चालाक भाग यह है कि पूरी प्रक्रिया शामिल सर्वरों के लिए अदृश्य है। यदि आप SQL सर्वर का उपयोग कर रहे हैं, तो आप अपने फ़ाइल समूह को एक कम परिवर्तन दर के साथ रखने के लिए डिज़ाइन करते हैं (जैसे बिक्री अभिलेखागार से> 3 साल पहले), और उच्च फ़ाइल दर (वर्तमान बिक्री की तरह) के साथ चीजें एक अलग फ़ाइल समूह पर। उन्हें पूरी तरह से केवल पढ़ने के लिए भी नहीं है - आप बस इसे डिज़ाइन करना चाहते हैं ताकि आप प्रत्येक फ़ाइल समूह के लिए अलग-अलग प्रतिकृति विधियों का उपयोग कर सकें। SAN गियर नेटवर्क, टेप के माध्यम से या SANs के माध्यम से luns को सिंक कर सकता है - मतलब, आप SAN के भागों को आगे और पीछे शिप कर सकते हैं। यह लेफ्टहैंड जैसे गियर के साथ अधिक प्रभावी है, जहां सैन भाग लेने वाली इकाइयों के पूल से बना है।

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

मैंने इसे पेटाबाइट स्तर पर नहीं किया है, हालांकि। आप जानते हैं कि वे क्या कहते हैं - सिद्धांत रूप में, सिद्धांत रूप में और व्यवहार में समान हैं। प्रयोग में...


हाय ब्रेंट, वहाँ हार्डवेयर उपलब्ध है जो SAN स्तर पर डेटा को संपीड़ित करता है?
सुपरकूलमॉस

SuperCoolMoss - हां, बिल्कुल। उदाहरण के लिए, अब NetApp अपने SANs में मुफ्त में बंडल करता है। अपने SAN विक्रेता से पूछें और पूछें कि वे क्या समाधान प्रस्तुत करते हैं।
ब्रेंट ओजर

और आपका स्वागत है, पॉल। :
ब्रेंट ओजर

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

3

विकल्प 1 मिररिंग है, जो # 4 के रूप में लगभग खराब है: किसी भी बग जो डेटा को दूषित करता है, और तुरंत खोजा नहीं जाता है, दोनों प्रतियों को दूषित करेगा।

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


SQL सर्वर जहाजों में डेटाबेस मिररिंग रिकॉर्ड्स, भौतिक पृष्ठ नहीं तो अधिकांश भ्रष्टाचार दर्पण की नकल नहीं करते हैं। हाँ, कुछ भी जो विभाजन-दर्पण + बैकअप लेने की अनुमति देता है, लेकिन फिर भी समस्या से बचा हुआ है कि लानत चीज़ कहाँ डालनी है यदि उसका पी.बी. लेकिन कुछ भी जो केवल SQL सर्वर से भिन्न-मूल-से-मूल (जैसे db स्नैपशॉट) अंतर्निहित स्रोत डेटा के भ्रष्टाचार के लिए अतिसंवेदनशील है, जिससे बेकार भी भिन्न होता है। क्या आपने टेप पर पीबी स्टोर करने की कोशिश की है + आपदा वसूली के दौरान इसे बहाल करना? डाउनटाइम के दिन :-( हालांकि अभी भी कुल डेटा-नुकसान से बेहतर है। उत्तर के लिए धन्यवाद!
पॉल रैंडल

3

उन लोगों को इंगित करें जो डेटा की एक पेटाबाइट को स्टोर करना चाहते हैं जो भंडारण सस्ता नहीं है।

मैं ऑनलाइन स्टोरेज के अतिरिक्त टेराबाइट नहीं होने के बारे में विलाप कर रहे लोगों से इतना तंग आ गया हूं क्योंकि डिस्क सस्ती है - डिस्क हो सकती है, लेकिन स्टोरेज सुनिश्चित है क्योंकि नरक नहीं है।

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

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

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


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

1
मैं सहमत हूँ। यदि आप बैकअप समाधान नहीं कर सकते हैं, तो आप भंडारण का खर्च नहीं उठा सकते हैं। बहुत सारे लोग भंडारण को डिस्क की कीमत के रूप में देखते हैं।
मार्क हेंडरसन

3

दिलचस्प वीडियो myspace.com की वास्तुकला (SQL2005 बैकएंड) का विवरण। सुनिश्चित नहीं हैं कि उनके पास अलग-अलग पेटाबाइट हैं क्योंकि वे कई डीबीएस के साथ स्केल करते हैं। वे सैन स्नैप बैकअप का उपयोग करते हैं।

http://wtv.watchtechvideos.com/topic70.html


2

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

एक तरीका स्नैपशॉट का उपयोग करना है। एक स्नैपशॉट लें, जिसे दूरस्थ स्थान पर स्थानांतरण के लिए टेप / डिस्क / नेट पर भेजें। इसके बाद स्नैपशॉट केवल भेजे गए डेटा को भेजते हैं, और यदि आवश्यक हो तो आप दोनों सिरों पर लाइव डेटा रख सकते हैं।

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

और आप कहते हैं कि ZFS विंडोज पर समर्थित नहीं है, सामान्य स्थान जिसे आप sqlserver खोज सकते हैं, हो सकता है कि आप Sunend / ZFS को बैकेंड पर चलाएं और iSCSI के माध्यम से कनेक्ट करें। हो सकता है कि यह एक भयानक विचार भी है, लेकिन यह कम से कम कुछ विचार देने के लायक है ताकि आप जान सकें कि क्या नहीं करना है।


दिलचस्प विचार - जिसके पास इस तरह के विचारों के साथ खेलने के लिए कुछ और हार्डवेयर थे।
पॉल रैंडल

2

क्या आपने विकल्प के रूप में अमेज़ॅन ग्लेशियर में देखा है?


डेटा पुनर्प्राप्त करना हालांकि कंपनी को दिवालिया कर सकता है।
टॉम ओ'कॉनर

1

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

फ़ाइलग्रुप आधारित बैकअप (IOW, गैर-वाष्पशील डेटा को कुछ FGs और बैक अप अपग्रेड पर डालते हैं) कभी नहीं लगता है क्योंकि devs या उपयोगकर्ता यह तय नहीं कर सकते हैं कि कौन सा डेटा अस्थिर है और क्या नहीं है, और ब्राउनफ़ील्ड में परिदृश्य जो आप अक्सर जोखिम नहीं उठा सकते।

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


मैं वास्तव में उस समय का इंतजार कर रहा हूं जब मुझे डेटा डेडअप स्टोरेज समाधान मिल सकता है। यह जल्द ही किसी भी समय होने वाला नहीं है, लेकिन मेरे डेटा की प्रकृति संभवतः 75% के आकार-प्रकार-डिस्क में कटौती की ओर ले जाएगी
मैट सीमन्स

हाँ - बैकअप संपीड़न मेरा विकल्प 2 है, लेकिन अक्सर एक और डीसी की आवश्यकता होती है। मुझे लगता है कि एक दूरस्थ SAN के विचार के साथ LUNS को अलग करने के विभिन्न तरीके हैं। धन्यवाद
पॉल रैंडल

1

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

तो आप डिस्क बैकअप के लिए नीचे हैं। आप संस्करण कर रहे हैं? मतलब क्या आप बैकअप 2 (वर्तमान db माइनस 2 बैकअप) पर वापस जाने के बारे में चिंता करते हैं? या बैकअप 3? उस स्थिति में, आपके पास समस्याएँ हो सकती हैं, लेकिन संभावना है कि आपको जो भी संभालना है वह लॉग बैकअप है, न कि इतना डेटा बैकअप।

यदि आप कुछ डेटा को केवल-पढ़ने / न बदलने वाले के रूप में विभाजित कर सकते हैं, तो शायद आपके पास प्रबंधनीय बैकअप आकार / विंडो हैं। या कम से कम आप उम्मीद कर रहे हैं कि बैकअप तकनीक और बैंडविड्थ डेटा वृद्धि के साथ पकड़ रहा है।

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

मुझे लगता है कि आपको उत्कृष्ट लॉग बैकअप प्रबंधन के साथ 1, 2 और 3 (4 नहीं) के संयोजन की आवश्यकता है।

वास्तव में मुझे लगता है कि किसी भी समय आप अपने डेटा की 3 प्रतियों को देख रहे हैं। 2 प्रतियों में से 1 पर चल रहे CHECKDB, जबकि दूसरी प्रतिलिपि वास्तव में परिवर्तन प्राप्त करने के लिए उपयोग की जा रही है। तब आप उस 2 को पहली बार कॉपी करते हैं और जारी रखते हैं। इस डेटा के साथ, मुझे लगता है कि आपको यहाँ कुछ परिश्रम की आवश्यकता होगी। पॉल, बहु-उपयोगकर्ता, 100TB db पर ऑनलाइन होने वाला चेकडब कैसे काम करता है?

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


हे स्टीव - कुछ ग्राहकों को संस्करणों की आवश्यकता होती है, कुछ नहीं। यह निर्भर करता है कि उनकी HA / DR सोच कितनी उन्नत है और उनके पास कितना पैसा है। 100TB डेटाबेस पर CHECKDB? कोई विचार नहीं - मैंने इसे कई टीबी से ऊपर का परीक्षण नहीं किया और एएफएआईके ने इसका परीक्षण नहीं किया> 10 टीबी। मुझे यह सुनकर अच्छा लगेगा कि यह 2005/2008 में कैसा है। धन्यवाद
पॉल रैंडल

अरे, तुम आदमी हो कि एक परीक्षण के लिए पूछना चाहिए। शायद SQLCAT में श्री कॉक्स एक चला सकते हैं। हा / DR स्थिति मायने रखती है। अमेज़न संस्करणों की परवाह नहीं कर सकता है। अन्य कानूनी / नियामक मुद्दों पर निर्भर हो सकते हैं। यह सोचने वाली बात है।
स्टीव जोंस

0

तकनीकी तौर पर, भंडारण है इतना नहीं सस्ते, लेकिन petabyte स्तर पर,। यह वास्तव में आवेदन पर निर्भर करता है, लेकिन मैं कहूंगा कि रणनीति के कुछ संयोजन # 2 और # 3 का उत्तर होने जा रहा है, # 2 के साथ दिए गए और # 3 के आधार पर आप कितना निवेश भंडारण और किस तरह का कर सकते हैं भंडारण और IO / कम्प्यूटेशनल शक्ति जो आपको कम वेतन वृद्धि और जितना संभव हो उतना पूर्ण बैकअप के साथ दूर होने देगी।

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


मैं उस व्यक्ति से सहमत हो गया हूं जिसने सवाल पूछा था। भंडारण सस्ता है। / प्रबंधित / भंडारण नरक के रूप में महंगा है।
मैट सिमंस

0

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


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

लेकिन टिप्पणी के लिए धन्यवाद!
पॉल रैंडल

0

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

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

ईमानदारी से, हालांकि, यह बात रखने के लिए प्रसंस्करण / भंडारण / आदि के एक बड़े कचरे की तरह लग रहा था ... खासकर जब सबसे बड़ा फायदा यह था कि उनके प्रवेश और एनसीआर तकनीक को अनियमित रखरखाव करने के लिए कम शाम को काम करना पड़ता था।

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