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

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

डेटा रिकवरी

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

rsync 4 मिनट और 28 सेकंड में परीक्षण डेटा सेट का मुकाबला किया

इतना भार

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

टार इसे थोड़ा तेजी से पूरा किया

2 मिनट और 43 सेकंड:

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

यदि संग्रह को और अधिक संपीड़ित किया जाता है, तो पुनर्प्राप्ति समय बढ़कर 3 मिनट 19 सेकंड हो जाता है।
मुख्य सर्वर पर इस तरह के लोड के साथ (मुख्य सर्वर के किनारे अनपैकिंग):

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

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

यह भार:

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

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

बर्प मैंने बैकअप को पुनर्स्थापित करने का कार्य 7 मिनट और 2 सेकंड में पूरा किया
इस भार के साथ:

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

कार्यक्रम ने लगभग समान गति और भार दिखाया बैकअपपीसी rsync ट्रांसफर मोड को सक्षम करते समय, बैकअप को तैनात करना

7 मिनट और 42 सेकंड:

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

डेढ़ गुना:

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

कोई एन्क्रिप्शन नहीं

एन्क्रिप्शन के साथ

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

बहुत उच्च:

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

परिणाम

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

ऐसा:

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

जो उसी:

बैकअप का उपयोग करके पुनर्स्थापित करते समय ज़बैकअप अग्रांकित परिणाम प्राप्त किए गए थे:

एन्क्रिप्शन, एलज़मा संपीड़न

चलने का समय 11 मिनट और 8 सेकंड

एईएस एन्क्रिप्शन, एलज़मा संपीड़न

कार्य समय 14 मिनट

एईएस एन्क्रिप्शन, एलज़ो संपीड़न

चलने का समय 6 मिनट, 19 सेकंड

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

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

निम्नलिखित:

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

इस कदर:

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

नहीं बदला गया है:

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

आराम करना पुनर्प्राप्ति को थोड़ा और धीरे-धीरे प्रबंधित किया गया, संचालन का समय 4 मिनट 28 सेकंड था। भार जैसा लग रहा था

के रूप में इस प्रकार है:

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

साथ उरैकअप 8 मिनट और 19 सेकंड में डेटा को पुनर्स्थापित करना संभव था, लोड था

ऐसा:

भार अभी भी बहुत अधिक नहीं है, टार से भी कम है। कुछ स्थानों पर विस्फोट होते हैं, लेकिन एक कोर के भार से अधिक नहीं।

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

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

• उपयोग में आसानी
• चंचलता
• स्थिरता
• तेज़ी

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

काम में आसानी

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

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

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

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

चंचलता

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

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

कार्य की गति

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

स्थिरता

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

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

निर्माण समय की प्रतिलिपि बनाएँ
पुनर्प्राप्ति समय कॉपी करें
सरल प्रतिष्ठापन
आसान सेटअप
प्रयोग करने में आसान
सरल स्वचालन
क्या आपको क्लाइंट सर्वर की आवश्यकता है?
भंडार की अखंडता की जाँच करना
विभेदक प्रतियाँ
पाइप के माध्यम से कार्य करना
चंचलता
स्वतंत्रता
भंडार पारदर्शिता
Шифрование
दबाव
डिडुप्लीकेशन
वेब इंटरफेस
बादल को भरना
विंडोज़ समर्थन
निशान

rsync
4m15s
4m28s
हां
नहीं
नहीं
नहीं
हां
नहीं
नहीं
हां
नहीं
हां
हां
नहीं
नहीं
नहीं
नहीं
नहीं
हां
6

टार
शुद्ध
3m12s
2m43s
हां
नहीं
नहीं
नहीं
नहीं
नहीं
हां
हां
नहीं
हां
नहीं
नहीं
नहीं
नहीं
नहीं
नहीं
हां
8,5

gzip
9m37s
3m19s
हां

rdiff-बैकअप
16m26s
17m17s
हां
हां
हां
हां
हां
नहीं
हां
नहीं
हां
नहीं
हां
नहीं
हां
हां
हां
नहीं
हां
11

रुस्नैपशॉट
4m19s
4m28s
हां
हां
हां
हां
नहीं
नहीं
हां
नहीं
हां
नहीं
हां
नहीं
नहीं
हां
हां
नहीं
हां
12,5

बर्प
11m9s
7m2s
हां
नहीं
हां
हां
हां
हां
हां
नहीं
हां
हां
नहीं
नहीं
हां
नहीं
हां
नहीं
हां
10,5

कपट
कोई एन्क्रिप्शन नहीं
16m48s
10m58s
हां
हां
नहीं
हां
नहीं
हां
हां
नहीं
नहीं
हां
नहीं
हां
हां
नहीं
हां
नहीं
हां
11

GPG
17m27s
15m3s

डुप्लीकेट
कोई एन्क्रिप्शन नहीं
20m28s
13m45s
नहीं
हां
नहीं
नहीं
नहीं
हां
हां
नहीं
नहीं
हां
नहीं
हां
हां
हां
हां
हां
हां
11

एईएस
29m41s
21m40s

GPG
26m19s
16m30s

ज़बैकअप
कोई एन्क्रिप्शन नहीं
40m3s
11m8s
हां
हां
नहीं
नहीं
नहीं
हां
हां
हां
नहीं
हां
नहीं
हां
हां
हां
नहीं
नहीं
नहीं
10

एईएस
42m0s
14m1s

एईएस+एलज़ो
18m9s
6m19s

बोर्ग बैकअप
कोई एन्क्रिप्शन नहीं
4m7s
2m45s
हां
हां
हां
हां
हां
हां
हां
हां
हां
हां
नहीं
हां
हां
हां
हां
नहीं
हां
16

एईएस
4m58s
3m23s

blake2
4m39s
3m19s

आराम करना
5m38s
4m28s
हां
हां
हां
हां
नहीं
हां
हां
हां
हां
हां
नहीं
हां
नहीं
हां
नहीं
हां
हां
15,5

उरैकअप
8m21s
8m19s
हां
हां
हां
नहीं
हां
नहीं
हां
नहीं
हां
हां
नहीं
हां
हां
हां
हां
नहीं
हां
12

अमांडा
9m3s
2m49s
हां
नहीं
नहीं
हां
हां
हां
हां
नहीं
हां
हां
हां
हां
हां
नहीं
हां
हां
हां
13

बैकअपपीसी
rsync
12m22s
7m42s
हां
नहीं
हां
हां
हां
हां
हां
नहीं
हां
नहीं
नहीं
हां
हां
नहीं
हां
नहीं
हां
10,5

टार
12m34s
12m15s

तालिका किंवदंती:

• हरा, परिचालन समय पांच मिनट से कम, या उत्तर "हां" (कॉलम "क्लाइंट सर्वर की आवश्यकता है?" को छोड़कर), 1 अंक
• पीला, परिचालन समय पाँच से दस मिनट, 0.5 अंक
• लाल, कार्य समय दस मिनट से अधिक है, या उत्तर "नहीं" है (कॉलम "क्या आपको क्लाइंट सर्वर की आवश्यकता है?" को छोड़कर), 0 अंक

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

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

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

घोषणा

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

स्रोत: www.habr.com