बैकअप, भाग 1: उद्देश्य, विधियों और प्रौद्योगिकियों की समीक्षा

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

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

-अज्ञात

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

डेवलपर्स के लापरवाह काम, या परिस्थितियों के संयोजन के परिणामस्वरूप उत्पन्न होने वाली तार्किक त्रुटियों के अलावा, साथ ही निर्माण कार्यक्रमों की छोटी विशेषताओं की अधूरी जानकारी या गलतफहमी - जिसमें कनेक्टिंग और सिस्टम वाले, ऑपरेटिंग सिस्टम, ड्राइवर और फर्मवेयर शामिल हैं - अन्य त्रुटियाँ भी हैं. उदाहरण के लिए, अधिकांश डेवलपर्स रनटाइम पर भरोसा करते हैं, भौतिक कानूनों के बारे में पूरी तरह से भूल जाते हैं, जिन्हें प्रोग्राम का उपयोग करके दरकिनार करना अभी भी असंभव है। इसमें डिस्क सबसिस्टम की अनंत विश्वसनीयता और सामान्य तौर पर, किसी भी डेटा स्टोरेज सबसिस्टम (रैम और प्रोसेसर कैश सहित!), और प्रोसेसर पर शून्य प्रोसेसिंग समय, और नेटवर्क पर ट्रांसमिशन के दौरान और नेटवर्क पर प्रोसेसिंग के दौरान त्रुटियों की अनुपस्थिति शामिल है। प्रोसेसर, और नेटवर्क विलंबता, जो 0 के बराबर है। आपको कुख्यात समय सीमा की उपेक्षा नहीं करनी चाहिए, क्योंकि यदि आप इसे समय पर पूरा नहीं करते हैं, तो नेटवर्क और डिस्क संचालन की बारीकियों से भी बदतर समस्याएं होंगी।

उन समस्याओं का क्या करें जो पूरी ताकत से उठती हैं और मूल्यवान डेटा पर हावी हो जाती हैं? जीवित डेवलपर्स को बदलने के लिए कुछ भी नहीं है, और यह सच नहीं है कि यह निकट भविष्य में संभव होगा। दूसरी ओर, केवल कुछ परियोजनाएँ पूरी तरह से यह साबित करने में सफल रही हैं कि कार्यक्रम इच्छानुसार काम करेगा, और अन्य समान परियोजनाओं के लिए साक्ष्य लेना और लागू करना आवश्यक नहीं होगा। इसके अलावा, ऐसे साक्ष्यों में बहुत समय लगता है और विशेष कौशल और ज्ञान की आवश्यकता होती है, और यह समय सीमा को ध्यान में रखते हुए उनके उपयोग की संभावना को व्यावहारिक रूप से कम कर देता है। इसके अलावा, हम अभी तक यह नहीं जानते हैं कि सूचनाओं के भंडारण, प्रसंस्करण और संचारण के लिए अल्ट्रा-फास्ट, सस्ती और असीम विश्वसनीय तकनीक का उपयोग कैसे किया जाए। ऐसी प्रौद्योगिकियाँ, यदि वे मौजूद हैं, तो अवधारणाओं के रूप में हैं, या - अक्सर - केवल विज्ञान कथा पुस्तकों और फिल्मों में।

अच्छे कलाकार नक़ल करते हैं महान कलाकार चोरी करते हैं।

-पब्लो पिकासो।

सबसे सफल समाधान और आश्चर्यजनक रूप से सरल चीजें आमतौर पर वहां होती हैं जहां अवधारणाएं, प्रौद्योगिकियां, ज्ञान और विज्ञान के क्षेत्र जो पहली नज़र में बिल्कुल असंगत होते हैं, मिलते हैं।

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

काश मुझे मालूम होता कि तुम कहाँ गिरोगे, तो तिनके बिछा देता!

-बेलारूसी लोक कहावत

इसका मतलब यह है कि बैकअप प्रतियां उन लोगों के लिए महत्वपूर्ण हैं जो:

