तबाही की योजना


18

मैं एक छोटी विपणन कंपनी के लिए काम करता हूं जो वेब डिजाइन और विकास भी करती है। हम अपने सभी वेब डिज़ाइन और विकास ग्राहकों को Hostgator के समर्पित सर्वर पर होस्ट करते हैं। हमारे पास RAID 1 कॉन्फ़िगर हार्ड ड्राइव के साथ एक समर्पित सर्वर है। हम साप्ताहिक बैकअप भी करते हैं जो कि cPanel के माध्यम से स्वचालित है और स्थानीय स्तर पर स्वचालित एफ़टीपी सॉफ़्टवेयर द्वारा डाउनलोड किया जाता है।

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

यह कहने की आवश्यकता नहीं है कि हम "सबसे खराब स्थिति" प्रकार की घटनाओं के लिए तैयार रहना चाहते हैं क्योंकि यह निश्चित रूप से हमें व्यापार से बाहर कर देगा। तो मेरे दो सवाल हैं:

  1. Hostgator द्वारा विस्तारित आउटेज के लिए तैयार होने के लिए हम क्या कर सकते हैं? एक आदर्श परिदृश्य में हमारे ग्राहकों की वेबसाइटें होंगी, और उम्मीद है कि ईमेल, फिर से और जल्दी से फिर से चलेंगे।

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

आप मान सकते हैं कि लागत आपके उत्तरों में कोई मुद्दा नहीं है, लेकिन जितना अधिक किफायती समाधान उतना ही बेहतर है।


उत्तर की तरह लगता है कि यहाँ पहले से ही बहुत सारे अच्छे मैदान हैं। मैं इस बात की प्रतिज्ञा कर सकता हूं कि अमेज़ॅन क्लाउड इस बिंदु पर एक बैकअप समाधान के रूप में बहुत किफायती रहा है। यह नहीं बताया कि भविष्य क्या है, लेकिन अगर और कुछ नहीं, तो यह सीखने का एक अच्छा तरीका है कि क्लाउड कैसे काम करता है।
जेएमसी

यहाँ AWS के लिए अनुमानित लागत कैलकुलेटर है अगर आप अभी तक इसे नहीं चलाते हैं: कैलकुलेटर।
S3.amazonaws.com/calc5.html

@ जॉन कोंडे: होस्टगेटर के साथ आपका अनुभव कैसा रहा, कोई बड़ी गिरावट? यदि हाँ तो प्रमुख डाउनटाइम आपको कब तक याद था?
मार्को डेमायो

@ मार्को डेमायो, हमारे पास होस्टगेटर के साथ बिल्कुल भी डाउनटाइम नहीं था। वे बेहद विश्वसनीय रहे हैं और उनका समर्थन शानदार है।
जॉन कोनडे

जवाबों:


15

मेरा सुझाव है कि आप:

  1. स्वचालित रूप से एक अलग डेटा सेंटर में पूरी तरह से अलग नेटवर्क पर एक माध्यमिक बैकअप सर्वर के लिए अपने मुख्य सर्वर की संपूर्ण सामग्री और कॉन्फ़िगरेशन को मिरर करें । RSync, FXP, cPanel voodoo, या जो भी विधि आप सिंक्रनाइज़ करना चाहते हैं उसका उपयोग करें।

  2. DNS फ़ेलओवर स्विचिंग का उपयोग बैकअप सर्वर पर ट्रैफ़िक को स्वचालित रूप से रूट करने के लिए करना चाहिए, होस्टगेटर सर्वर को अप्रतिसादी साबित करना चाहिए।

