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

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

मुझे कहना होगा, इन लिपियों ने पूरी तरह से काम किया। लेकिन आगे हम बढ़े, विभिन्न सॉफ्टवेयर और बाहरी रिपॉजिटरी के साथ अधिक विविध परियोजनाएं जो हमारी स्क्रिप्ट का समर्थन नहीं करती थीं, दिखाई नहीं दीं। उदाहरण के लिए, हमारे पास Redis और बाद में आने वाले हॉट MySQL और PostgreSQL बैकअप के लिए समर्थन नहीं था। बैकअप प्रक्रिया की निगरानी नहीं की गई थी, केवल ईमेल अलर्ट थे।

एक अन्य समस्या थी समर्थन प्रक्रिया। इन वर्षों में, हमारी एक बार कॉम्पैक्ट स्क्रिप्ट बढ़ी है और एक विशाल अजीब राक्षस में बदल गई है। और जब हम एक साथ आए और एक नया संस्करण जारी किया, तो यह ग्राहकों के उस हिस्से के लिए अद्यतन को रोल करने के प्रयास के लायक था, जिन्होंने पिछले संस्करण का उपयोग किसी तरह के अनुकूलन के साथ किया था।

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

सबसे अधिक उपयोग किए जाने वाले सॉफ़्टवेयर के डेटा का बैकअप लें:
- फ़ाइलें (असतत और वृद्धिशील प्रतिलिपि)
- MySQL (ठंडा / गर्म बैकअप)
- PostgreSQL (ठंडा / गर्म बैकअप)
- MongoDB
- Redis
लोकप्रिय रिपॉजिटरी में स्टोर बैकअप:
- स्थानीय
- एफ़टीपी
- SSH
- एसएमबी
- एनएफएस
- WebDAV
- S3
बैकअप प्रक्रिया के दौरान किसी भी समस्या के मामले में अलर्ट प्राप्त करें
एकल कॉन्फ़िगरेशन फ़ाइल है जो आपको केंद्रीय रूप से बैकअप प्रबंधित करने की अनुमति देती है
बाहरी मॉड्यूल को जोड़कर नए सॉफ़्टवेयर के लिए समर्थन जोड़ें
डंप इकट्ठा करने के लिए अतिरिक्त विकल्प निर्दिष्ट करें
नियमित माध्यम से बैकअप को बहाल करने की क्षमता है
आसान प्रारंभिक विन्यास

हम उपलब्ध समाधानों का विश्लेषण करते हैं

हमने पहले से मौजूद खुले स्रोत समाधानों को देखा:

बकुला और इसके कांटे, उदाहरण के लिए, बेरोस
अमांडा
बोर्ग
Duplicaty
कपट
Rsnapshot
Rdiff-बैकअप

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

अंत में, हम दो महत्वपूर्ण निष्कर्षों पर आए:

मौजूदा समाधानों में से कोई भी पूरी तरह से हमारे अनुकूल नहीं है;
ऐसा लगता है कि हम खुद को अपना निर्णय लिखना शुरू करने के लिए पर्याप्त अनुभव और पागलपन था।

तो हमने किया।

Nxs- बैकअप का जन्म

पायथन को कार्यान्वयन के लिए भाषा के रूप में चुना गया था - यह लिखना आसान है और बनाए रखना, लचीला और सुविधाजनक है। यमल प्रारूप में कॉन्फ़िगरेशन फ़ाइलों का वर्णन करने का निर्णय लिया गया।

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

फ़ाइलों, डेटाबेस और दूरस्थ भंडारण के लिए समर्थन

वर्तमान में, फ़ाइलों, डेटाबेस और दूरस्थ रिपॉजिटरी के बैकअप के निम्न प्रकार समर्थित हैं:

डीबी:

MySQL (गर्म / ठंडा बैकअप)
PostgreSQL (गर्म / ठंडा बैकअप)
Redis
MongoDB

फाइलें:

नकल उतारना
इंक्रीमेंटल नकल

दूरस्थ रिपोजिटरी:

स्थानीय
S3
एसएमबी
एनएफएस
एफ़टीपी
SSH
WebDAV

असतत बैकअप

विभिन्न कार्यों के लिए, या तो असतत या वृद्धिशील बैकअप उपयुक्त हैं, इसलिए, उन्होंने दोनों प्रकारों को लागू किया। आप व्यक्तिगत फ़ाइल और निर्देशिका स्तर पर किस विधि का उपयोग कर सकते हैं, यह निर्दिष्ट कर सकते हैं।

असतत प्रतियों (दोनों फ़ाइलों और डेटाबेस) के लिए, आप दिनों / सप्ताह / महीनों के प्रारूप में पूर्वव्यापी सेट कर सकते हैं।

वृद्धिशील बैकअप

फाइलों की वृद्धिशील प्रतियां निम्नानुसार बनाई गई हैं:

वर्ष की शुरुआत में, एक पूर्ण बैकअप के लिए जा रहा है। अगले, प्रत्येक महीने की शुरुआत में - वार्षिक एक सापेक्ष मासिक प्रति। मासिक धर्म के भीतर - मासिक के सापेक्ष वृद्धिशील विकृति। दस दिन की अवधि के सापेक्ष प्रत्येक दस-दिन के वृद्धिशील दिन के भीतर।

यह ध्यान दिया जाना चाहिए कि निर्देशिकाओं के साथ काम करते समय कुछ समस्याएं हैं जिनमें बड़ी संख्या में उपनिर्देशिकाएं (दसियों हजारों) शामिल हैं। ऐसे मामलों में, प्रतियों का संग्रह काफी धीमा हो जाता है और एक दिन से अधिक समय ले सकता है। हम इस कमी को सक्रिय रूप से संबोधित कर रहे हैं।

हम वृद्धिशील बैकअप से उबरते हैं

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

एक साल के बैकअप का विस्तार करें, भले ही हमारे मामले में यह 1 जनवरी, 2018 से शुरू हो (व्यवहार में, यह किसी भी तारीख को हो सकता है, यह इस बात पर निर्भर करता है कि कब वृद्धिशील बैकअप लागू करने का निर्णय लिया गया था)
उस पर जुलाई के लिए एक मासिक बैकअप रोल करें
21 जुलाई के बैकअप को रोल अप करें
24 जुलाई के लिए दैनिक बैकअप रोल करें

उसी समय, 2-4 अंकों को पूरा करने के लिए, ट कमांड को -G स्विच जोड़ें, जिससे यह संकेत मिलता है कि यह एक वृद्धिशील बैकअप है। बेशक, यह सबसे तेज प्रक्रिया नहीं है, लेकिन जब आप समझते हैं कि बैकअप से उबरने के लिए ऐसा अक्सर जरूरी नहीं है और लागत-प्रभावशीलता महत्वपूर्ण है, तो ऐसी योजना काफी प्रभावी हो जाती है।

अपवाद

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

कॉन्फ़िगरेशन फ़ाइल उदाहरण