• न्यूनतम डाउनटाइम के साथ, या इसके बिना भी अपने सिस्टम के संचालन को बहाल करने में सक्षम हों
• साहसपूर्वक कार्य करें, क्योंकि त्रुटि की स्थिति में रोलबैक की संभावना हमेशा बनी रहती है
• जानबूझकर डेटा भ्रष्टाचार के परिणामों को कम करें

यहाँ एक छोटा सा सिद्धांत है

कोई भी वर्गीकरण मनमाना है। प्रकृति वर्गीकरण नहीं करती. हम वर्गीकृत करते हैं क्योंकि यह हमारे लिए अधिक सुविधाजनक है। और हम डेटा के अनुसार वर्गीकरण करते हैं जिसे हम मनमाने ढंग से भी लेते हैं।

-जीन ब्रुलर

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

ब्लॉक डेटा स्टोरेज का तात्पर्य है कि एक भौतिक उपकरण है जहां डेटा को कुछ निश्चित भागों, ब्लॉकों में लिखा जाता है। ब्लॉक को एक निश्चित पते पर एक्सेस किया जाता है; डिवाइस के भीतर प्रत्येक ब्लॉक का अपना पता होता है।

बैकअप आमतौर पर डेटा के ब्लॉक कॉपी करके बनाया जाता है। डेटा अखंडता सुनिश्चित करने के लिए, कॉपी करते समय नए ब्लॉकों की रिकॉर्डिंग, साथ ही मौजूदा ब्लॉकों में परिवर्तन को निलंबित कर दिया जाता है। यदि हम सामान्य दुनिया से सादृश्य लेते हैं, तो निकटतम चीज़ समान संख्या वाली कोशिकाओं वाली एक कोठरी है।

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

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

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

— सिस्टम प्रशासक दो प्रकार के होते हैं, एक जो बैकअप नहीं बनाते हैं, और दूसरे जो पहले से ही ऐसा करते हैं।
- दरअसल, ये तीन प्रकार के होते हैं: ऐसे भी होते हैं जो जांचते हैं कि बैकअप को बहाल किया जा सकता है।

-अज्ञात

यह भी समझने योग्य है कि डेटा बैकअप प्रक्रिया स्वयं प्रोग्रामों द्वारा की जाती है, इसलिए इसमें किसी अन्य प्रोग्राम की तरह ही सभी नुकसान हैं। मानव कारक, साथ ही विशेषताओं पर निर्भरता को हटाने (खत्म नहीं करने के लिए!) - जिसका व्यक्तिगत रूप से कोई मजबूत प्रभाव नहीं होता है, लेकिन एक साथ ध्यान देने योग्य प्रभाव दे सकता है - तथाकथित नियम 3-2-1. इसे समझने के लिए कई विकल्प हैं, लेकिन मुझे निम्नलिखित व्याख्या अधिक पसंद है: एक ही डेटा के 3 सेट संग्रहीत किए जाने चाहिए, 2 सेट विभिन्न स्वरूपों में संग्रहीत किए जाने चाहिए, और 1 सेट भौगोलिक रूप से दूरस्थ भंडारण में संग्रहीत किया जाना चाहिए।

भंडारण प्रारूप को इस प्रकार समझा जाना चाहिए:

• यदि भौतिक भंडारण विधि पर निर्भरता है, तो हम भौतिक विधि को बदल देते हैं।
• यदि तार्किक भंडारण विधि पर निर्भरता है, तो हम तार्किक विधि को बदल देते हैं।

3-2-1 नियम के अधिकतम प्रभाव को प्राप्त करने के लिए, भंडारण प्रारूप को दोनों तरीकों से बदलने की अनुशंसा की जाती है।

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

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

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

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

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

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

क्विस कस्टोडिएट ipsos कस्टोड?

(पहरेदार स्वयं कौन पहरा देगा? - अव्य.)

यह बहुत अप्रिय है जब कोई बैकअप प्रतियां नहीं होती हैं, लेकिन यह बहुत बुरा होता है अगर ऐसा लगता है कि बैकअप प्रतिलिपि बनाई गई है, लेकिन पुनर्स्थापित करते समय यह पता चलता है कि इसे पुनर्स्थापित नहीं किया जा सकता है क्योंकि:

• स्रोत डेटा की अखंडता से समझौता किया गया है।
• बैकअप संग्रहण क्षतिग्रस्त है.
• पुनर्स्थापना बहुत धीमी गति से काम करती है; आप उस डेटा का उपयोग नहीं कर सकते जो आंशिक रूप से पुनर्प्राप्त किया गया है।

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

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

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

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

मसालों का विशेषज्ञ वह नहीं है जो उन्हें हर व्यंजन में जोड़ता है, बल्कि वह है जो कभी भी इसमें कुछ भी अतिरिक्त नहीं जोड़ता है।

-में। सिन्याव्स्की

सिस्टम प्रशासकों द्वारा उपयोग किए जाने वाले सॉफ़्टवेयर के संबंध में प्रथाएँ भिन्न हो सकती हैं, लेकिन सामान्य सिद्धांत अभी भी, किसी न किसी रूप में, समान हैं, विशेष रूप से:

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

ब्लॉक डिवाइस से बैकअप लेने के लिए निम्नलिखित सामान्य प्रोग्राम हैं:

• dd, सिस्टम प्रशासन के दिग्गजों से परिचित, इसमें समान कार्यक्रम भी शामिल हैं (उदाहरण के लिए वही dd_rescue)।
• कुछ फ़ाइल सिस्टम में निर्मित उपयोगिताएँ जो फ़ाइल सिस्टम का डंप बनाती हैं।
• सर्वाहारी उपयोगिताएँ; उदाहरण के लिए पार्टक्लोन।
• स्वयं के, अक्सर स्वामित्व वाले, निर्णय; उदाहरण के लिए, नॉर्टनघोस्ट और बाद में।

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

• Rsync, फ़ाइल सिस्टम की स्थिति को सिंक्रनाइज़ करने के लिए एक सामान्य प्रयोजन कार्यक्रम और प्रोटोकॉल।
• अंतर्निर्मित संग्रह उपकरण (ZFS)।
• तृतीय पक्ष संग्रह उपकरण; सबसे लोकप्रिय प्रतिनिधि टार है। उदाहरण के लिए, अन्य भी हैं, डार - आधुनिक प्रणालियों के उद्देश्य से टार का प्रतिस्थापन।

बैकअप प्रतियां बनाते समय डेटा स्थिरता सुनिश्चित करने के लिए सॉफ़्टवेयर टूल के बारे में अलग से उल्लेख करना उचित है। सबसे अधिक उपयोग किए जाने वाले विकल्प हैं:

• फ़ाइल सिस्टम को रीड-ओनली मोड में माउंट करना, या फ़ाइल सिस्टम को फ़्रीज़ करना (फ्रीज़ करना) - विधि सीमित प्रयोज्यता की है।
• फ़ाइल सिस्टम या ब्लॉक डिवाइस (LVM, ZFS) की स्थिति के स्नैपशॉट बनाना।
• इंप्रेशन को व्यवस्थित करने के लिए तीसरे पक्ष के टूल का उपयोग, यहां तक ​​कि उन मामलों में भी जहां किसी कारण से पिछले बिंदु प्रदान नहीं किए जा सकते हैं (हॉटकॉपी जैसे कार्यक्रम)।
• हालाँकि, कॉपी-ऑन-चेंज तकनीक (CopyOnWrite), यह अक्सर प्रयुक्त फ़ाइल सिस्टम (BTRFS, ZFS) से जुड़ी होती है।

इसलिए, एक छोटे सर्वर के लिए आपको एक बैकअप योजना प्रदान करने की आवश्यकता है जो निम्नलिखित आवश्यकताओं को पूरा करती हो:

• उपयोग में आसान - ऑपरेशन के दौरान किसी विशेष अतिरिक्त कदम की आवश्यकता नहीं है, प्रतियां बनाने और पुनर्स्थापित करने के लिए न्यूनतम कदम।
• यूनिवर्सल - बड़े और छोटे दोनों सर्वरों पर काम करता है; सर्वरों की संख्या बढ़ाने या स्केलिंग करते समय यह महत्वपूर्ण है।
• एक पैकेज मैनेजर द्वारा, या "डाउनलोड और अनपैक" जैसे एक या दो कमांड में स्थापित किया गया।
• स्थिर - एक मानक या लंबे समय से स्थापित भंडारण प्रारूप का उपयोग किया जाता है।
• काम में तेजी.

