बॅकअप, भाग 1: उद्देश, पद्धती आणि तंत्रज्ञानाचे पुनरावलोकन

तुम्हाला बॅकअप घेण्याची गरज का आहे? शेवटी, उपकरणे खूप, खूप विश्वासार्ह आहेत आणि त्याशिवाय, "क्लाउड" आहेत जे भौतिक सर्व्हरपेक्षा विश्वासार्हतेमध्ये चांगले आहेत: योग्य कॉन्फिगरेशनसह, "क्लाउड" सर्व्हर पायाभूत सुविधांच्या भौतिक सर्व्हरच्या अपयशातून सहजपणे टिकून राहू शकतो आणि सेवा वापरकर्त्यांच्या दृष्टिकोनातून, वेळेच्या सेवेमध्ये एक लहान, केवळ लक्षणीय उडी असेल. याव्यतिरिक्त, माहितीच्या डुप्लिकेशनसाठी "अतिरिक्त" प्रोसेसर वेळ, डिस्क लोड आणि नेटवर्क रहदारीसाठी पैसे द्यावे लागतात.

एक आदर्श प्रोग्राम जलद चालतो, मेमरी लीक होत नाही, छिद्र नसतो आणि अस्तित्वात नाही.

-अज्ञात

प्रोग्रॅम अजूनही प्रोटीन डेव्हलपर्स द्वारे लिहिलेले असल्याने, आणि अनेकदा कोणतीही चाचणी प्रक्रिया नसल्यामुळे, तसेच प्रोग्राम्स क्वचितच "सर्वोत्तम पद्धती" वापरून वितरित केले जातात (जे स्वतः प्रोग्राम देखील आहेत आणि म्हणूनच अपूर्ण आहेत), सिस्टम प्रशासकांना बर्‍याचदा समस्या सोडवाव्या लागतात ज्या थोडक्यात वाटतात परंतु संक्षिप्तपणे: “ते कसे होते त्याकडे परत या”, “बेस सामान्य ऑपरेशनवर आणा”, “हळूहळू कार्य करते - परत रोल करा” आणि माझे आवडते “मला काय माहित नाही, परंतु ते ठीक करा”.

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

पूर्ण शक्तीने वाढणाऱ्या आणि मौल्यवान डेटावर लटकणाऱ्या समस्यांचे काय करावे? जिवंत विकासकांना पुनर्स्थित करण्यासाठी काहीही नाही आणि नजीकच्या भविष्यात ते शक्य होईल हे तथ्य नाही. दुसरीकडे, केवळ काही प्रकल्प पूर्णतः सिद्ध करण्यात यशस्वी झाले आहेत की कार्यक्रम हेतूनुसार कार्य करेल आणि इतर, तत्सम प्रकल्पांसाठी पुरावे घेणे आणि लागू करणे शक्य होणार नाही. तसेच, अशा पुराव्यासाठी खूप वेळ लागतो आणि त्यासाठी विशेष कौशल्ये आणि ज्ञान आवश्यक असते आणि यामुळे मुदती लक्षात घेऊन त्यांचा वापर होण्याची शक्यता कमी होते. याव्यतिरिक्त, माहिती संचयित करण्यासाठी, प्रक्रिया करण्यासाठी आणि प्रसारित करण्यासाठी अल्ट्रा-फास्ट, स्वस्त आणि असीम विश्वासार्ह तंत्रज्ञान कसे वापरावे हे आम्हाला अद्याप माहित नाही. असे तंत्रज्ञान, जर ते अस्तित्त्वात असतील तर, संकल्पनांच्या स्वरूपात आहेत, किंवा - बहुतेकदा - केवळ विज्ञान कल्पनारम्य पुस्तके आणि चित्रपटांमध्ये.

चांगले कलाकार कॉपी करतात, महान कलाकार चोरी करतात.

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

सर्वात यशस्वी उपाय आणि आश्चर्यकारकपणे सोप्या गोष्टी सहसा घडतात जेथे संकल्पना, तंत्रज्ञान, ज्ञान आणि विज्ञानाचे क्षेत्र जे पहिल्या दृष्टीक्षेपात पूर्णपणे विसंगत आहेत.