- target: - /var/www/*/data/ excludes: - exclude1/exclude_file - exclude2 - /var/www/exclude_3

बैकअप रोटेशन

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

नए कार्यान्वयन में, हमने इस दृष्टिकोण को बदलने का फैसला किया: पहले पुराने को हटा दें और उसके बाद ही एक नई प्रतिलिपि एकत्र करें। और किसी भी समस्या के बारे में पता लगाने के लिए बैकअप इकट्ठा करने की प्रक्रिया की निगरानी की जानी चाहिए।

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

लॉगिंग

किसी भी प्रक्रिया में, और विशेष रूप से बैकअप में, यह महत्वपूर्ण है कि कुछ गलत होने पर पता लगाने में सक्षम हो। सिस्टम अपने काम का एक लॉग रखता है और प्रत्येक चरण के परिणाम को कैप्चर करता है: फंड का प्रारंभ / रोकना, किसी विशिष्ट कार्य की शुरुआत / समाप्ति, एक अस्थायी निर्देशिका में प्रतिलिपि एकत्र करने का परिणाम, एक अस्थायी निर्देशिका से कॉपी को स्थानांतरित करने / एक स्थायी स्थान पर कॉपी करने का परिणाम, बैकअप रोटेशन का परिणाम आदि। ..

घटनाओं को 2 स्तरों में विभाजित किया गया है:

जानकारी : सूचना का स्तर - उड़ान सामान्य है, अगला चरण सफलतापूर्वक पूरा हो गया, लॉग में एक संबंधित सूचना प्रविष्टि की जाती है
त्रुटि : त्रुटि स्तर - कुछ गलत हो गया, अगला चरण विफल हो गया, लॉग में एक संबंधित त्रुटि रिकॉर्ड बनाया गया है

ईमेल सूचनाएं

बैकअप संग्रह के अंत में, सिस्टम ईमेल सूचनाएं भेज सकता है।

2 प्राप्तकर्ता सूची समर्थित हैं:

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

कॉन्फ़िगरेशन फ़ाइल संरचना

कॉन्फ़िगरेशन फ़ाइलों की संरचना इस प्रकार है:

संरचना उदाहरण

 /etc/nxs-backup ├── conf.d │ ├── desc_files_local.conf │ ├── external_clickhouse_local.conf │ ├── inc_files_smb.conf │ ├── mongodb_nfs.conf │ ├── mysql_s3.conf │ ├── mysql_xtradb_scp.conf │ ├── postgresql_ftp.conf │ ├── postgresql_hot_webdav.conf │ └── redis_local_ftp.conf └── nxs-backup.conf

यहाँ /etc/nxs-backup/nxs-backup.conf मुख्य विन्यास फ़ाइल है जिसमें वैश्विक सेटिंग्स को दर्शाया गया है:

कॉन्फ़िगरेशन फ़ाइल

 main: server_name: SERVER_NAME admin_mail: project-tech@nixys.ru client_mail: - '' mail_from: backup@domain.ru level_message: error block_io_read: '' block_io_write: '' blkio_weight: '' general_path_to_all_tmp_dir: /var/nxs-backup cpu_shares: '' log_file_name: /var/log/nxs-backup/nxs-backup.log jobs: !include [conf.d/*.conf]

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

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

 nxs-backup generate --storage local scp --type mysql --path /etc/nxs-backup/conf.d/mysql_local_scp.conf

आउटपुट फ़ाइल /etc/nxs-backup/conf.d/mysql_local_scp.conf उत्पन्न करता है:

फ़ाइल सामग्री

  - job: PROJECT-mysql type: mysql tmp_dir: /var/nxs-backup/databases/mysql/dump_tmp sources: - connect: db_host: '' db_port: '' socket: '' db_user: '' db_password: '' auth_file: '' target: - all excludes: - information_schema - performance_schema - mysql - sys gzip: no is_slave: no extra_keys: '--opt --add-drop-database --routines --comments --create-options --quote-names --order-by-primary --hex-blob' storages: - storage: local enable: yes backup_dir: /var/nxs-backup/databases/mysql/dump store: days: '' weeks: '' month: '' - storage: scp enable: yes backup_dir: /var/nxs-backup/databases/mysql/dump user: '' host: '' port: '' password: '' path_to_key: '' store: days: '' weeks: '' month: ''

जिसमें यह केवल कुछ आवश्यक मूल्यों को स्थान देने के लिए रहता है।

एक उदाहरण लेते हैं। मान लीजिए कि / var / www निर्देशिका में हमारे सर्वर पर 1C-Bitrix ऑनलाइन स्टोर की दो साइटें हैं (bitrix-1.ru, bitrix-2.ru), जिनमें से प्रत्येक अलग-अलग MySQL इंस्टेंसेस में अपने स्वयं के डेटाबेस के साथ काम करता है (पोर्ट 3306 के लिए) bitrix_1_db और bitrix_2_db के लिए 3307 पोर्ट)।

एक विशिष्ट बिट्रिक्स परियोजना की फ़ाइल संरचना लगभग इस प्रकार है:

 ├── ... ├── bitrix │ ├── .. │ ├── admin │ ├── backup │ ├── cache │ ├── .. │ ├── managed_cache │ ├── .. │ ├── stack_cache │ └── .. ├── upload └── ...

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

इस तरह के एक सेटअप के लिए परिणामी विन्यास फाइल इस तरह दिखाई देगी:

bitrix-desc-files.conf (असतत बैकअप के लिए नौकरी विवरण के साथ कॉन्फ़िगरेशन फ़ाइल)

  - job: Bitrix-desc-files type: desc_files tmp_dir: /var/nxs-backup/files/desc/dump_tmp sources: - target: - /var/www/*/ excludes: - bitrix/backup - bitrix/cache - bitrix/managed_cache - bitrix/stack_cache - upload gzip: yes storages: - storage: local enable: yes backup_dir: /var/nxs-backup/files/desc/dump store: days: 6 weeks: 4 month: 6 - storage: ftp enable: yes backup_dir: /nxs-backup/databases/mysql/dump host: ftp_host user: ftp_usr password: ftp_usr_pass store: days: 6 weeks: 4 month: 6