उन आवेदकों में से जो कमोबेश आवश्यकताओं को पूरा करते हैं:

• rdiff-बैकअप
• rsnapshot
• burp
• डुप्लिकेट
• कपट
• डुबो देना
• देना
• ज़बैकअप
• रेस्टिक
• बोर्गबैकअप

निम्नलिखित विशेषताओं वाली एक वर्चुअल मशीन (XenServer पर आधारित) का उपयोग परीक्षण बेंच के रूप में किया जाएगा:

• 4 कोर 2.5 गीगाहर्ट्ज़,
• 16 जीबी रैम,
• विभाजन के बिना एक अलग वर्चुअल डिस्क के रूप में 50 जीबी हाइब्रिड स्टोरेज (वर्चुअल डिस्क आकार के 20% एसएसडी पर कैशिंग के साथ स्टोरेज सिस्टम),
• 200 एमबीपीएस इंटरनेट चैनल।

लगभग उसी मशीन का उपयोग बैकअप रिसीवर सर्वर के रूप में किया जाएगा, केवल 500 जीबी हार्ड ड्राइव के साथ।

ऑपरेटिंग सिस्टम - सेंटोस 7 x64: मानक विभाजन, अतिरिक्त विभाजन का उपयोग डेटा स्रोत के रूप में किया जाएगा।

प्रारंभिक डेटा के रूप में, आइए 40 जीबी मीडिया फ़ाइलों और एक MySQL डेटाबेस वाली एक वर्डप्रेस साइट लें। चूँकि वर्चुअल सर्वर विशेषताओं में बहुत भिन्न होते हैं, और बेहतर प्रतिलिपि प्रस्तुत करने योग्यता के लिए भी, यहाँ है

sysbench का उपयोग करके सर्वर परीक्षण परिणाम।sysbench --थ्रेड्स=4 --समय=30 --सीपीयू-मैक्स-प्राइम=20000 सीपीयू रन
sysbench 1.1.0-18a9f86 (बंडल किए गए LuaJIT 2.1.0-बीटा3 का उपयोग करके)
निम्नलिखित विकल्पों के साथ परीक्षण चलाना:
धागे की संख्या: 4
वर्तमान समय से यादृच्छिक संख्या जनरेटर प्रारंभ करना

अभाज्य संख्या सीमा: 20000

वर्कर थ्रेड आरंभ किया जा रहा है...

थ्रेड शुरू!

सीपीयू गति:
प्रति सेकंड घटनाएँ: 836.69

प्रवाह क्षमता:
इवेंट/एस (ईपीएस): 836.6908
बीता हुआ समय: 30.0039 सेकंड
आयोजनों की कुल संख्या: 25104

विलंबता (एमएस):
न्यूनतम: 2.38
औसत: 4.78
अधिकतम: 22.39
95वाँ प्रतिशत: 10.46
राशि: 119923.64

धागे निष्पक्षता:
घटनाएँ (avg/stddev): 6276.0000/13.91
निष्पादन समय (औसत/stddev): 29.9809/0.01

sysbench --threads=4 --समय=30 --मेमोरी-ब्लॉक-आकार=1K --मेमोरी-स्कोप=वैश्विक --मेमोरी-कुल-आकार=100G --मेमोरी-ऑपर=रीड मेमोरी रन
sysbench 1.1.0-18a9f86 (बंडल किए गए LuaJIT 2.1.0-बीटा3 का उपयोग करके)
निम्नलिखित विकल्पों के साथ परीक्षण चलाना:
धागे की संख्या: 4
वर्तमान समय से यादृच्छिक संख्या जनरेटर प्रारंभ करना

निम्नलिखित विकल्पों के साथ मेमोरी स्पीड परीक्षण चलाना:
ब्लॉक का आकार: 1KiB
कुल आकार: 102400MiB
ऑपरेशन: पढ़ें
दायरा: वैश्विक