उदाहरणार्थ, पक्षी आणि विमानांना पंख असतात, परंतु कार्यात्मक समानता असूनही - काही मोडमध्ये ऑपरेशनचे तत्त्व समान असते आणि तांत्रिक समस्या त्याच प्रकारे सोडवल्या जातात: पोकळ हाडे, मजबूत आणि हलके सामग्रीचा वापर इ. - परिणाम पूर्णपणे भिन्न आहेत, जरी खूप समान आहेत. आमच्या तंत्रज्ञानामध्ये आपण पाहत असलेली उत्तम उदाहरणे देखील मोठ्या प्रमाणात निसर्गाकडून घेतली जातात: जहाजे आणि पाणबुड्यांचे दाबलेले कंपार्टमेंट हे अॅनिलिड्सशी थेट साधर्म्य आहे; रेड अॅरे तयार करणे आणि डेटा अखंडता तपासणे - डीएनए साखळी डुप्लिकेट करणे; तसेच जोडलेले अवयव, मध्यवर्ती मज्जासंस्था (हृदयाचे ऑटोमेशन) आणि रिफ्लेक्स - इंटरनेटवरील स्वायत्त प्रणालींपासून वेगवेगळ्या अवयवांच्या कार्याचे स्वातंत्र्य. अर्थात, “हेड-ऑन” तयार सोल्यूशन्स घेणे आणि लागू करणे ही समस्यांनी भरलेली आहे, परंतु कोणास ठाऊक आहे, कदाचित इतर कोणतेही उपाय नाहीत.

तू कुठे पडशील हे मला माहीत असतं तर मी पेंढ्या टाकल्या असत्या!

- बेलारशियन लोक म्हण

याचा अर्थ असा की ज्यांना हे करायचे आहे त्यांच्यासाठी बॅकअप प्रती महत्वाच्या आहेत:

• कमीतकमी डाउनटाइमसह किंवा अगदी त्याशिवाय देखील आपल्या सिस्टमचे कार्य पुनर्संचयित करण्यात सक्षम व्हा
• धैर्याने कार्य करा, कारण त्रुटीच्या बाबतीत नेहमी रोलबॅकची शक्यता असते
• हेतुपुरस्सर डेटा भ्रष्टाचाराचे परिणाम कमी करा

येथे एक छोटा सिद्धांत आहे

कोणतेही वर्गीकरण अनियंत्रित आहे. निसर्ग वर्गीकरण करत नाही. आम्ही वर्गीकरण करतो कारण ते आमच्यासाठी अधिक सोयीचे आहे. आणि आम्ही डेटानुसार वर्गीकरण करतो जे आम्ही देखील अनियंत्रितपणे घेतो.

- जीन ब्रुलर

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

ब्लॉक डेटा स्टोरेजचा अर्थ असा आहे की एक भौतिक उपकरण आहे जिथे डेटा विशिष्ट निश्चित भागांमध्ये, ब्लॉक्समध्ये लिहिला जातो. ब्लॉक्स एका विशिष्ट पत्त्यावर प्रवेश केले जातात; प्रत्येक ब्लॉकला डिव्हाइसमध्ये स्वतःचा पत्ता असतो.

बॅकअप सामान्यतः डेटाचे ब्लॉक कॉपी करून तयार केले जाते. डेटा अखंडता सुनिश्चित करण्यासाठी, कॉपी करताना नवीन ब्लॉक्सचे रेकॉर्डिंग तसेच विद्यमान असलेल्या बदलांना निलंबित केले जाते. जर आपण सामान्य जगापासून एक साधर्म्य घेतले तर सर्वात जवळची गोष्ट म्हणजे समान क्रमांकित पेशी असलेली कोठडी.

