बैकअप भाग 4: zbackup, restic, borgbackup की समीक्षा और परीक्षण

यह आलेख बैकअप सॉफ़्टवेयर पर विचार करेगा, जो डेटा स्ट्रीम को अलग-अलग घटकों (खंडों) में तोड़कर, एक भंडार बनाता है।

रिपॉजिटरी घटकों को और अधिक संपीड़ित और एन्क्रिप्ट किया जा सकता है, और सबसे महत्वपूर्ण बात - बार-बार बैकअप प्रक्रियाओं के दौरान - पुन: उपयोग किया जा सकता है।

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

इसी तरह के कई समाधान हैं, मैं 3 पर ध्यान केंद्रित करूंगा: ज़बैकअप, बोर्गबैकअप और रेस्टिक।

अपेक्षित परिणाम

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

टार जैसे आर्काइवर्स का उपयोग किए बिना सीधे फ़ाइलों की बैकअप प्रतियां बनाने में सक्षम होना, साथ ही rsync और sshfs जैसे अतिरिक्त टूल के बिना ssh/sftp के साथ काम करना भी अत्यधिक वांछनीय है।

बैकअप बनाते समय व्यवहार:

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

टार के साथ काम करना एक संदर्भ मूल्य के रूप में लिया जाता है, जैसा कि पिछले लेखों में से एक में दिखाया गया था।

ज़बैकअप का परीक्षण

ज़ेडबैकअप का सामान्य तंत्र यह है कि प्रोग्राम इनपुट डेटा स्ट्रीम में समान डेटा वाले क्षेत्रों को ढूंढता है, फिर वैकल्पिक रूप से उन्हें संपीड़ित और एन्क्रिप्ट करता है, प्रत्येक क्षेत्र को केवल एक बार सहेजता है।

डीडुप्लीकेशन मौजूदा डेटा ब्लॉक के खिलाफ बाइट-बाय-बाइट मिलान की जांच करने के लिए एक स्लाइडिंग विंडो के साथ 64-बिट रिंग हैश फ़ंक्शन का उपयोग करता है (जैसे rsync इसे लागू करता है)।

मल्टी-थ्रेडेड एलज़मा और एलज़ो का उपयोग संपीड़न के लिए किया जाता है, और एईएस का उपयोग एन्क्रिप्शन के लिए किया जाता है। नवीनतम संस्करणों में भविष्य में रिपॉजिटरी से पुराने डेटा को हटाने की क्षमता है।
प्रोग्राम न्यूनतम निर्भरता के साथ C++ में लिखा गया है। लेखक स्पष्ट रूप से यूनिक्स-वे से प्रेरित था, इसलिए प्रोग्राम बैकअप बनाते समय stdin पर डेटा स्वीकार करता है, पुनर्स्थापित करते समय stdout पर समान डेटा स्ट्रीम उत्पन्न करता है। इस प्रकार, अपने स्वयं के बैकअप समाधान लिखते समय zbackup को एक बहुत अच्छे "बिल्डिंग ब्लॉक" के रूप में उपयोग किया जा सकता है। उदाहरण के लिए, लेख के लेखक ने लगभग 2014 से इस प्रोग्राम को घरेलू मशीनों के लिए मुख्य बैकअप टूल के रूप में उपयोग किया है।

जब तक अन्यथा न कहा जाए, डेटा स्ट्रीम एक नियमित टार होगी।

आइए देखें कि परिणाम क्या हैं:

कार्य की जाँच 2 विकल्पों में की गई:

1. एक रिपॉजिटरी बनाई जाती है और स्रोत डेटा के साथ सर्वर पर zbackup लॉन्च किया जाता है, फिर रिपॉजिटरी की सामग्री को बैकअप स्टोरेज सर्वर पर स्थानांतरित कर दिया जाता है।
2. बैकअप स्टोरेज सर्वर पर एक रिपॉजिटरी बनाई जाती है, बैकअप स्टोरेज सर्वर पर ssh के माध्यम से zbackup लॉन्च किया जाता है, और डेटा को पाइप के माध्यम से भेजा जाता है।

पहले विकल्प के परिणाम इस प्रकार थे: 43m11s - एक अनएन्क्रिप्टेड रिपॉजिटरी और lzma कंप्रेसर का उपयोग करते समय, 19m13s - कंप्रेसर को lzo के साथ बदलते समय।