bitrix-inc-files.conf (वृद्धिशील बैकअप के लिए नौकरी विवरण के साथ कॉन्फ़िगरेशन फ़ाइल)

  - job: Bitrix-inc-files type: inc_files sources: - target: - /var/www/*/upload/ gzip: yes storages: - storage: ftp enable: yes backup_dir: /nxs-backup/files/inc host: ftp_host user: ftp_usr password: ftp_usr_pass - storage: local enable: yes backup_dir: /var/nxs-backup/files/inc

bitrix-mysql.conf (MySQL बैकअप के लिए नौकरी विवरण के साथ कॉन्फ़िगरेशन फ़ाइल)

  - job: Bitrix-mysql type: mysql tmp_dir: /var/nxs-backup/databases/mysql/dump_tmp sources: - connect: db_host: localhost db_port: 3306 db_user: bitrux_usr_1 db_password: password_1 target: - bitrix_1_db excludes: - information_schema - performance_schema - mysql - sys gzip: no is_slave: no extra_keys: '--opt --add-drop-database --routines --comments --create-options --quote-names --order-by-primary --hex-blob' - connect: db_host: localhost db_port: 3307 db_user: bitrix_usr_2 db_password: password_2 target: - bitrix_2_db excludes: - information_schema - performance_schema - mysql - sys gzip: yes is_slave: no extra_keys: '--opt --add-drop-database --routines --comments --create-options --quote-names --order-by-primary --hex-blob' storages: - storage: smb enable: yes backup_dir: /nxs-backup/databases/mysql/dump host: smb_host port: smb_port share: smb_share_name user: smb_usr password: smb_usr_pass store: days: 6 weeks: 4 month: 6

बैकअप एकत्रित करना शुरू करने के विकल्प

पिछले उदाहरण में, हमने एक ही बार में सभी तत्वों के बैकअप एकत्र करने के लिए नौकरी विन्यास फाइल तैयार की: फाइलें (असतत और वृद्धिशील), दो डेटाबेस और उन्हें स्थानीय और बाहरी (ftp, smb) स्टोरेज पर संग्रहीत करना।

यह पूरी बात चलाने के लिए बनी हुई है। लॉन्च कमांड द्वारा किया जाता है:

 nxs-backup start $JOB_NAME -c $PATH_TO_MAIN_CONFIG

कई आरक्षित नौकरी के नाम हैं:

फाइलें - प्रकार desc_files के साथ सभी नौकरियों के मनमाने ढंग से निष्पादन, inc_files (संक्षेप में, केवल फाइलें समर्थित हैं)
डेटाबेस - सभी प्रकार के mysql , mysql_xtradb , postgresql , postgresql_hot , mongodb , redis (जो केवल डेटाबेस का बैकअप है) के साथ सभी नौकरियों को बेतरतीब ढंग से निष्पादित कर रहा है
बाहरी - बेतरतीब ढंग से बाहरी प्रकार के साथ सभी नौकरियों को निष्पादित करना (केवल अतिरिक्त कस्टम स्क्रिप्ट चलाना, नीचे इस पर और अधिक)
सभी - एक के बाद एक काम फाइलों , डेटाबेस , बाहरी (डिफ़ॉल्ट मान) के साथ कमांड चलाने की नकल

चूंकि हमें आउटपुट पर एक ही समय (या न्यूनतम अंतर के साथ) दोनों फ़ाइलों और डेटाबेस के डेटा बैकअप प्राप्त करने की आवश्यकता होती है, इसलिए सभी नौकरी के साथ nxs-backup चलाने की सिफारिश की जाती है, जो वर्णित नौकरी के निरंतर निष्पादन को सुनिश्चित करेगा (Bitrix-desc-) फ़ाइलें, Bitrix-inc_files, Bitrix-mysql)।

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

बाहरी मॉड्यूल

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

कॉन्फ़िगरेशन फ़ाइल उदाहरण

  - job: TEST-external type: external dump_cmd: '' storages: ….

विशेष रूप से डंप_cmd कुंजी पर ध्यान दिया जाना चाहिए, जहां मान बाहरी स्क्रिप्ट चलाने के लिए पूर्ण कमांड है। इसके अलावा, इस आदेश के पूरा होने पर, यह अपेक्षित है कि:

सॉफ़्टवेयर डेटा का एक तैयार किया गया संग्रह एकत्र किया जाएगा
डेटा को फॉर्म के json प्रारूप में भेजा जाएगा:
```
 { "full_path": "ABS_PATH_TO_ARCHIVE", "basename": "BASENAME_ARCHIVE", "extension": "EXTERNSION_OF_ARCHIVE", "gzip": true/false } 
```
- इस मामले में, कुंजी बैकअप नाम, विस्तार , gzip विशेष रूप से अंतिम बैकअप नाम के गठन के लिए आवश्यक हैं ।
स्क्रिप्ट के सफल समापन के मामले में, रिटर्न कोड 0 होना चाहिए और किसी भी समस्या के मामले में कोई अन्य होना चाहिए।

उदाहरण के लिए, मान लें कि हमारे पास स्नैपशॉट etcd /etc/nxs-backup-ext/etcd.py बनाने के लिए एक स्क्रिप्ट है:

स्क्रिप्ट कोड

 #! /usr/bin/env python3 # -*- coding: utf-8 -*- import json import os import subprocess import sys import tarfile def archive(snapshot_path): abs_tmp_path = '%s.tar' %(snapshot_path) with tarfile.open(abs_tmp_path, 'w:') as tar: tar.add(snapshot_path) os.unlink(snapshot_path) return abs_tmp_path def exec_cmd(cmdline): data_dict = {} current_process = subprocess.Popen([cmdline], stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True, executable='/bin/bash') data = current_process.communicate() data_dict['stdout'] = data[0][0:-1].decode('utf-8') data_dict['stderr'] = data[1][0:-1].decode('utf-8') data_dict['code'] = current_process.returncode return data_dict def main(): snapshot_path = "/var/backups/snapshot.db" dump_cmd = "ETCDCTL_API=3 etcdctl --cacert=/etc/ssl/etcd/ssl/ca.pem --cert=/etc/ssl/etcd/ssl/member-node1.pem"+\ " --key=/etc/ssl/etcd/ssl/member-node1-key.pem --endpoints 'https://127.0.0.1:2379' snapshot save %s" %snapshot_path command = exec_cmd(dump_cmd) result_code = command['code'] if result_code: sys.stderr.write(command['stderr']) else: try: new_path = archive(snapshot_path) except tarfile.TarError as e: sys.exit(1) else: result_dict = { "full_path": new_path, "basename": "etcd", "extension": "tar", "gzip": False } print(json.dumps(result_dict)) sys.exit(result_code) if __name__ == '__main__': main()

इस लिपि को चलाने के लिए विन्यास इस प्रकार है:

कॉन्फ़िगरेशन फ़ाइल

  - job: etcd-external type: external dump_cmd: '/etc/nxs-backup-ext/etcd.py' storages: - storage: local enable: yes backup_dir: /var/nxs-backup/external/dump store: days: 6 weeks: 4 month: 6

इस मामले में, नौकरी वगैरह चलाने के दौरान कार्यक्रम:

मापदंडों के बिना स्क्रिप्ट /etc/nxs-backup-ext/etcd.py चलाएँ
स्क्रिप्ट पूरी होने के बाद, यह पूरा कोड और stdout में आवश्यक डेटा की उपलब्धता की जांच करेगा
यदि सभी चेक सफल होते हैं, तो उसी तंत्र का उपयोग पहले से निर्मित मॉड्यूल के साथ किया जाता है, जहां full_path कुंजी मान tmp_path के रूप में उपयोग किया जाता है। यदि नहीं, तो यह इस कार्य को लॉग में संबंधित चिह्न के साथ पूरा करेगा।

समर्थन और अद्यतन

नई बैकअप प्रणाली को विकसित करने और समर्थन करने की प्रक्रिया सीआई / सीडी के सभी कैनन के साथ लागू की गई है। कोई और अधिक अद्यतन और स्क्रिप्ट युद्ध सर्वर पर संपादित नहीं करता है। सभी परिवर्तन Gitlab में हमारे केंद्रीय गिट भंडार से होकर गुजरते हैं, जहां deb / rpm संकुल के नए संस्करणों की असेंबली पाइपलाइन में पंजीकृत है, जो तब हमारे deb / rpm रिपॉजिटरी में अपलोड की जाती हैं। और उसके बाद, पैकेज मैनेजर के माध्यम से, उन्हें अंतिम क्लाइंट सर्वर तक पहुंचाया जाता है।

Nxs-backup कैसे डाउनलोड करें?

हमने nxs- बैकअप ओपन-सोर्स प्रोजेक्ट बनाया। कोई भी अपनी परियोजनाओं में बैकअप प्रक्रिया को व्यवस्थित करने के लिए इसे डाउनलोड और उपयोग कर सकता है, साथ ही अपनी आवश्यकताओं को संशोधित कर सकता है, बाहरी मॉड्यूल लिख सकता है।

Nxs- बैकअप के लिए सोर्स कोड इस लिंक पर Github रिपॉजिटरी से डाउनलोड किया जा सकता है। स्थापना और कॉन्फ़िगरेशन निर्देश भी है।

हमने एक डॉकर छवि भी तैयार की और इसे डॉकरहब पर पोस्ट किया।

यदि आपके पास सेटअप या उपयोग प्रक्रिया के दौरान कोई प्रश्न हैं, तो हमें लिखें। हम निर्देशों को समझने और अंतिम रूप देने में मदद करेंगे।

निष्कर्ष

निकट भविष्य में, हम निम्नलिखित कार्यक्षमता को लागू करेंगे:

निगरानी एकीकरण
बैकअप एन्क्रिप्शन
बैकअप सेटिंग्स के प्रबंधन के लिए वेब-आधारित इंटरफ़ेस
Nxs-backup का उपयोग करके बैकअप तैनात करना
और भी बहुत कुछ

बड़ी संख्या में विषम वेब परियोजनाओं का समर्थन करना