GitLab तुम्हाला मोठ्या NextCloud स्टोरेजचा बॅकअप घेण्यास कशी मदत करते

अहो हाब्र!

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

इंस्टॉलेशनच्या वैशिष्ट्यांमुळे उद्भवलेल्या समस्या म्हणजे भरपूर डेटा आहे. नेक्स्टक्लाउड, रिडंडंसी, व्यक्तिनिष्ठ कारणे आणि बरेच काही द्वारे प्रदान केलेली आवृत्ती अनेक डुप्लिकेट तयार करते.

prehistory

नेक्स्टक्लॉडचे व्यवस्थापन करताना, प्रभावी बॅकअप आयोजित करण्याची समस्या उद्भवते, जी एन्क्रिप्ट केलेली असणे आवश्यक आहे, कारण डेटा मौल्यवान आहे.

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

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

प्रथम, इनपुट डेटा पाहू. आम्हाला गरज आहे:

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

बॅकअप व्यवस्थापित करण्याच्या समस्येचे निराकरण करण्यासाठी, आम्ही GitLab स्थापित केले. टॅकलद्वारे अधिक तपशील.

अर्थात, अशा समस्येचे निराकरण करणारे आम्ही पहिले नाही, परंतु असे दिसते की आमचा व्यावहारिक, कष्टाने मिळवलेला अनुभव मनोरंजक असू शकतो आणि आम्ही ते सामायिक करण्यास तयार आहोत.

आमच्या कंपनीचे ओपन सोर्स पॉलिसी असल्याने, आम्ही ओपन सोर्स सोल्यूशन शोधत होतो. त्या बदल्यात, आम्ही आमच्या घडामोडी सामायिक करतो आणि त्या पोस्ट करतो. उदाहरणार्थ, GitHub वर आहे नेक्स्टक्लाउडसाठी आमचे प्लगइन, जे आम्ही ग्राहकांना प्रदान करतो, अपघाताने किंवा हेतुपुरस्सर हटवल्याच्या बाबतीत डेटा सुरक्षितता वाढवतो.

बॅकअप साधने

आम्ही बॅकअप तयार करण्याचे साधन निवडून उपाय पद्धती शोधण्यास सुरुवात केली.

नियमित टार + gzip चांगले कार्य करत नाही - डेटा डुप्लिकेट आहे. एका वाढीमध्ये सहसा खूप कमी वास्तविक बदल असतात आणि एकाच फाईलमधील बर्याच डेटाची पुनरावृत्ती होते.
आणखी एक समस्या आहे - वितरित डेटा स्टोरेजची रिडंडंसी. आम्ही minio वापरतो आणि त्याचा डेटा मुळात अनावश्यक आहे. किंवा तुम्हाला minio द्वारेच बॅकअप घ्यावा लागला - ते लोड करा आणि फाइल सिस्टममधील सर्व स्पेसर वापरा आणि, कमी महत्त्वाचे नाही, काही बादल्या आणि मेटा-माहिती विसरण्याचा धोका आहे. किंवा डुप्लिकेशन वापरा.

डुप्लिकेशनसह बॅकअप साधने मुक्त स्त्रोतामध्ये उपलब्ध आहेत (हॅब्रेवर तेथे होती लेख या थीम बद्दल) आणि आमचे अंतिम स्पर्धक होते बोर्ग и विश्रांती. आमची दोन ऍप्लिकेशन्सची तुलना खाली आहे, परंतु आत्ता आम्ही तुम्हाला सांगू की आम्ही संपूर्ण योजना कशी आयोजित केली.

बॅकअप व्यवस्थापित करणे

बोर्ग आणि रेस्टिक चांगले आहेत, परंतु कोणत्याही उत्पादनामध्ये केंद्रीकृत नियंत्रण यंत्रणा नाही. व्यवस्थापन आणि नियंत्रणाच्या उद्देशासाठी, आम्ही एक साधन निवडले आहे जे आम्ही आधीच लागू केले आहे, ज्याशिवाय आम्ही ऑटोमेशनसह आमच्या कामाची कल्पना करू शकत नाही - हे सुप्रसिद्ध CI/CD - GitLab आहे.

कल्पना खालीलप्रमाणे आहे: नेक्स्टक्लाउड डेटा संचयित करणार्‍या प्रत्येक नोडवर gitlab-runner स्थापित केले आहे. धावपटू एका शेड्यूलवर एक स्क्रिप्ट चालवतो जो बॅकअप प्रक्रियेवर लक्ष ठेवतो आणि तो बोर्ग किंवा रेस्टिक लाँच करतो.

