बैकअप, भाग 3: अवलोकन और परीक्षण दोहराव, डुप्लिकेट

यह आलेख बैकअप उपकरण का वर्णन करता है जो बैकअप सर्वर पर अभिलेखागार बनाकर बैकअप देता है।

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

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

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

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

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

बैकअप व्यवहार:

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

संदर्भ मान के रूप में, निम्न कमांड चलाएँ:

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

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

रनटाइम 3 एम 12 एस। यह देखा जा सकता है कि गति बैकअप स्टोरेज सर्वर के डिस्क सबसिस्टम पर आराम करती है, जैसा कि 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" 

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

निष्पादन का समय 10 मी 30 हो गया, क्योंकि 2 प्रक्रियाएं प्राप्त करने वाले पक्ष पर शुरू की गईं - अड़चन फिर से एक एकल-थ्रेडेड कंप्रेसर, और एक छोटे एन्क्रिप्शन ओवरहेड थे।

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

परीक्षण दोहराव

एन्क्रिप्टेड टार अभिलेखागार बनाकर द्वैधता अजगर बैकअप सॉफ्टवेयर है।

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

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

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

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

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

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

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

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

यह सॉफ्टवेयर C # में लिखा गया है, मोनो से पुस्तकालयों के एक सेट का उपयोग करके लॉन्च किया गया है। एक GUI और साथ ही एक cli संस्करण भी है।

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

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

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

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

सामान्य तौर पर, शुरुआती लोगों के लिए पर्याप्त मित्रता सहित कार्यक्रम का एक काफी सकारात्मक प्रभाव है।

परिणाम

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

निष्कर्ष

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

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

घोषणा

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

Finnix द्वारा पोस्ट किया गया