लॉजिकल डिव्हाइस तत्त्वावर आधारित फाइल डेटा स्टोरेज ब्लॉक स्टोरेजच्या जवळ आहे आणि बहुतेक वेळा शीर्षस्थानी आयोजित केले जाते. महत्त्वाचे फरक म्हणजे स्टोरेज पदानुक्रम आणि मानवी वाचनीय नावांची उपस्थिती. एक अमूर्तता एका फाइलच्या स्वरूपात वाटप केली जाते - एक नामित डेटा क्षेत्र, तसेच एक निर्देशिका - एक विशेष फाइल ज्यामध्ये वर्णन आणि इतर फायलींमध्ये प्रवेश संग्रहित केला जातो. फाइल्स अतिरिक्त मेटाडेटासह पुरवल्या जाऊ शकतात: निर्मिती वेळ, प्रवेश ध्वज इ. बॅकअप सहसा अशा प्रकारे केले जातात: ते बदललेल्या फायली शोधतात, नंतर त्यांना समान संरचनेसह दुसर्‍या फाइल स्टोरेजमध्ये कॉपी करतात. डेटा अखंडता सहसा फायली लिहिल्या जात नसल्यामुळे लागू केली जाते. फाइल मेटाडेटा त्याच प्रकारे बॅकअप घेतला आहे. सर्वात जवळचे साधर्म्य म्हणजे लायब्ररी, ज्यामध्ये विविध पुस्तके असलेले विभाग आहेत आणि पुस्तकांच्या मानवी-वाचनीय नावांचा कॅटलॉग देखील आहे.

अलीकडे, आणखी एक पर्याय कधीकधी वर्णन केला जातो, ज्यामधून, तत्त्वानुसार, फाइल डेटा स्टोरेज सुरू झाले आणि ज्यामध्ये समान पुरातन वैशिष्ट्ये आहेत: ऑब्जेक्ट डेटा स्टोरेज.

हे फाइल स्टोरेजपेक्षा वेगळे आहे कारण त्यात एकापेक्षा जास्त नेस्टिंग (फ्लॅट स्कीम) नाही आणि फाइलची नावे, जरी मानवी वाचनीय असली तरीही, मशीनद्वारे प्रक्रिया करण्यासाठी अधिक योग्य आहेत. बॅकअप घेत असताना, ऑब्जेक्ट स्टोरेजला बहुतेकदा फाईल स्टोरेज प्रमाणेच हाताळले जाते, परंतु कधीकधी इतर पर्याय असतात.

— दोन प्रकारचे सिस्टम प्रशासक आहेत, जे बॅकअप घेत नाहीत आणि जे आधीच करतात.
- वास्तविक, तीन प्रकार आहेत: बॅकअप पुनर्संचयित केले जाऊ शकतात हे तपासणारे देखील आहेत.

-अज्ञात

हे देखील समजून घेण्यासारखे आहे की डेटा बॅकअप प्रक्रिया स्वतः प्रोग्रामद्वारे चालविली जाते, म्हणून त्याचे इतर कोणत्याही प्रोग्रामसारखेच तोटे आहेत. मानवी घटक, तसेच वैशिष्ट्यांवरील अवलंबित्व काढून टाकण्यासाठी (काढू नये!) - ज्याचा वैयक्तिकरित्या मजबूत प्रभाव पडत नाही, परंतु एकत्रितपणे एक लक्षणीय परिणाम देऊ शकतो - तथाकथित नियम 3-2-1. त्याचा उलगडा कसा करायचा याचे अनेक पर्याय आहेत, परंतु मला खालील व्याख्या अधिक आवडते: समान डेटाचे 3 संच संग्रहित केले जाणे आवश्यक आहे, 2 संच वेगवेगळ्या स्वरूपात संग्रहित केले जाणे आवश्यक आहे आणि 1 संच भौगोलिकदृष्ट्या रिमोट स्टोरेजमध्ये संग्रहित करणे आवश्यक आहे.

स्टोरेज फॉरमॅट खालीलप्रमाणे समजले पाहिजे:

• भौतिक स्टोरेज पद्धतीवर अवलंबित्व असल्यास, आम्ही भौतिक पद्धत बदलतो.
• लॉजिकल स्टोरेज पद्धतीवर अवलंबित्व असल्यास, आम्ही तार्किक पद्धत बदलतो.

3-2-1 नियमाचा जास्तीत जास्त प्रभाव साध्य करण्यासाठी, स्टोरेज फॉरमॅट दोन्ही प्रकारे बदलण्याची शिफारस केली जाते.

बॅकअपच्या तयारीच्या दृष्टिकोनातून त्याच्या इच्छित हेतूसाठी - कार्यक्षमता पुनर्संचयित करणे - "गरम" आणि "थंड" बॅकअपमध्ये फरक केला जातो. गरम लोक थंड लोकांपेक्षा फक्त एकाच गोष्टीत भिन्न असतात: ते वापरण्यासाठी त्वरित तयार असतात, तर थंड असलेल्यांना पुनर्प्राप्तीसाठी काही अतिरिक्त चरणांची आवश्यकता असते: डिक्रिप्शन, संग्रहणातून काढणे इ.