आम्हाला काय मिळाले? अंमलबजावणीकडून अभिप्राय, बदलांवर सोयीस्कर नियंत्रण, त्रुटी आढळल्यास तपशील.

येथे येथे GitHub वर आम्ही विविध कार्यांसाठी स्क्रिप्टची उदाहरणे पोस्ट केली आणि आम्ही ती केवळ नेक्स्टक्लाउडच्याच नव्हे तर इतर अनेक सेवांच्या बॅकअपमध्ये संलग्न केली. तुम्हाला ते स्वहस्ते कॉन्फिगर करायचे नसल्यास तेथे शेड्युलर देखील आहे (आणि आम्हाला ते नको आहे) आणि .gitlab-ci.yml

Gitlab API मध्ये अद्याप CI/CD कालबाह्य बदलण्याचा कोणताही मार्ग नाही, परंतु तो लहान आहे. ते वाढवण्याची गरज आहे, असे म्हणा 1d.

गिटलॅब, सुदैवाने, केवळ कमिटनुसारच नव्हे तर केवळ शेड्यूलनुसार लॉन्च करू शकते, आपल्याला नेमके हेच हवे आहे.

आता रॅपर स्क्रिप्टबद्दल.

आम्ही या स्क्रिप्टसाठी खालील अटी सेट केल्या आहेत:

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

GitLab मध्ये संपूर्ण लॉग आर्टिफॅक्ट म्हणून सेव्ह केला आहे; जर काही त्रुटी नसेल, तर लॉग हटवला जाईल. आम्ही स्क्रिप्ट बॅशमध्ये लिहितो.

ओपन सोर्स संदर्भात कोणत्याही सूचना आणि टिप्पण्या विचारात घेतल्यास आम्हाला आनंद होईल - स्वागत आहे.

या कसे कार्य करते

बॅश एक्झिक्युटरसह धावणारा बॅकअप नोडवर लॉन्च केला जातो. शेड्युलरनुसार, जॉब सीआय/सीडी एका विशेष सलगम नावाने लाँच केली जाते. धावपटू अशा कामांसाठी युनिव्हर्सल रॅपर स्क्रिप्ट लाँच करतो, तो बॅकअप रेपॉजिटरी, माउंट पॉइंट्स आणि आपल्याला पाहिजे असलेल्या सर्व गोष्टींची वैधता तपासतो, नंतर बॅकअप घेतो आणि जुनी साफ करतो. पूर्ण झालेला बॅकअप स्वतः S3 वर पाठवला जातो.

आम्ही या योजनेनुसार कार्य करतो - हे बाह्य AWS प्रदाता किंवा रशियन समतुल्य आहे (ते वेगवान आहे आणि डेटा रशियन फेडरेशन सोडत नाही). किंवा आम्ही या हेतूंसाठी क्लायंटसाठी त्याच्या साइटवर एक वेगळा minio क्लस्टर स्थापित करतो. आम्ही हे सहसा सुरक्षिततेच्या कारणांसाठी करतो, जेव्हा क्लायंटला डेटा त्यांच्या सर्किटमधून बाहेर पडू इच्छित नाही.

आम्ही ssh द्वारे बॅकअप पाठविण्याचे वैशिष्ट्य वापरले नाही. हे सुरक्षितता जोडत नाही, आणि S3 प्रदात्याच्या नेटवर्क क्षमता आमच्या एका ssh मशीनपेक्षा खूप जास्त आहेत.

तुमच्‍या स्‍थानिक मशीनला हॅकरपासून संरक्षित करण्‍यासाठी, कारण तो S3 वरील डेटा मिटवू शकतो, तुम्‍ही आवृत्ती सक्षम करणे आवश्‍यक आहे.
बॅकअप नेहमी बॅकअप एन्क्रिप्ट करतो.

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

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

रशियनमध्ये रीडमी

मुख्य कार्ये

• prepare प्रशिक्षण
• testcheck तयारी तपासणी
• maincommand मुख्य संघ
• forcepostscript फंक्शन जे शेवटी किंवा चुकून अंमलात आणले जाते. आम्ही ते विभाजन अनमाउंट करण्यासाठी वापरतो.

सेवा कार्ये

