बैकअप भाग 3: नकल, नकल की समीक्षा और परीक्षण

यह नोट बैकअप टूल पर चर्चा करता है जो बैकअप सर्वर पर संग्रह बनाकर बैकअप करता है।

आवश्यकताओं को पूरा करने वालों में डुप्लिकेटी (जिसमें डीजा डुप के रूप में एक अच्छा इंटरफ़ेस है) और डुप्लिकेटी शामिल हैं।

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

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

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

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

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

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

आइए निम्नलिखित कमांड को संदर्भ मान के रूप में चलाएँ:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

निष्पादन परिणाम इस प्रकार थे:

निष्पादन समय 3m12s. यह देखा जा सकता है कि गति बैकअप स्टोरेज सर्वर के डिस्क सबसिस्टम द्वारा सीमित है, जैसा कि उदाहरण में है rsync. बस थोड़ा सा तेज़, क्योंकि... रिकॉर्डिंग एक फ़ाइल में जाती है।

इसके अलावा, संपीड़न का मूल्यांकन करने के लिए, आइए वही विकल्प चलाएँ, लेकिन बैकअप सर्वर साइड पर संपीड़न सक्षम करें:

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

परिणाम हैं:

निष्पादन समय 10m11s. सबसे अधिक संभावना है कि बाधा प्राप्त करने वाले सिरे पर एकल-प्रवाह कंप्रेसर है।

वही आदेश, लेकिन इस परिकल्पना का परीक्षण करने के लिए मूल डेटा के साथ सर्वर पर संपीड़न स्थानांतरित किया गया कि बाधा एक एकल-थ्रेडेड कंप्रेसर है।

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

यह इस प्रकार निकला:

निष्पादन का समय 9m37s था। कंप्रेसर द्वारा एक कोर पर लोड स्पष्ट रूप से दिखाई देता है, क्योंकि नेटवर्क स्थानांतरण गति और स्रोत डिस्क सबसिस्टम पर लोड समान है।

एन्क्रिप्शन का मूल्यांकन करने के लिए, आप एक अतिरिक्त कमांड कनेक्ट करके ओपनएसएल या जीपीजी का उपयोग कर सकते हैं openssl या gpg पाइप में. संदर्भ के लिए इस तरह एक कमांड होगी:

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

परिणाम इस प्रकार सामने आये:

निष्पादन का समय 10m30s हो गया, क्योंकि प्राप्त पक्ष पर 2 प्रक्रियाएं चल रही थीं - बाधा फिर से एक सिंगल-थ्रेडेड कंप्रेसर है, साथ ही छोटा एन्क्रिप्शन ओवरहेड भी है।

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

डुप्लिकेट परीक्षण

डुप्लिकेटी टार प्रारूप में एन्क्रिप्टेड अभिलेखागार बनाकर बैकअप के लिए एक पायथन सॉफ्टवेयर है।

वृद्धिशील अभिलेखागार के लिए, librsync का उपयोग किया जाता है, इसलिए आप इसमें वर्णित व्यवहार की अपेक्षा कर सकते हैं श्रृंखला में पिछली पोस्ट.

बैकअप को gnupg का उपयोग करके एन्क्रिप्ट और हस्ताक्षरित किया जा सकता है, जो बैकअप संग्रहीत करने के लिए विभिन्न प्रदाताओं (s3, बैकब्लेज़, gdrive, आदि) का उपयोग करते समय महत्वपूर्ण है।

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

एन्क्रिप्शन के बिना चलने पर हमें ये परिणाम मिले

स्पॉइलर

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

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

16m33s
17m20s
16m30s

8m29s
9m3s
8m45s

5m21s
6m04s
5m53s

और जब gnupg एन्क्रिप्शन सक्षम किया जाता है, तो 2048 बिट्स के कुंजी आकार के साथ परिणाम यहां दिए गए हैं:

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

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

17m22s
17m32s
17m28s

8m52s
9m13s
9m3s

5m48s
5m40s
5m30s

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

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

एन्क्रिप्शन को सक्षम करने से प्रोग्राम के चलने के समय में उल्लेखनीय वृद्धि नहीं हुई, लेकिन इससे प्रोसेसर लोड लगभग 10% बढ़ गया, जो काफी अच्छा बोनस हो सकता है।

दुर्भाग्य से, यह प्रोग्राम निर्देशिका का नाम बदलने के साथ स्थिति का सही ढंग से पता लगाने में असमर्थ था, और परिणामी रिपॉजिटरी का आकार परिवर्तनों के आकार (यानी, सभी 18 जीबी) के बराबर निकला, लेकिन बैकअप के लिए एक अविश्वसनीय सर्वर का उपयोग करने की क्षमता स्पष्ट रूप से थी इस व्यवहार को कवर करता है.

डुप्लिकेट परीक्षण

यह सॉफ़्टवेयर C# में लिखा गया है और मोनो से लाइब्रेरीज़ के एक सेट का उपयोग करके चलता है। इसमें GUI के साथ-साथ CLI संस्करण भी है।

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

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

आइए देखें कि यह समाधान कौन से संकेतक उत्पन्न कर सकता है:

यदि आप एन्क्रिप्शन बंद कर देते हैं (और WEBGUI ऐसा करने की अनुशंसा नहीं करता है), तो परिणाम इस प्रकार हैं:

समय:

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

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

एन्क्रिप्शन सक्षम होने पर, एईएस का उपयोग करते हुए, यह इस तरह दिखता है:

समय:

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

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

और यदि आप बाहरी प्रोग्राम gnupg का उपयोग करते हैं, तो निम्नलिखित परिणाम सामने आते हैं:

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

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

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

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

कुल मिलाकर, कार्यक्रम का काफी सकारात्मक प्रभाव पड़ा, जिसमें नए लोगों के लिए काफी अनुकूल होना भी शामिल है।

निष्कर्ष

दोनों उम्मीदवारों ने धीरे-धीरे काम किया, लेकिन सामान्य तौर पर, नियमित टार की तुलना में, प्रगति हुई है, कम से कम डुप्लिकेटी के साथ। ऐसी प्रगति की कीमत भी स्पष्ट है - एक ध्यान देने योग्य बोझ
प्रोसेसर. सामान्य तौर पर, परिणामों की भविष्यवाणी में कोई विशेष विचलन नहीं होता है।

निष्कर्ष

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

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

घोषणा

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

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

स्रोत: www.habr.com