बॅकअप भाग 3: डुप्लिसीटीचे पुनरावलोकन आणि चाचणी, डुप्लिकेट

ही नोट बॅकअप टूल्सची चर्चा करते जे बॅकअप सर्व्हरवर संग्रहण तयार करून बॅकअप करतात.

आवश्यकता पूर्ण करणार्‍यांपैकी डुप्लिसीटी (ज्यात डेजा डुपच्या रूपात एक छान इंटरफेस आहे) आणि डुप्लिकेटी आहेत.

आणखी एक अतिशय उल्लेखनीय बॅकअप साधन dar आहे, परंतु त्यामध्ये पर्यायांची खूप विस्तृत सूची असल्याने - चाचणी पद्धतीमध्ये ते सक्षम असलेल्या केवळ 10% कव्हर करते - आम्ही सध्याच्या चक्राचा भाग म्हणून त्याची चाचणी करत नाही.

अपेक्षित निकाल

दोन्ही उमेदवार एक किंवा दुसर्या प्रकारे संग्रहण तयार करत असल्याने, नियमित डांबर मार्गदर्शक म्हणून वापरले जाऊ शकते.

याव्यतिरिक्त, आम्ही बॅकअप कॉपी तयार करून स्टोरेज सर्व्हरवरील डेटा स्टोरेज किती चांगल्या प्रकारे ऑप्टिमाइझ केले आहे याचे मूल्यांकन करू ज्यामध्ये फक्त संपूर्ण कॉपी आणि फायलींची वर्तमान स्थिती, किंवा मागील आणि वर्तमान संग्रहणांमध्ये (वाढीव, घटता, इ.) फरक आहे. .

बॅकअप तयार करताना वर्तन:

1. बॅकअप स्टोरेज सर्व्हरवरील फाइल्सची तुलनेने कमी संख्या (बॅकअप प्रतींच्या संख्येशी किंवा GB मधील डेटाच्या आकाराशी तुलना करता), परंतु त्यांचा आकार खूप मोठा आहे (दहापट ते शेकडो मेगाबाइट्स).
2. रेपॉजिटरी आकारात फक्त बदल समाविष्ट असतील - कोणतेही डुप्लिकेट संग्रहित केले जाणार नाहीत, त्यामुळे रेपॉजिटरी आकार rsync-आधारित सॉफ्टवेअरपेक्षा लहान असेल.
3. कम्प्रेशन आणि/किंवा एन्क्रिप्शन वापरताना जास्त CPU लोडची अपेक्षा करा आणि बॅकअप स्टोरेज सर्व्हरवर संग्रहण आणि/किंवा एन्क्रिप्शन प्रक्रिया चालू असल्यास नेटवर्क आणि डिस्क लोड होण्याची शक्यता आहे.

संदर्भ मूल्य म्हणून खालील कमांड चालवू:

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 वापरू शकता 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, backblaze, 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% वाढला, जो एक चांगला बोनस असू शकतो.

दुर्दैवाने, हा प्रोग्राम डिरेक्ट्रीचे नाव बदलून परिस्थिती योग्यरित्या शोधण्यात अक्षम आहे आणि परिणामी रिपॉझिटरी आकार बदलांच्या आकाराइतका (म्हणजे सर्व 18GB) असल्याचे दिसून आले, परंतु स्पष्टपणे बॅकअपसाठी अविश्वासू सर्व्हर वापरण्याची क्षमता. हे वर्तन कव्हर करते.

डुप्लिकेट चाचणी

हे सॉफ्टवेअर 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