• cleanup आम्ही त्रुटी रेकॉर्ड करतो किंवा लॉग फाइल मिटवतो.
• checklog त्रुटी असलेल्या ओळीच्या घटनेसाठी लॉगचे विश्लेषण करा.
• ret बाहेर पडा हँडलर.
• checktimeout कालबाह्य तपासा.

पर्यावरण

• VERBOSE=1 आम्ही तत्काळ स्क्रीनवर त्रुटी प्रदर्शित करतो (stdout).
• SAVELOGSONSUCCES=1 यशावर लॉग जतन करा.
• INIT_REPO_IF_NOT_EXIST=1 ते अस्तित्वात नसल्यास भांडार तयार करा. डीफॉल्टनुसार अक्षम.
• TIMEOUT मुख्य ऑपरेशनसाठी जास्तीत जास्त वेळ. तुम्ही शेवटी 'm', 'h' किंवा 'd' म्हणून सेट करू शकता.

जुन्या प्रतींसाठी स्टोरेज मोड. डीफॉल्ट:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

स्क्रिप्टमधील व्हेरिएबल्स

• ERROR_STRING — त्रुटीसाठी लॉग इन चेकसाठी स्ट्रिंग.
• EXTRACT_ERROR_STRING — त्रुटी असल्यास शो स्ट्रिंगसाठी अभिव्यक्ती.
• KILL_TIMEOUT_SIGNAL - कालबाह्य झाल्यास मारण्यासाठी सिग्नल.
• TAIL — स्क्रीनवर त्रुटींसह किती स्ट्रिंग आहेत.
• COLORMSG - संदेशाचा रंग (डिफॉल्ट पिवळा).

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

रेस्टिक वि बोर्ग

बोर्ग आणि रेस्टिक यांच्यातही तुलना आहेत येथे Habré वर, आणि आमच्याकडे फक्त दुसरे बनवण्याचे काम नव्हते, परंतु आमचे स्वतःचे. आमच्या डेटावर, आमच्या तपशीलांसह ते कसे दिसेल हे आमच्यासाठी महत्त्वाचे होते. आम्ही त्यांना आणतो.

आमचे निवड निकष, आधीच नमूद केलेल्या व्यतिरिक्त (डुप्लिकेशन, जलद पुनर्प्राप्ती इ.):

• अपूर्ण कामाचा प्रतिकार. मारण्यासाठी तपासा -9.
• डिस्कवरील आकार.
• संसाधनांची आवश्यकता (CPU, मेमरी).
• संग्रहित blobs आकार.
• S3 सह काम करत आहे.
• अखंडता तपासणी.

चाचणीसाठी, आम्ही वास्तविक डेटा आणि एकूण 1,6 TB आकारासह एक क्लायंट घेतला.
परिस्थिती.

बोर्गला S3 सह थेट कसे कार्य करावे हे माहित नाही आणि आम्ही डिस्कला फ्यूज म्हणून माउंट केले. मूर्ख. रेस्टिकने ते S3 वरच पाठवले.

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

नेटवर्कचा प्रभाव कमी करण्यासाठी, आम्ही स्थानिक प्रदाता - यांडेक्स क्लाउडचा वापर केला.

तुलना चाचणी परिणाम.

• आणखी रीस्टार्टसह किल -9 दोन्ही यशस्वी झाले.
• डिस्कवरील आकार. बोर्ग संकुचित करू शकतो, त्यामुळे परिणाम अपेक्षित आहेत.

बॅकअप
आकार

बोर्ग
562Gb

विश्रांती
628Gb

• CPU द्वारे
  डिफॉल्ट कॉम्प्रेशनसह बोर्ग स्वतःच थोडेसे वापरतो, परंतु त्याचे मुल्यांकन मुर्ख प्रक्रियेसह एकत्रितपणे करणे आवश्यक आहे. एकूण, ते तुलनात्मक आहेत आणि समान चाचणी आभासी मशीनवर सुमारे 1,2 कोर वापरतात.
• स्मृती. रेस्टिक अंदाजे 0,5GB आहे, बोर्ग अंदाजे 200MB आहे. परंतु सिस्टम फाइल कॅशेच्या तुलनेत हे सर्व नगण्य आहे. त्यामुळे अधिक मेमरी वाटप करण्याचा सल्ला दिला जातो.
• ब्लॉबच्या आकारातील फरक धक्कादायक होता.

बॅकअप
आकार

बोर्ग
सुमारे 500MB

विश्रांती
सुमारे 5MB