गरम आणि थंड प्रतींना ऑनलाइन आणि ऑफलाइन प्रतींमध्ये गोंधळात टाकू नका, जे डेटाचे भौतिक अलगाव सूचित करते आणि खरं तर, बॅकअप पद्धतींच्या वर्गीकरणाचे आणखी एक लक्षण आहे. त्यामुळे एक ऑफलाइन प्रत - जिथे ती पुनर्संचयित करणे आवश्यक आहे त्या प्रणालीशी थेट कनेक्ट केलेली नाही - एकतर गरम किंवा थंड असू शकते (पुनर्प्राप्तीसाठी तत्परतेच्या दृष्टीने). ऑनलाइन प्रत थेट उपलब्ध होऊ शकते जिथे ती पुनर्संचयित करणे आवश्यक आहे आणि बहुतेकदा ती गरम असते, परंतु थंड देखील असतात.

याव्यतिरिक्त, हे विसरू नका की बॅकअप प्रती तयार करण्याची प्रक्रिया स्वतःच एक बॅकअप प्रत तयार करून संपत नाही आणि मोठ्या प्रमाणात प्रती असू शकतात. म्हणून, पूर्ण बॅकअपमध्ये फरक करणे आवश्यक आहे, म्हणजे. जे इतर बॅकअप्सपासून स्वतंत्रपणे पुनर्संचयित केले जाऊ शकतात, तसेच विभेदक (वाढीव, भिन्नता, घट, इ.) प्रती - ज्या स्वतंत्रपणे पुनर्संचयित केल्या जाऊ शकत नाहीत आणि एक किंवा अधिक इतर बॅकअपच्या प्राथमिक पुनर्संचयनाची आवश्यकता आहे.

डिफरेंशियल इन्क्रिमेंटल बॅकअप हे बॅकअप स्टोरेज स्पेस वाचवण्याचा प्रयत्न आहे. अशा प्रकारे, मागील बॅकअपमधील बदललेला डेटा बॅकअप कॉपीवर लिहिला जातो.

डिफरेंशियल डिक्रीमेंटल समान हेतूसाठी तयार केले जातात, परंतु थोड्या वेगळ्या पद्धतीने: एक पूर्ण बॅकअप प्रत बनविली जाते, परंतु फक्त ताजी प्रत आणि मागील प्रत यांच्यातील फरक प्रत्यक्षात संग्रहित केला जातो.

स्वतंत्रपणे, स्टोरेजवर बॅकअप घेण्याची प्रक्रिया विचारात घेण्यासारखे आहे, जे डुप्लिकेटच्या संचयनाच्या अनुपस्थितीचे समर्थन करते. अशाप्रकारे, जर तुम्ही त्याच्या वर संपूर्ण बॅकअप लिहिल्यास, फक्त बॅकअपमधील फरक प्रत्यक्षात लिहिला जाईल, परंतु बॅकअप पुनर्संचयित करण्याची प्रक्रिया संपूर्ण कॉपीमधून पुनर्संचयित करण्यासारखी आणि पूर्णपणे पारदर्शक असेल.

ipsos custodes custodiet?

(स्वतः पहारेकरी कोण पहावे? - lat.)

जेव्हा बॅकअप प्रती नसतात तेव्हा हे खूप अप्रिय असते, परंतु बॅकअप प्रत बनवल्या गेल्यासारखे वाटत असल्यास ते खूपच वाईट आहे, परंतु पुनर्संचयित करताना ते पुनर्संचयित केले जाऊ शकत नाही कारण:

• स्त्रोत डेटाच्या अखंडतेशी तडजोड केली गेली आहे.
• बॅकअप स्टोरेज खराब झाले आहे.
• पुनर्संचयित करणे खूप मंद गतीने कार्य करते; आपण अंशतः पुनर्प्राप्त केलेला डेटा वापरू शकत नाही.

योग्यरित्या तयार केलेल्या बॅकअप प्रक्रियेने अशा टिप्पण्या विचारात घेतल्या पाहिजेत, विशेषतः पहिल्या दोन.

