बैकअप, भाग 6: बैकअप उपकरण की तुलना करना

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

डेटा रिकवरी

Rsync और टार को संदर्भ बिंदु के रूप में उपयोग किया जाएगा, क्योंकि यह इन पर है कि सरलतम बैकअप स्क्रिप्ट आमतौर पर आधारित होती हैं ।

Rsync ने 4 मिनट और 28 सेकंड में परीक्षण डेटासेट दिखा कर पूरा कर लिया


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

टार के लिए थोड़ा तेज निपटा


नेटवर्क सबसिस्टम के संचालन के दौरान ओवरहेड - बढ़ी हुई ओवरहेड के कारण पूर्ण सिस्टम लोड औसतन 20% से अधिक था।

यदि संग्रह अतिरिक्त रूप से संपीड़ित होता है, तो पुनर्प्राप्ति समय 3 मिनट 19 सेकंड तक बढ़ जाता है

अनपैकिंग प्रक्रिया दोनों प्रोसेसर कोर पर कब्जा कर लेती है, क्योंकि दो प्रक्रियाएं काम करती हैं। सामान्य तौर पर, अपेक्षित परिणाम। साथ ही, बैकअप के साथ सर्वर साइड पर gzip चलाते समय एक तुलनीय परिणाम (3 मिनट और 20 सेकंड) प्राप्त किया गया था, मुख्य सर्वर पर लोड प्रोफ़ाइल gzip कंप्रेसर के बिना टार चलाने के समान था (पिछले ग्राफ़ देखें)।

Rdiff- बैकअप में, आप नियमित rsync (परिणाम समान होंगे) का उपयोग करके बनाए गए अंतिम बैकअप को सिंक्रनाइज़ कर सकते हैं, लेकिन पुराने बैकअप को अभी भी rdiff- बैकअप प्रोग्राम का उपयोग करके पुनर्स्थापित करने की आवश्यकता है, जो 17 मिनट और 17 सेकंड में पुनर्स्थापित करने में सफल रहा,


शायद यह कल्पना की गई थी, किसी भी मामले में, लेखक गति को सीमित करने के लिए इस तरह के समाधान का प्रस्ताव करते हैं। एक बैकअप को पुनर्स्थापित करने की प्रक्रिया एक कोर के आधे से थोड़ा कम लेती है, आनुपातिक तुलनीय प्रदर्शन (यानी, 2-5 बार धीमी) एक डिस्क और नेटवर्क पर rsync के साथ।

पुनर्प्राप्ति के लिए Rsnapshot नियमित rsync का उपयोग करने का सुझाव देता है, इसलिए इसके परिणाम समान होंगे। सामान्य तौर पर, यह कैसे हुआ।

बर्प ने 7 मिनट और 2 सेकंड में बैकअप बहाल करने के कार्य के साथ मुकाबला किया

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

BackupPC ने उसी गति और लोड के बारे में दिखाया जब rsync ट्रांसफ़र मोड को चालू करने के लिए बैकअप को तैनात करके


लेकिन टार बैकअपपीसी के साथ डेटा ट्रांसफर मोड में अधिक धीमी गति से: 12 मिनट और 15 सेकंड में, प्रोसेसर लोड आमतौर पर कम था


एन्क्रिप्शन के बिना द्वैधता ने थोड़ा बेहतर परिणाम दिखाया, 10 मिनट और 58 सेकंड में बैकअप बहाल करने के साथ मुकाबला किया। यदि आप gpg का उपयोग करके एन्क्रिप्शन को सक्रिय करते हैं - वसूली का समय 15 मिनट और 3 सेकंड तक बढ़ जाता है। इसके अलावा, जब आप कॉपियों को संग्रहीत करने के लिए भंडार का निर्माण करते हैं, तो आप संग्रह के आकार को निर्दिष्ट कर सकते हैं, जिसका उपयोग आने वाली नई स्ट्रीम को विभाजित करते समय किया जाएगा। सामान्य तौर पर, साधारण हार्ड ड्राइव पर, ऑपरेशन के एकल-थ्रेडेड मोड के कारण भी बहुत अंतर नहीं होता है। हाइब्रिड स्टोरेज का उपयोग करते समय यह विभिन्न ब्लॉक आकारों के साथ दिखाई दे सकता है। वसूली के दौरान मुख्य सर्वर पर लोड इस प्रकार था:



डुप्लिकेटी ने 13 मिनट और 45 सेकंड में, एक तुलनात्मक पुनर्प्राप्ति गति दिखाई। एक और 5 मिनट में बरामद डेटा (लगभग 19 मिनट की कुल) की शुद्धता का सत्यापन किया गया। भार था


जब एन्स एन्क्रिप्शन को आंतरिक रूप से सक्रिय किया गया था, तो रिकवरी का समय 21 मिनट और 40 सेकंड था, और प्रोसेसर लोड अधिकतम था (दोनों कोर!) रिकवरी के दौरान; डेटा की जाँच करते समय, केवल एक धागा सक्रिय था, जिसमें एक प्रोसेसर कोर था। पुनर्प्राप्ति के बाद डेटा सत्यापन में समान 5 मिनट (कुल लगभग 27 मिनट) लगे।


एन्क्रिप्शन के लिए एक बाहरी gpg प्रोग्राम का उपयोग करते समय डुप्लिकेटी ने रिकवरी को थोड़ी तेजी से नियंत्रित किया, लेकिन सामान्य तौर पर पिछले मोड से अंतर न्यूनतम हैं। 6 मिनट में डेटा सत्यापन के साथ ऑपरेटिंग समय 16 मिनट 30 सेकंड था। भार था