इसका मतलब है कि आपके पास लगातार 'हॉट' बैकअप होने की प्रतीक्षा है, बल्कि 'कोल्ड' बैकअप के बजाय सबसे खराब स्थिति में होना चाहिए, जिसमें मैनुअल हस्तक्षेप और चारों ओर से घबराने की जरूरत होती है। इसका मतलब यह भी है कि आपके ग्राहकों को कभी पता नहीं चलेगा कि आपकी साइट आपके द्वारा किए जाने से पहले नीचे चली गई थी, जो हर किसी के लिए चिंताजनक हो सकती है।

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

  1. DNS मेड ईज़ी आपके प्राथमिक सर्वर को कभी भी दो से चार मिनट तक जांचता है और, यदि यह प्रतिक्रिया का पता नहीं लगाता है, तो यह द्वितीयक आईपी पते पर ट्रैफ़िक को रूट करता है।

  2. DNS मेड ईजी प्राथमिक सर्वर की जांच जारी रखता है। जब यह ऊपर आता है, तो यह पहले सर्वर पर ट्रैफ़िक फिर से भेज देगा, या - यदि आप चाहें तो इसे बैकअप में रखें जब आपको पता चले कि क्या गलत हुआ है और प्राथमिक सर्वर को ठीक करें।

बेशक, यह समाधान आपकी परिचालन लागतों को बढ़ा देगा, जिसे आपको ग्राहकों को किसी भी तरह से पास करना होगा, लेकिन - यदि आप एक ऐसे उद्योग में हैं, जहां डाउनटाइम आपको व्यवसाय से बाहर कर देगा - मोटे तौर पर अनावश्यक सर्वर के लिए भुगतान करना संभवत: लायक है इसके लिए यह एक बार कंपनी को बचाता है।

उस परे:

नकल, नकल, नकल

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

मैन्युअल रूप से बैकअप बहाल करने का अभ्यास करें

यदि आपने अपने किसी बैकअप से पुनर्प्राप्त करने का प्रयास नहीं किया है, तो आप कैसे जानते हैं कि वे काम करते हैं? यह देखने के लिए आपातकालीन अभ्यास करने के लायक है कि क्या होगा आपकी स्वचालित प्रक्रियाएं विफल हो जानी चाहिए।


अद्यतन: कुछ अन्य सेवाओं को मैंने हाल ही में खोजा है जो साइट बैकअप, आपदा वसूली और अपटाइम को बनाए रखने के संबंध में ध्यान देने योग्य हैं:

  • Cloudflare, जो आपके सर्वर के डाउन होने पर साइट्स को बनाए रखने के लिए सुरक्षा और कैशिंग सुविधाएँ प्रदान करता है। (वे आपकी साइट को मिरर करते हैं और इसे सीधे आपके सर्वर से बजाय विश्व स्तर पर वितरित कैश से प्राप्त करते हैं।)
  • कोडगार्ड, जो स्वचालित बैकअप और वेबसाइट कोड (केवल FTP) का रोलबैक प्रदान करता है।
  • साइट ऑटो बैकअप, जो cPanel बैकअप के माध्यम से स्वचालित बैकअप और वेबसाइट कोड, ईमेल डेटा और MySQL जानकारी का रोलबैक प्रदान करता है। ध्यान दें कि यह Hostgator द्वारा चलाया जाता है, इसलिए यह आवश्यक नहीं है कि आप अपनी साइट को इनके साथ भी होस्ट करें, लेकिन दूसरों की मदद कर सकते हैं।

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


मुझे नहीं पता था कि डीएनएस जैसा आसान अस्तित्व में था। यह एक शानदार तरीका होगा कि प्राथमिक सर्वर के डाउन होने की स्थिति में साइटों को जल्दी से पुनः चालू किया जाए।
जॉन कोंडे

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

@ निक: यहां वे कहते हैं कि डीएनएस फेलओवर (मुझे लगता है कि आप डीएनएस मेड ईज़ी में जिस सेवा में सबसे अधिक व्यस्त हैं) की सिफारिश नहीं की गई है: serverfault.com/questions/60553/… आपको क्या लगता है?
मार्को डेमायो

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

1
वैसे, स्टैक एक्सचेंज डीएनएस फेलओवर का भी उपयोग करता है। ओरेगन में माध्यमिक में प्राथमिक डेटा सेंटर है। meta.stackexchange.com/a/231138/238706 meta.stackexchange.com/q/207653/238706
Palec

6

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

