बड़ी संख्या में छोटी फ़ाइलों का बैकअप

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

rdiff-बैकअप

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

rsnapshot

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

परीक्षण

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

परीक्षणों के लिए, 11 जीबी का एक यादृच्छिक परियोजना फ़ोल्डर लिया गया था, जिसमें घोंसले के शिकार की डिग्री और 230911 फ़ाइलों के 593 उपनिर्देशिकाएं थीं। फ़ाइल आकार 4 से 800KB तक तैरता है, जैसा कि ऊपर बताया गया है, यह ग्राफिक सामग्री में है। दोनों उपयोगिताओं का परीक्षण एक समय में किया गया था, बाहरी कारक लगभग पूरी तरह से अनुपस्थित थे (कोई अन्य उपयोगकर्ता, कार्यभार या भारी प्रक्रियाएं नहीं हैं)। समय की उपयोगिता का उपयोग करते हुए, परीक्षण कार्यों में से प्रत्येक के निष्पादन समय की गणना की गई थी, और इसके अलावा, तुलना के लिए, पीपीपी का उपयोग करके पूरी निर्देशिका की प्रतिलिपि बनाना:

पहली बैकअप - बैकअप लोकेशन 11090MB की पूरी कॉपी

	असली	उपयोगकर्ता	sys
cp	6m30.885s	0m1.068s	0m24.554s
rsnapshot	7m53.879s	1m57.299s	1m22.441s
rdiff-बैकअप	10m50.314s	3m26.073s	1m0.928s

पुनरारंभ करें (फ़ोल्डर में कोई परिवर्तन नहीं)

	असली	उपयोगकर्ता	sys
rsnapshot	0m10.129s	0m4.936s	0m6.708s
rdiff-बैकअप	1m3.969s	1m0.616s	0m2.048s

निर्देशिका के अंदर, एक यादृच्छिक फ़ोल्डर को डुप्लिकेट किया जाता है (कुल आकार 13267MB तक बढ़ जाता है)

	असली	उपयोगकर्ता	sys
rsnapshot	0m31.175s	0m22.001s	0m17.365s
rdiff-बैकअप	27m53.517s	1m58.819s	0m19.005s

निर्देशिका आकार बढ़ाने के बाद पुनरारंभ करना (अंतिम निष्पादन के बाद कोई परिवर्तन नहीं)

	असली	उपयोगकर्ता	sys
rsnapshot	0m11.477s	0m5.748s	0m7.368s
rdiff-बैकअप	1m16.366s	1m13.713s	0m1.912s

डुप्लिकेट फ़ोल्डर को हटा दें, निर्देशिका के आकार को मूल तक कम कर देता है

	असली	उपयोगकर्ता	sys
rsnapshot	0m13.885s	0m6.388s	0m9.077s
rdiff-बैकअप	52m55.794s	2m1.560s	0m21.941s

संशोधन के बिना टेस्ट पुनरारंभ

	असली	उपयोगकर्ता	sys
rsnapshot	0m11.250s	0m5.132s	0m7.068s
rdiff-बैकअप	1m2.380s	1m0.088s	0m1.792s

परिणाम

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