बैकअप के लिए क्लाउड सेवा कैसे चुनें


12

मैं अपने ग्राहक की वेबसाइट का बैकअप लेने के लिए क्लाउड सेवा का उपयोग करने के बारे में सोच रहा हूं।

मेरे (ग्राहक) मुख्य चिंताएँ हैं (महत्व के घटते क्रम में)

  1. IP का संरक्षण (व्यापार रहस्य, स्रोत कोड), उपयोगकर्ता खाता विवरण आदि
  2. सेवा प्रदाता द्वारा दी गई अपटाइम गारंटी (वेबसर्वर को कम से कम करने के लिए)
  3. लागत
  4. अपलोड / डाउनलोड गति

आदर्श रूप से, मैं ऐसी सेवा करना चाहूंगा जिसमें एक लंबी टाई न हो (यानी मैं एक तरह की "पे-एज़-यू-गो" सेवा पसंद करूंगा)

मैं वेंडर लॉकिन से भी बचना चाहूंगा, जहां दूसरी सेवा में जाना असंभव है।

मैं कुछ सामान्य दिशा-निर्देशों पर चाहूंगा:

  1. सेवा प्रदाता चुनने के बारे में कैसे जाना है
  2. मैदान में मुख्य खिलाड़ी कौन हैं
  3. के लिए उपयोग करने के लिए सॉफ्टवेयर की सिफारिश: बैकअप / बहाल / / और बचाया / बहाल फ़ाइलों के अपलोड / डाउनलोड

सर्वर सॉफ्टवेयर या तो उबंटू या डेबियन होने वाला है (मैं संभवतः एक सवाल पोस्ट करूंगा कि ओएस किस सर्वर के रूप में जाना है - मैं पहले से ही उबंटू से परिचित हूं)


वेबसाइट कितनी बड़ी है? क्या इसमें बड़े डेटाबेस शामिल हैं? किसी भी बॉल-पार्क आंकड़े पर कि ग्राहक कितना खर्च करने को तैयार है? ($ 100 / माह, $ 10,000 / महीना?)
RJFalconer

3
जहां तक ​​"व्यापार रहस्य और स्रोत कोड" का संबंध है, इतनी महत्वपूर्ण जानकारी "क्लाउड" में नहीं है, भले ही कोई सेवा कितनी प्रतिष्ठित हो।

जवाबों:


4

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

वेबसाइट के सर्वर पर सभी महत्वपूर्ण एन्क्रिप्शन कुंजियों की मेजबानी करने से बचने के लिए, जो किसी बिंदु पर हैक होने की संभावना है, यहां मैं क्या करूंगा:

  1. ग्राहक की अपनी साइट पर इन-हाउस बैकअप सर्वर - दोनों अन्य सर्वरों के लिए एन्क्रिप्शन कुंजी और एसएसएच कुंजी है
  2. वेबसाइट को होस्ट करने वाला सर्वर - एक वेब होस्ट हो सकता है
  3. क्लाउड बैकअप सर्वर या सेवा

चरण 1: सर्वर (1) बैकअप को (2) से खींचता है, इसलिए वेबसाइट सर्वर के अधिकांश हैक बैकअप से समझौता नहीं करेंगे। इस बिंदु पर एन्क्रिप्शन होता है।

  • मैं कुंजी-आधारित लॉगिन का उपयोग करके SSH पर rsnapshot का उपयोग करूंगा , क्योंकि इसमें वेब होस्ट और इन-हाउस बैकअप सर्वर की न्यूनतम आवश्यकताएं हैं - जब तक कि आपके पास बैकअप करने के लिए एक बड़ा DB नहीं है, यह बैंडविड्थ में बहुत कुशल है और साइट के कई संस्करणों को संग्रहीत करता है, और पुराने बैकअप को भी सँभालता है।
  • एन्क्रिप्शन किसी भी फाइल टू फाइल टूल जैसे कि GPG, rsnapshot ट्री को दूसरे पेड़ पर कॉपी करने के लिए किया जा सकता है - या आप डिस्क स्पेस को बचाते हुए चरण 2 के लिए डुप्लिकेट का उपयोग कर सकते हैं।
  • बैकअप सर्वर से "खींचो" महत्वपूर्ण है - यदि मुख्य सर्वर (2) में बैकअप सर्वर के लिए पासवर्ड / कुंजी हैं, तो हैकर्स मुख्य सर्वर को हैक करने के बाद कभी-कभी बैकअप हटा सकते हैं (नीचे देखें)। वास्तव में उन्नत हैक ट्रोजन एसएसएच बायनेरिज़ को स्थापित कर सकते हैं जो तब बैकअप सर्वर से समझौता कर सकते थे, लेकिन ज्यादातर कंपनियों के लिए इसकी संभावना कम है।