• रेस्टिकचा S3 अनुभव उत्कृष्ट आहे. गोफीद्वारे बोर्गसोबत काम केल्याने कोणतेही प्रश्न उद्भवत नाहीत, परंतु हे लक्षात आले आहे की कॅशे पूर्णपणे रीसेट करण्यासाठी बॅकअप पूर्ण झाल्यानंतर उमाउंट करण्याचा सल्ला दिला जातो. S3 चे वैशिष्ठ्य म्हणजे अंडर-पंप केलेले भाग कधीही बादलीमध्ये पाठवले जाणार नाहीत, याचा अर्थ अपूर्ण भरलेल्या डेटामुळे मोठे नुकसान होते.
• अखंडता तपासणी दोन्ही प्रकरणांमध्ये चांगली कार्य करते, परंतु वेग लक्षणीय भिन्न आहे.
  आरामशीर 3,5 तास.
  बोर्ग, 100GB SSD फाइल कॅशेसह - 5 तास.डेटा स्थानिक डिस्कवर असल्यास अंदाजे समान गतीचा परिणाम.
  बोर्ग थेट S3 वरून कॅशेशिवाय वाचतो 33 तास. राक्षसी लांब.

सर्वात महत्त्वाची गोष्ट अशी आहे की बोर्ग कॉम्प्रेस करू शकतो आणि त्यात मोठे ब्लॉब आहेत - जे S3 मध्ये स्टोरेज आणि GET/PUT ऑपरेशन्स स्वस्त करतात. परंतु हे अधिक जटिल आणि हळू पडताळणीच्या खर्चावर येते. पुनर्प्राप्तीच्या गतीबद्दल, आम्हाला कोणताही फरक जाणवला नाही. रेस्टिक नंतरचे बॅकअप (पहिल्या नंतर) थोडा जास्त वेळ घेते, परंतु लक्षणीय नाही.

निवडीमध्ये शेवटचे परंतु किमान नाही समुदायाचा आकार होता.

आणि आम्ही बोर्ग निवडला.

कॉम्प्रेशन बद्दल काही शब्द

बोर्गच्या शस्त्रागारात एक उत्कृष्ट नवीन कॉम्प्रेशन अल्गोरिदम आहे - zstd. कॉम्प्रेशन गुणवत्ता gzip पेक्षा वाईट नाही, परंतु खूप वेगवान आहे. आणि डीफॉल्ट lz4 च्या गतीशी तुलना करता येईल.

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

बोर्गकडे एक बोनस कॉम्प्रेशन मोड आहे - जर फाइलमध्ये उच्च एन्ट्रॉपी असेल तर कॉम्प्रेशन अजिबात लागू केले जात नाही, ज्यामुळे वेग वाढतो. तयार करताना पर्यायाने सक्षम केले
-C auto,zstd
zstd अल्गोरिदमसाठी
तर या पर्यायासह, डिफॉल्ट कॉम्प्रेशनच्या तुलनेत, आम्हाला मिळाले
560Gb आणि 562Gb अनुक्रमे. वरील उदाहरणातील डेटा, मी तुम्हाला आठवण करून देतो, कॉम्प्रेशनशिवाय परिणाम 628Gb आहे. 2GB फरकाच्या परिणामाने आम्हाला काहीसे आश्चर्यचकित केले, परंतु आम्हाला वाटले की आम्ही शेवटी ते निवडू. auto,zstd.

बॅकअप सत्यापन पद्धत

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

समान योजना वापरुन, आम्ही अँटीव्हायरससह फायली तपासतो (वास्तविकतेनंतर). शेवटी, वापरकर्ते नेक्स्टक्लॉडवर वेगवेगळ्या गोष्टी अपलोड करतात आणि प्रत्येकाकडे अँटीव्हायरस नसतो. ओतण्याच्या वेळी तपासणी करणे खूप वेळ घेते आणि व्यवसायात हस्तक्षेप करते.

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

निष्कर्ष

परिणामी, आम्हाला खात्री आहे की आम्ही बॅकअप घेतो, आमचे बॅकअप वैध आहेत, त्यांच्यासह उद्भवलेल्या समस्यांना थोडा वेळ लागतो आणि कर्तव्य प्रशासकाच्या स्तरावर निराकरण केले जाते. tar.gz किंवा Bacula च्या तुलनेत बॅकअप खरोखरच कमी जागा घेतात.

स्त्रोत: www.habr.com