AMANDA , टार का उपयोग करते हुए, 2 मिनट 49 सेकंड में प्रबंधित किया जाता है, जो सिद्धांत रूप में, नियमित टार के बहुत करीब है। सिद्धांत में सिस्टम लोड


जब zbackup का उपयोग करके एक बैकअप बहाल किया जाता है , तो निम्न परिणाम प्राप्त हुए:




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

गैर-एन्क्रिप्टेड मोड में बोर्गबैकअप टार की तुलना में थोड़ा धीमा था, 2 मिनट 45 सेकंड में, हालांकि, उसी टार के विपरीत, रिपॉजिटरी को डुप्लिकेट करना संभव हो गया। एक ही समय में लोड निकला


यदि आप ब्लेक-आधारित एन्क्रिप्शन को सक्रिय करते हैं, तो बैकअप को पुनर्स्थापित करने की गति थोड़ी धीमी हो जाती है। इस मोड में पुनर्प्राप्ति समय 3 मिनट 19 सेकंड है, और लोड जारी किया गया है


एईएस एन्क्रिप्शन थोड़ा धीमा काम करता है, रिकवरी समय 3 मिनट 23 सेकंड, विशेष रूप से लोड


चूंकि Borg बहु-थ्रेडेड मोड में काम कर सकता है - प्रोसेसर लोड अधिकतम है, जब आप अतिरिक्त फ़ंक्शन सक्रिय करते हैं, तो ऑपरेटिंग समय बस बढ़ जाता है। जाहिरा तौर पर, यह zbackup के समान ही मल्टीथ्रेडिंग कार्य की खोज के लायक है।

आराम थोड़ा और धीरे धीरे से निपटने के लिए, ऑपरेटिंग समय 4 मिनट 28 सेकंड था। लोड देखा


जाहिरा तौर पर, पुनर्प्राप्ति प्रक्रिया कई थ्रेड्स में काम करती है, लेकिन दक्षता बोर्गबैकअप जितनी अधिक नहीं है, लेकिन यह सामान्य rsync के समय में तुलनीय है।

UrBackup का उपयोग करते हुए, मैं 8 मिनट और 19 सेकंड में डेटा को पुनर्प्राप्त करने में सक्षम था, जबकि लोड था


अभी भी बहुत अधिक लोड नहीं दिख रहा है, यहां तक ​​कि टार की तुलना में भी कम है। स्थानों में, फट, लेकिन एक भी कोर लोड करने से अधिक नहीं।

तुलना के लिए मापदंड का चयन और औचित्य

जैसा कि पिछले लेख में बताया गया है, बैकअप सिस्टम को निम्न मानदंडों को पूरा करना चाहिए:

• काम में सरलता
• चंचलता
• स्थिरता
• तेज़ी

यह प्रत्येक वस्तु पर अधिक विस्तार से अलग से विचार करने योग्य है।

काम की सादगी

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

उदाहरण के लिए, जिन उम्मीदवारों पर विचार किया गया है, एक सरल उपाय है burp, rdiff-backup और restic, जिनके पास अलग-अलग ऑपरेटिंग मोड के लिए mnemonically याद की गई कुंजियाँ हैं। थोड़ा और जटिल हैं बोर्ग और दोहराव। सबसे मुश्किल था AMANDA। उपयोग की आसानी के बीच में कहीं है। किसी भी मामले में, यदि आपको उपयोगकर्ता पुस्तिका को पढ़ने के लिए 30 सेकंड से अधिक की आवश्यकता है, या आपको Google या किसी अन्य खोज इंजन पर जाने की आवश्यकता है, और लंबी हेल्प शीट के माध्यम से भी स्क्रॉल करें, समाधान जटिल है, एक ही रास्ता या कोई अन्य।

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

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

चंचलता

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

एक संकेत के रूप में - नियमित एसएचएस का उपयोग करके काम करने की क्षमता।

काम की गति

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

स्थिरता

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

बैकअप टूल की तुलना

टेबल लीजेंड:

• हरा, ऑपरेटिंग समय पांच मिनट से कम है, या उत्तर "हां" है (कॉलम के लिए "क्लाइंट \ _ सर्वर चाहिए?"), 1 अंक
• पीला, परिचालन समय पांच से दस मिनट, 0.5 अंक
• लाल, ऑपरेटिंग समय दस मिनट से अधिक है, या उत्तर "नहीं" है (कॉलम के लिए "क्लाइंट \ _ सर्वर चाहिए?"), 0 अंक

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

मैं हर किसी को धन्यवाद देता हूं जो चक्र को अंत तक पढ़ता है, मैं विकल्पों पर चर्चा करने का सुझाव देता हूं, अपने खुद के सुझाव देता हूं, यदि कोई हो। जैसे-जैसे चर्चा आगे बढ़ती है, तालिका पूरक हो सकती है।

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

घोषणा

बैकअप, भाग 1: आपको बैकअप की आवश्यकता क्यों है, विधियों, प्रौद्योगिकियों का अवलोकन
बैकअप, भाग 2: अवलोकन और परीक्षण rsync- आधारित बैकअप उपकरण
बैकअप, भाग 3: अवलोकन और परीक्षण दोहराव, डुप्लिकेट
बैकअप, भाग 4: अवलोकन और परीक्षण zbackup, restic, borgbackup
बैकअप, भाग 5: लिनक्स के लिए बेकुला और वेज बैकअप का परीक्षण
बैकअप: पाठकों द्वारा अनुरोधित हिस्सा: AMANDA समीक्षा, UrBackup, BackupPC
बैकअप, भाग 6: बैकअप उपकरण की तुलना करना
बैकअप भाग 7: निष्कर्ष