स्त्रोत डेटाच्या अखंडतेची अनेक प्रकारे हमी दिली जाऊ शकते. सर्वात सामान्यपणे खालील गोष्टी वापरल्या जातात: अ) ब्लॉक स्तरावर फाइल सिस्टमचे स्नॅपशॉट तयार करणे, ब) फाइल सिस्टमची स्थिती "फ्रीझ करणे", क) आवृत्ती स्टोरेजसह एक विशेष ब्लॉक डिव्हाइस, डी) फाइल्सचे अनुक्रमिक रेकॉर्डिंग किंवा ब्लॉक पुनर्प्राप्ती दरम्यान डेटा सत्यापित केला गेला आहे याची खात्री करण्यासाठी चेकसम देखील लागू केले जातात.

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

पुनर्प्राप्तीचा वेग वाढवण्यासाठी, पुनर्प्राप्तीसाठी एकाधिक प्रक्रियांसह डेटा पुनर्प्राप्तीचा वापर केला जातो - जर धीमे नेटवर्क किंवा स्लो डिस्क सिस्टमच्या स्वरूपात कोणतीही अडचण नसेल. अंशतः पुनर्प्राप्त केलेल्या डेटासह परिस्थितीवर जाण्यासाठी, आपण बॅकअप प्रक्रिया तुलनेने लहान उपकार्यांमध्ये खंडित करू शकता, ज्यापैकी प्रत्येक स्वतंत्रपणे केला जातो. अशाप्रकारे, पुनर्प्राप्ती वेळेचा अंदाज लावताना सातत्याने कार्यप्रदर्शन पुनर्संचयित करणे शक्य होते. ही समस्या बहुतेक वेळा संघटनात्मक विमानात (एसएलए) असते, म्हणून आम्ही यावर तपशीलवार विचार करणार नाही.

मसाल्यांचा तज्ञ तो प्रत्येक पदार्थात मिसळणारा नसतो, परंतु जो कधीही त्यात अतिरिक्त काही घालत नाही तो असतो.

-IN. सिन्याव्स्की

सिस्टम प्रशासकांद्वारे वापरल्या जाणार्‍या सॉफ्टवेअरशी संबंधित सराव भिन्न असू शकतात, परंतु सामान्य तत्त्वे अजूनही, एक किंवा दुसर्या प्रकारे, समान आहेत, विशेषतः:

• तयार-तयार उपाय वापरण्याची जोरदार शिफारस केली जाते.
• प्रोग्राम्सने अंदाजानुसार कार्य केले पाहिजे, म्हणजे. कोणतीही अदस्तांकित वैशिष्ट्ये किंवा अडथळे नसावेत.
• प्रत्येक प्रोग्राम सेट करणे इतके सोपे असावे की तुम्हाला प्रत्येक वेळी मॅन्युअल किंवा फसवणूक पत्रक वाचण्याची गरज नाही.
• शक्य असल्यास, उपाय सार्वत्रिक असावा, कारण सर्व्हर त्यांच्या हार्डवेअर वैशिष्ट्यांमध्ये मोठ्या प्रमाणात बदलू शकतात.

ब्लॉक डिव्हाइसेसवरून बॅकअप घेण्यासाठी खालील सामान्य प्रोग्राम आहेत:

• dd, सिस्टीम प्रशासनाच्या दिग्गजांना परिचित, यात समान प्रोग्राम देखील समाविष्ट आहेत (उदाहरणार्थ समान dd_rescue).
• काही फाइल सिस्टीममध्ये तयार केलेल्या युटिलिटीज फाइल सिस्टमचा डंप तयार करतात.
• सर्वभक्षी उपयुक्तता; उदाहरणार्थ partclone.
• स्वतःचे, अनेकदा मालकीचे, निर्णय; उदाहरणार्थ, NortonGhost आणि नंतर.

फाइल सिस्टमसाठी, ब्लॉक उपकरणांसाठी लागू असलेल्या पद्धतींचा वापर करून बॅकअप समस्या अंशतः सोडवली जाते, परंतु समस्या अधिक कार्यक्षमतेने सोडवली जाऊ शकते, उदाहरणार्थ:

• Rsync, फाईल सिस्टीमची स्थिती समक्रमित करण्यासाठी एक सामान्य उद्देश कार्यक्रम आणि प्रोटोकॉल.
• अंगभूत संग्रहण साधने (ZFS).
• तृतीय पक्ष संग्रहण साधने; सर्वात लोकप्रिय प्रतिनिधी टार आहे. इतर आहेत, उदाहरणार्थ, दार - आधुनिक प्रणालींच्या उद्देशाने टारची जागा.

बॅकअप कॉपी तयार करताना डेटा सुसंगतता सुनिश्चित करण्यासाठी सॉफ्टवेअर टूल्सबद्दल स्वतंत्रपणे उल्लेख करणे योग्य आहे. सर्वात सामान्यतः वापरलेले पर्याय आहेत:

• फाइल सिस्टमला केवळ-वाचनीय मोडमध्ये माउंट करणे (केवळ वाचनीय), किंवा फाइल सिस्टम गोठवणे (फ्रीज) - पद्धत मर्यादित लागू आहे.
• फाइल प्रणाली किंवा ब्लॉक साधने (LVM, ZFS) च्या स्थितीचे स्नॅपशॉट तयार करणे.
• इंप्रेशन आयोजित करण्यासाठी तृतीय-पक्ष साधनांचा वापर, अगदी काही कारणास्तव (हॉटकॉपी सारखे कार्यक्रम) पूर्वीचे मुद्दे प्रदान केले जाऊ शकत नाहीत अशा प्रकरणांमध्ये.
• कॉपी-ऑन-चेंज तंत्र (CopyOnWrite), तथापि, ते बहुतेकदा वापरलेल्या फाइल सिस्टमशी (BTRFS, ZFS) जोडलेले असते.

तर, एका लहान सर्व्हरसाठी तुम्हाला खालील आवश्यकता पूर्ण करणारी बॅकअप योजना प्रदान करणे आवश्यक आहे:

• वापरण्यास सोपा - ऑपरेशन दरम्यान कोणत्याही विशेष अतिरिक्त चरणांची आवश्यकता नाही, कॉपी तयार करण्यासाठी आणि पुनर्संचयित करण्यासाठी किमान चरणे.
• युनिव्हर्सल - मोठ्या आणि लहान सर्व्हरवर कार्य करते; सर्व्हरची संख्या वाढवताना किंवा स्केलिंग करताना हे महत्त्वाचे आहे.
• पॅकेज मॅनेजरद्वारे किंवा "डाउनलोड आणि अनपॅक" सारख्या एक किंवा दोन कमांडद्वारे स्थापित केले जाते.
• स्थिर - एक मानक किंवा दीर्घ-स्थापित स्टोरेज स्वरूप वापरले जाते.
• कामात वेगवान.

जे कमी किंवा जास्त आवश्यकता पूर्ण करतात त्यांच्याकडील अर्जदार:

• rdiff-बॅकअप
• आरएसएनॅपशॉट
• burp
• नक्कल
• नक्कल
• डूप करू द्या
• अरुंद
• zbackup
• विश्रांती
• borgbackup

खालील वैशिष्ट्यांसह एक आभासी मशीन (XenServer वर आधारित) चाचणी बेंच म्हणून वापरली जाईल:

• 4 कोर 2.5 GHz,
• 16 जीबी रॅम,
• 50 GB हायब्रिड स्टोरेज (SSD वर कॅशिंग असलेली स्टोरेज सिस्टीम व्हर्च्युअल डिस्क आकाराच्या 20%) विभाजन न करता वेगळ्या व्हर्च्युअल डिस्कच्या स्वरूपात,
• 200 Mbps इंटरनेट चॅनेल.

जवळजवळ समान मशीन बॅकअप रिसीव्हर सर्व्हर म्हणून वापरली जाईल, फक्त 500 GB हार्ड ड्राइव्हसह.

ऑपरेटिंग सिस्टम - Centos 7 x64: मानक विभाजन, अतिरिक्त विभाजन डेटा स्रोत म्हणून वापरले जाईल.

प्रारंभिक डेटा म्हणून, 40 GB मीडिया फाइल्स आणि mysql डेटाबेस असलेली WordPress साइट घेऊ. व्हर्च्युअल सर्व्हर वैशिष्ट्यांमध्ये मोठ्या प्रमाणात बदलत असल्याने आणि चांगल्या पुनरुत्पादनासाठी, येथे आहे