चरण 2: सर्वर (1) एन्क्रिप्टेड बैकअप को (3) धकेलता है ताकि ऑफसाइट बैकअप हो। यदि बैकअप चरण 1 में एन्क्रिप्ट किए गए थे, तो आप रिमोट सिस्टम पर स्थानीय rsnapshot ट्री के rsync दर्पण का उपयोग कर सकते हैं।

  • रिमोट सर्वर पर अनएन्क्रिप्टेड rsnapshot ट्री को सीधे एन्क्रिप्ट और बैकअप करने के लिए डुप्लिकेट एक अच्छा विकल्प होगा। GPG- एन्क्रिप्टेड टार अभिलेखागार का उपयोग करते हुए, डुप्लिकेटिटी की विशेषताएं rsnapshot के लिए थोड़ी भिन्न होती हैं, लेकिन यह दूरस्थ होस्ट पर बैकअप एन्क्रिप्शन प्रदान करता है और केवल उस होस्ट पर SSH की आवश्यकता होती है (या यह Amazon S3 का उपयोग कर सकता है)। द्वैधता हार्ड लिंक का समर्थन नहीं करता है , इसलिए यदि यह आवश्यक है (उदाहरण के लिए एक पूर्ण सर्वर बैकअप के लिए), तो यह सबसे अच्छा है अगर कोई स्क्रिप्ट rsnapshot ट्री (जो हार्ड लिंक का समर्थन करता है) को एक टार फाइल (शायद सिर्फ उन फ़ाइलों में>> में परिवर्तित करता है) 1 हार्ड लिंक, जो काफी छोटा होगा) इसलिए डुप्लिकेट टार फाइल का बैकअप ले सकता है।
  • चूंकि रिमोट सर्वर सिर्फ एक SSH होस्ट है, संभवतः rsync के साथ, यह एक वेब होस्ट हो सकता है (लेकिन एक अलग होस्टिंग प्रदाता और देश के एक अलग हिस्से में), या rsync और / या SSH प्रदान करने वाली क्लाउड सेवा - देखें bsbackup और rsync.net की अनुशंसा के लिए क्लाउड पर rsync बैकअप पर यह उत्तर , हालांकि मैं उल्लेखित बैकअप सेटअप से सहमत नहीं हूं।
  • आप डुप्लिकेट के साथ दूरस्थ सर्वर के रूप में अमेज़ॅन एस 3 का उपयोग कर सकते हैं, जो आपको वास्तव में अच्छी उपलब्धता देगा हालांकि शायद बड़े बैकअप के लिए अधिक लागत आएगी।
  • रिमोट एन्क्रिप्टेड बैकअप के लिए अन्य विकल्प हैं बॉक्सबैकअप (काफी परिपक्व, कुछ अच्छी विशेषताएं नहीं) और टार्सनैप (कमर्शियल क्लाउड सर्विस जो कि साधारण कमांड लाइन इंटरफेस के साथ अमेज़ॅन एस 3 पर आधारित है, अच्छा समर्पण और बहुत गहन एन्क्रिप्शन है)।

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

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

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

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


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

@ptman: यह सच है - हालांकि सभी rsnapshot पेड़ की जरूरत नहीं है। मैं rsnapshot "daily.0" निर्देशिका को rsnapshot ट्री में बैकअप करने के लिए द्वैधता का उपयोग करूंगा, जिसमें निर्देशिका ट्री का सबसे हाल का स्नैपशॉट बैकअप लिया जा रहा है। Rsnapshot के इंटर-स्नैपशॉट लिंक के बीच daily.0, daily.1, आदि, डुप्लिकेटिटी बैकअप के लिए प्रासंगिक नहीं हैं, जो केवल दैनिक.0 स्नैपशॉट ट्री के भीतर दो फाइलों के बीच लिंक को देखता है, जो कि सिस्टम के हार्ड लिंक के अनुरूप है। टार उन लिंक को ओके कर सकता है और डुप्लिकेटिटी उन्हें टार फाइल के माध्यम से बैकअप दे सकती है।
रिचवेल

2

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


1

मैं हमेशा अपने ग्राहकों को बताता हूं कि सबसे अच्छा, कम से कम महंगा और सबसे कुशल बैकअप समाधान वह है जो आप अपने स्वयं के प्रयोजनों के लिए स्वयं का निर्माण करते हैं।

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

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


0

छोटे व्यवसाय / अभियोजक के लिए, मैं अमेज़ॅन के संग्रहण सेवा की सिफारिश करूंगा ।

  • क्षेत्र नियंत्रण (यूरोपीय संघ में संग्रहीत वस्तुएं यूरोपीय संघ को कभी नहीं छोड़ती हैं)।
  • किसी भी बिलिंग चक्र के लिए 99.9% अपटाइम
  • $ 0.150 प्रति जीबी प्रति माह संग्रहीत
  • $ 0.170 प्रति जीबी डाउनलोड किया गया
  • जून 2010 तक नि: शुल्क अपलोड, उसके बाद $ 0.10 प्रति जीबी

और बल्कि अस्पष्ट आश्वासन है कि "यह सुनिश्चित करने के लिए प्रमाणीकरण तंत्र प्रदान किए जाते हैं कि डेटा को अनधिकृत पहुंच से सुरक्षित रखा जाए"


0

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

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


0

मुझे अमेज़ॅन AWS के भीतर अपना बैकअप स्टोर करना पसंद है और मैं मुफ्त टूल s3cmd ( http://s3tools.org/slcmd ) का उपयोग करता हूं

इसे काफी आसानी से स्थापित किया जा सकता है (डेबियन: apt-get install s3cmd)।

S3 पर अपनी फ़ाइलों को संग्रहीत करने के लिए आपको केवल अमेजन AWS खाते की आवश्यकता है। फिर एक साधारण कमांड आपके बैकअप को चला सकता है, यहां तक ​​कि वृद्धिशील या सिंक समाधान के रूप में, जैसे:

s3cmd sync /srv/backup  s3://your-bucket-name-at-amazon/

सुनिश्चित करें कि आप चलाते हैं

s3cms --configure 

सबसे पहले अपने AWS क्रेडेंशियल दर्ज करें।

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