वर्कर थ्रेड आरंभ किया जा रहा है...

थ्रेड शुरू!

कुल परिचालन: 50900446 (1696677.10 प्रति सेकंड)

49707.47 एमआईबी स्थानांतरित (1656.91 एमआईबी/सेकंड)

प्रवाह क्षमता:
इवेंट/एस (ईपीएस): 1696677.1017
बीता हुआ समय: 30.0001 सेकंड
आयोजनों की कुल संख्या: 50900446

विलंबता (एमएस):
न्यूनतम: 0.00
औसत: 0.00
अधिकतम: 24.01
95वाँ प्रतिशत: 0.00
राशि: 39106.74

धागे निष्पक्षता:
घटनाएँ (avg/stddev): 12725111.5000/137775.15
निष्पादन समय (औसत/stddev): 9.7767/0.10

sysbench --threads=4 --समय=30 --मेमोरी-ब्लॉक-आकार=1K --मेमोरी-स्कोप=वैश्विक --मेमोरी-कुल-आकार=100G --मेमोरी-ऑपर=मेमोरी रन लिखें
sysbench 1.1.0-18a9f86 (बंडल किए गए LuaJIT 2.1.0-बीटा3 का उपयोग करके)
निम्नलिखित विकल्पों के साथ परीक्षण चलाना:
धागे की संख्या: 4
वर्तमान समय से यादृच्छिक संख्या जनरेटर प्रारंभ करना

निम्नलिखित विकल्पों के साथ मेमोरी स्पीड परीक्षण चलाना:
ब्लॉक का आकार: 1KiB
कुल आकार: 102400MiB
ऑपरेशन: लिखें
दायरा: वैश्विक

वर्कर थ्रेड आरंभ किया जा रहा है...

थ्रेड शुरू!

कुल परिचालन: 35910413 (1197008.62 प्रति सेकंड)

35068.76 एमआईबी स्थानांतरित (1168.95 एमआईबी/सेकंड)

प्रवाह क्षमता:
इवेंट/एस (ईपीएस): 1197008.6179
बीता हुआ समय: 30.0001 सेकंड
आयोजनों की कुल संख्या: 35910413

विलंबता (एमएस):
न्यूनतम: 0.00
औसत: 0.00
अधिकतम: 16.90
95वाँ प्रतिशत: 0.00
राशि: 43604.83

धागे निष्पक्षता:
घटनाएँ (avg/stddev): 8977603.2500/233905.84
निष्पादन समय (औसत/stddev): 10.9012/0.41

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G फाइलियो रन
sysbench 1.1.0-18a9f86 (बंडल किए गए LuaJIT 2.1.0-बीटा3 का उपयोग करके)
निम्नलिखित विकल्पों के साथ परीक्षण चलाना:
धागे की संख्या: 4
वर्तमान समय से यादृच्छिक संख्या जनरेटर प्रारंभ करना

अतिरिक्त फ़ाइल खुले फ़्लैग: (कोई नहीं)
128 फ़ाइलें, प्रत्येक 8MiB
1GiB कुल फ़ाइल आकार
ब्लॉक का आकार 4KiB
आईओ अनुरोधों की संख्या: 0
संयुक्त यादृच्छिक IO परीक्षण के लिए पढ़ें/लिखें अनुपात: 1.50
आवधिक FSYNC सक्षम, प्रत्येक 100 अनुरोधों पर fsync() को कॉल करना।
परीक्षण के अंत में fsync() को कॉल करना, सक्षम।
सिंक्रोनस I/O मोड का उपयोग करना
यादृच्छिक आर/डब्ल्यू परीक्षण कर रहा हूँ
वर्कर थ्रेड आरंभ किया जा रहा है...

थ्रेड शुरू!

प्रवाह क्षमता:
पढ़ें: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
लिखें: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98

विलंबता (एमएस):
न्यूनतम: 0.00
औसत: 0.27
अधिकतम: 18.01
95वाँ प्रतिशत: 1.08
राशि: 238469.45

इस नोट की शुरुआत बड़ी होती है

बैकअप के बारे में लेखों की श्रृंखला

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

स्रोत: www.habr.com