sysbench वापरून सर्व्हर चाचणी परिणाम.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu रन
sysbench 1.1.0-18a9f86 (बंडल केलेले LuaJIT 2.1.0-beta3 वापरून)
खालील पर्यायांसह चाचणी चालवित आहे:
थ्रेडची संख्या: 4
सध्याच्या वेळेपासून यादृच्छिक क्रमांक जनरेटर सुरू करत आहे

प्राइम संख्या मर्यादा: 20000

कामगार थ्रेड सुरू करत आहे...

धागे सुरू झाले!

सीपीयू वेग:
इव्हेंट प्रति सेकंद: 836.69

थ्रुपुट
इव्हेंट/से (eps): 836.6908
वेळ निघून गेली: 30.0039s
एकूण कार्यक्रमांची संख्या: 25104

विलंब (ms):
मि: ०,५१
सरासरी: ४.७८
कमाल: १०.५
95वी टक्केवारी: 10.46
बेरीज: 119923.64

थ्रेड्स निष्पक्षता:
कार्यक्रम (avg/stddev): 6276.0000/13.91
अंमलबजावणीची वेळ (avg/stddev): 29.9809/0.01

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=रीड मेमरी रन
sysbench 1.1.0-18a9f86 (बंडल केलेले LuaJIT 2.1.0-beta3 वापरून)
खालील पर्यायांसह चाचणी चालवित आहे:
थ्रेडची संख्या: 4
सध्याच्या वेळेपासून यादृच्छिक क्रमांक जनरेटर सुरू करत आहे

खालील पर्यायांसह मेमरी गती चाचणी चालवणे:
ब्लॉक आकार: 1KiB
एकूण आकार: 102400MiB
ऑपरेशन: वाचा
व्याप्ती: जागतिक

कामगार थ्रेड सुरू करत आहे...

धागे सुरू झाले!

एकूण ऑपरेशन्स: 50900446 (1696677.10 प्रति सेकंद)

49707.47 MiB हस्तांतरित (1656.91 MiB/सेकंद)

थ्रुपुट
इव्हेंट/से (eps): 1696677.1017
वेळ निघून गेली: 30.0001s
एकूण कार्यक्रमांची संख्या: 50900446

विलंब (ms):
मि: ०,५१
सरासरी: ४.७८
कमाल: १०.५
95वी टक्केवारी: 0.00
बेरीज: 39106.74

थ्रेड्स निष्पक्षता:
कार्यक्रम (avg/stddev): 12725111.5000/137775.15
अंमलबजावणीची वेळ (avg/stddev): 9.7767/0.10

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.1.0-18a9f86 (बंडल केलेले LuaJIT 2.1.0-beta3 वापरून)
खालील पर्यायांसह चाचणी चालवित आहे:
थ्रेडची संख्या: 4
सध्याच्या वेळेपासून यादृच्छिक क्रमांक जनरेटर सुरू करत आहे

खालील पर्यायांसह मेमरी गती चाचणी चालवणे:
ब्लॉक आकार: 1KiB
एकूण आकार: 102400MiB
ऑपरेशन: लिहा
व्याप्ती: जागतिक

कामगार थ्रेड सुरू करत आहे...

धागे सुरू झाले!

एकूण ऑपरेशन्स: 35910413 (1197008.62 प्रति सेकंद)

35068.76 MiB हस्तांतरित (1168.95 MiB/सेकंद)

थ्रुपुट
इव्हेंट/से (eps): 1197008.6179
वेळ निघून गेली: 30.0001s
एकूण कार्यक्रमांची संख्या: 35910413

विलंब (ms):
मि: ०,५१
सरासरी: ४.७८
कमाल: १०.५
95वी टक्केवारी: 0.00
बेरीज: 43604.83

थ्रेड्स निष्पक्षता:
कार्यक्रम (avg/stddev): 8977603.2500/233905.84
अंमलबजावणीची वेळ (avg/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-beta3 वापरून)
खालील पर्यायांसह चाचणी चालवित आहे:
थ्रेडची संख्या: 4
सध्याच्या वेळेपासून यादृच्छिक क्रमांक जनरेटर सुरू करत आहे

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

धागे सुरू झाले!

थ्रुपुट
वाचा: 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

विलंब (ms):
मि: ०,५१
सरासरी: ४.७८
कमाल: १०.५
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