मूल डेटा के साथ सर्वर पर लोड इस प्रकार था (lzma के साथ एक उदाहरण दिखाया गया है; lzo के साथ लगभग एक ही तस्वीर थी, लेकिन rsync का हिस्सा लगभग एक चौथाई समय था):

यह स्पष्ट है कि ऐसी बैकअप प्रक्रिया केवल अपेक्षाकृत दुर्लभ और छोटे परिवर्तनों के लिए उपयुक्त है। zbackup को 1 थ्रेड तक सीमित करना भी अत्यधिक उचित है, अन्यथा बहुत अधिक CPU लोड होगा, क्योंकि यह प्रोग्राम कई थ्रेड्स में काम करने में बहुत अच्छा है। डिस्क पर लोड छोटा था, जो सामान्य तौर पर आधुनिक एसएसडी-आधारित डिस्क सबसिस्टम के साथ ध्यान देने योग्य नहीं होगा। आप रिपॉजिटरी डेटा को रिमोट सर्वर पर सिंक्रनाइज़ करने की प्रक्रिया की शुरुआत को भी स्पष्ट रूप से देख सकते हैं; ऑपरेशन की गति नियमित rsync के बराबर है और बैकअप स्टोरेज सर्वर के डिस्क सबसिस्टम के प्रदर्शन पर निर्भर करती है। इस दृष्टिकोण का नुकसान स्थानीय भंडार का भंडारण है और, परिणामस्वरूप, डेटा का दोहराव।

व्यवहार में अधिक दिलचस्प और लागू दूसरा विकल्प है, सीधे बैकअप स्टोरेज सर्वर पर zbackup चलाना।

सबसे पहले, हम एलज़मा कंप्रेसर के साथ एन्क्रिप्शन का उपयोग किए बिना ऑपरेशन का परीक्षण करेंगे:

प्रत्येक टेस्ट रन का रनिंग टाइम:

प्रक्षेपण 1
प्रक्षेपण 2
प्रक्षेपण 3

39m45s
40m20s
40m3s

7m36s
8m3s
7m48s

15m35s
15m48s
15m38s

यदि आप एईएस का उपयोग करके एन्क्रिप्शन सक्षम करते हैं, तो परिणाम काफी करीब हैं:

एन्क्रिप्शन के साथ, समान डेटा पर परिचालन समय:

प्रक्षेपण 1
प्रक्षेपण 2
प्रक्षेपण 3

43m40s
44m12s
44m3s

8m3s
8m15s
8m12s

15m0s
15m40s
15m25s

यदि एन्क्रिप्शन को एलज़ो का उपयोग करके संपीड़न के साथ जोड़ा जाता है, तो यह इस तरह दिखता है:

समय:

प्रक्षेपण 1
प्रक्षेपण 2
प्रक्षेपण 3

18m2s
18m15s
18m12s

5m13s
5m24s
5m20s

8m48s
9m3s
8m51s

परिणामी रिपॉजिटरी का आकार अपेक्षाकृत 13GB के समान था। इसका मतलब है कि डिडुप्लीकेशन सही ढंग से काम कर रहा है। इसके अलावा, पहले से ही संपीड़ित डेटा पर, एलज़ो का उपयोग ध्यान देने योग्य प्रभाव देता है; कुल परिचालन समय के संदर्भ में, ज़बैकअप डुप्लिकेटी/डुप्लिकेटी के करीब आता है, लेकिन लाइब्रसिंक पर आधारित डेटा से 2-5 गुना पीछे रहता है।

फायदे स्पष्ट हैं - बैकअप स्टोरेज सर्वर पर डिस्क स्थान की बचत। जहां तक ​​रिपॉजिटरी चेकिंग टूल का सवाल है, zbackup के लेखक उन्हें प्रदान नहीं करते हैं; दोष-सहिष्णु डिस्क सरणी या क्लाउड प्रदाता का उपयोग करने की अनुशंसा की जाती है।

कुल मिलाकर, एक बहुत अच्छा प्रभाव, इस तथ्य के बावजूद कि परियोजना लगभग 3 वर्षों से रुकी हुई है (अंतिम सुविधा अनुरोध लगभग एक वर्ष पहले था, लेकिन कोई प्रतिक्रिया नहीं हुई)।

बोर्गबैकअप का परीक्षण

बोर्गबैकअप अटारी का एक कांटा है, जो ज़बैकअप के समान एक और प्रणाली है। पायथन में लिखा गया, इसमें zbackup के समान क्षमताओं की एक सूची है, लेकिन इसके अतिरिक्त यह भी हो सकता है:

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