आरटीओ अनिवार्य रूप से इस बात की उम्मीद है कि साइटों को वापस आने तक कितना समय लगना चाहिए। यदि आपके पास एक या दो मिनट (या उससे कम) का आरटीओ है, तो आपको निक के सुझाव के अनुरूप एक समाधान पर विचार करना चाहिए, जिसमें आपकी फ़ाइलों और डेटा की वास्तविक समय प्रतिकृति और एक द्वितीयक डेटा केंद्र और DNS की स्वचालित विफलता शामिल हो सकती है। भुगतान सेवा के साथ या दोनों डेटा केंद्रों (जैसे BIG-IP ग्लोबल ट्रैफ़िक मैनेजर) के साथ किया जाना चाहिएF5 नेटवर्क से। यह महंगा हो सकता है, लेकिन काफी हद तक इस सवाल का जवाब देने पर निर्भर करता है कि "डाउनटाइम की लागत क्या है?" यदि आपका आरटीओ कुछ घंटों या कुछ दिनों का भी है, तो आप आपदा वसूली प्रक्रियाओं पर विचार कर सकते हैं जिसमें अधिक मैनुअल भागीदारी शामिल हो सकती है जैसे कि सर्वर को ऑनलाइन लाना, DNS को स्विच करना, आदि थकाऊ, लेकिन निश्चित रूप से प्रभावी लागत यदि आपका आरटीओ इसके लिए अनुमति देता है।

RPO मूल रूप से बैकअप कितनी बार किया जाता है और आपदा की स्थिति में आप कितना डेटा खोने को तैयार हैं। यदि सामग्री और / या डेटा में परिवर्तन अक्सर होता है, तो आपके पास शायद मिनट या घंटों का आरपीओ होने की संभावना है और वास्तविक समय प्रतिकृति या उच्च आवृत्ति बैकअप के साथ काम कर सकता है। यदि सामग्री में वह परिवर्तन नहीं होता है या आपके पास ऐसे ग्राहक होते हैं जो जरूरी नहीं कि वे कुछ दिनों के लिए डेटा खो देते हैं, तो आपका बैकअप कम बार हो सकता है।

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

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

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

आशा है कि इसने मदद की है।

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


मैंने कभी भी क्लाउड होस्टिंग को "सर्वर" के रूप में उपयोग करने पर विचार नहीं किया। यह एक बहुत ही किफायती तरीका होगा कि आप जल्दी से जाने के लिए तैयार रहें।
जॉन कोंडे

2

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

फ़ाइलों को rsync और unison जैसे उपकरणों के साथ सिंक में रखा जा सकता है। SQL बैकअप को भी rsynced किया जा सकता है और फिर स्क्रिप्ट द्वारा दास db पर अपलोड किया जा सकता है।


1

सुनिश्चित करें कि आप स्रोत कोड रिपॉजिटरी (SVN या GIT) के साथ अपने सभी कोड का संस्करण नियंत्रण चला रहे हैं। क्या आप एसवीएन या जीआईटी का उपयोग कर रहे हैं?

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

आप या तो अपने एसवीएन कमिट / चेकआउट को कमांड लाइन के माध्यम से कर सकते हैं, या क्लाइंट जैसे संस्करणों (मैक के लिए) या टोर्टोइसेएसवीएन (विंडोज के लिए) के माध्यम से कर सकते हैं।


केवल स्रोत कोड रिपॉजिटरी के साथ समस्या यह डेटाबेस या किसी भी उपयोगकर्ता द्वारा अपलोड की गई फ़ाइलों आदि का
बैकअप नहीं लेती है

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

दुर्भाग्य से हम संस्करण नियंत्रण का उपयोग नहीं करते हैं। वास्तव में, यहां शुरू होने से पहले, सभी काम लाइव साइट पर किए गए थे! मैं स्थानीय स्तर पर विकास का वातावरण प्राप्त करने में सक्षम था, इसलिए कम से कम यह अभ्यास आधिकारिक तौर पर मर चुका है।
जॉन कोंडे
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.