प्रदर्शन जांच

बोर्गबैकअप बेंचमार्क क्रूड ssh://backup_server/repo/path local_dir

परिणाम निम्नवत थे:

सी-जेड-बिग 96.51 एमबी/एस (10 100.00 एमबी पूर्ण-शून्य फ़ाइलें: 10.36 सेकंड)
आर-जेड-बिग 57.22 एमबी/एस (10 100.00 एमबी पूर्ण-शून्य फ़ाइलें: 17.48 सेकंड)
यू-जेड-बिग 253.63 एमबी/एस (10 100.00 एमबी पूर्ण-शून्य फ़ाइलें: 3.94 सेकंड)
डी-जेड-बिग 351.06 एमबी/एस (10 100.00 एमबी पूर्ण-शून्य फ़ाइलें: 2.85 सेकंड)
सी-आर-बिग 34.30 एमबी/सेकंड (10 100.00 एमबी यादृच्छिक फ़ाइलें: 29.15 सेकंड)
आर-आर-बिग 60.69 एमबी/एस (10 100.00 एमबी यादृच्छिक फ़ाइलें: 16.48 सेकंड)
यू-आर-बिग 311.06 एमबी/एस (10 100.00 एमबी यादृच्छिक फ़ाइलें: 3.21 सेकंड)
डी-आर-बिग 72.63 एमबी/एस (10 100.00 एमबी यादृच्छिक फ़ाइलें: 13.77 सेकंड)
सी-जेड-मीडियम 108.59 एमबी/एस (1000 1.00 एमबी पूर्ण-शून्य फ़ाइलें: 9.21 सेकंड)
आर-जेड-मीडियम 76.16 एमबी/एस (1000 1.00 एमबी पूर्ण-शून्य फ़ाइलें: 13.13 सेकंड)
यू-जेड-मीडियम 331.27 एमबी/एस (1000 1.00 एमबी पूर्ण-शून्य फ़ाइलें: 3.02 सेकंड)
डी-जेड-मीडियम 387.36 एमबी/एस (1000 1.00 एमबी पूर्ण-शून्य फ़ाइलें: 2.58 सेकंड)
सी-आर-मीडियम 37.80 एमबी/सेकंड (1000 1.00 एमबी यादृच्छिक फ़ाइलें: 26.45 सेकंड)
आर-आर-मीडियम 68.90 एमबी/एस (1000 1.00 एमबी यादृच्छिक फ़ाइलें: 14.51 सेकंड)
यू-आर-मीडियम 347.24 एमबी/एस (1000 1.00 एमबी यादृच्छिक फ़ाइलें: 2.88 सेकंड)
डी-आर-मीडियम 48.80 एमबी/सेकेंड (1000 1.00 एमबी यादृच्छिक फ़ाइलें: 20.49 सेकंड)
सी-जेड-स्मॉल 11.72 एमबी/एस (10000 10.00 केबी पूर्ण-शून्य फ़ाइलें: 8.53 सेकंड)
आर-जेड-स्मॉल 32.57 एमबी/एस (10000 10.00 केबी पूर्ण-शून्य फ़ाइलें: 3.07 सेकंड)
यू-जेड-स्मॉल 19.37 एमबी/एस (10000 10.00 केबी पूर्ण-शून्य फ़ाइलें: 5.16 सेकंड)
डी-जेड-स्मॉल 33.71 एमबी/एस (10000 10.00 केबी पूर्ण-शून्य फ़ाइलें: 2.97 सेकंड)
सी-आर-स्मॉल 6.85 एमबी/एस (10000 10.00 केबी यादृच्छिक फ़ाइलें: 14.60 सेकंड)
आर-आर-स्मॉल 31.27 एमबी/एस (10000 10.00 केबी यादृच्छिक फ़ाइलें: 3.20 सेकंड)
यू-आर-स्मॉल 12.28 एमबी/सेकेंड (10000 10.00 केबी यादृच्छिक फ़ाइलें: 8.14 सेकंड)
डी-आर-स्मॉल 18.78 एमबी/सेकंड (10000 10.00 केबी यादृच्छिक फ़ाइलें: 5.32 सेकंड)

परीक्षण करते समय, फ़ाइल प्रकार (संपीड़न ऑटो) निर्धारित करने के लिए संपीड़न अनुमान का उपयोग किया जाएगा, और परिणाम इस प्रकार होंगे:

सबसे पहले, आइए देखें कि यह एन्क्रिप्शन के बिना कैसे काम करता है:

समय:

प्रक्षेपण 1
प्रक्षेपण 2
प्रक्षेपण 3

4m6s
4m10s
4m5s

56s
58s
54s

1m26s
1m34s
1m30s

यदि आप रिपॉजिटरी प्राधिकरण (प्रमाणीकृत मोड) सक्षम करते हैं, तो परिणाम करीब होंगे:

समय:

प्रक्षेपण 1
प्रक्षेपण 2
प्रक्षेपण 3

4m11s
4m20s
4m12s

1m0s
1m3s
1m2s

1m30s
1m34s
1m31s

जब एईएस एन्क्रिप्शन सक्रिय किया गया, तो परिणाम ज्यादा खराब नहीं हुए:

प्रक्षेपण 1
प्रक्षेपण 2
प्रक्षेपण 3

4m55s
5m2s
4m58s

1m0s
1m2s
1m0s

1m49s
1m50s
1m50s

और यदि आप एईएस को ब्लेक में बदलते हैं, तो स्थिति पूरी तरह से सुधर जाएगी:

समय:

प्रक्षेपण 1
प्रक्षेपण 2
प्रक्षेपण 3

4m33s
4m43s
4m40s

59s
1m0s
1m0s

1m38s
1m43s
1m40s

जैसा कि zbackup के मामले में, रिपॉजिटरी का आकार 13GB था और उससे भी थोड़ा कम, जो आम तौर पर अपेक्षित होता है। मैं चलने के समय से बहुत प्रसन्न था; यह लाइब्रसिंक पर आधारित समाधानों के बराबर है, जो अधिक व्यापक क्षमताएं प्रदान करता है। मैं पर्यावरण चर के माध्यम से विभिन्न पैरामीटर सेट करने की क्षमता से भी प्रसन्न था, जो स्वचालित मोड में बोर्गबैकअप का उपयोग करते समय एक बहुत ही गंभीर लाभ देता है। मैं बैकअप के दौरान लोड से भी प्रसन्न था: प्रोसेसर लोड को देखते हुए, बोर्गबैकअप 1 थ्रेड में काम करता है।

इसे इस्तेमाल करने पर कोई खास नुकसान नहीं हुआ।

रेस्टिक परीक्षण

इस तथ्य के बावजूद कि रेस्टिक एक बिल्कुल नया समाधान है (पहले 2 उम्मीदवार 2013 और उससे भी पहले ज्ञात थे), इसमें काफी अच्छी विशेषताएं हैं। गो में लिखा है.

जब zbackup के साथ तुलना की जाती है, तो यह अतिरिक्त रूप से देता है:

• भंडार की अखंडता की जाँच करना (भागों में जाँच सहित)।
• बैकअप संग्रहीत करने के लिए समर्थित प्रोटोकॉल और प्रदाताओं की एक विशाल सूची, साथ ही क्लाउड समाधानों के लिए rclone - rsync के लिए समर्थन।
• 2 बैकअप की एक दूसरे से तुलना करना।
• फ़्यूज़ के माध्यम से रिपॉजिटरी को माउंट करना।

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

परिणाम निम्नवत थे:

समय:

प्रक्षेपण 1
प्रक्षेपण 2
प्रक्षेपण 3

5m25s
5m50s
5m38s

35s
38s
36s

1m54s
2m2s
1m58s

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

सबसे अधिक संभावना है, प्रोग्राम डेटा स्टोरेज सर्वर पर डिस्क सबसिस्टम के प्रदर्शन द्वारा सीमित है, जैसा कि पहले से ही rsync के मामले में था। रिपॉजिटरी का आकार 13GB था, ठीक zbackup या borgbackup की तरह, इस समाधान का उपयोग करते समय कोई स्पष्ट नुकसान नहीं था।

निष्कर्ष

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

निष्कर्ष

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

बोर्गबैकअप मूल रूप से कोई बदतर नहीं है, लेकिन ज़ेडबैकअप को शायद बेहतर तरीके से प्रतिस्थापित किया गया है। सच है, 3-2-1 नियम काम करता है यह सुनिश्चित करने के लिए zbackup का अभी भी उपयोग किया जा सकता है। उदाहरण के लिए, (lib)rsync-आधारित बैकअप सुविधाओं के अतिरिक्त।

घोषणा

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

के द्वारा प्रकाशित किया गया: पावेल डेमकोविच

स्रोत: www.habr.com