बोर्ग के साथ बैकअप का सिद्धांत और अभ्यास

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

पृष्ठभूमि: बकुला और बरेस के साथ अनुभव

2017 में, हम बकुला और बेरोज़ से थक गए थे, जिसका उपयोग हम अपनी गतिविधि की शुरुआत से ही करते थे (यानी, उस समय उत्पादन में लगभग 9 साल)। क्यों? ऑपरेशन के दौरान, हमने बहुत असंतोष जमा किया है:

• एसडी (स्टोरेज डेमॉन) जमा देता है। यदि आपने समानांतरवाद को कॉन्फ़िगर किया है, तो एसडी रखरखाव अधिक जटिल हो जाता है, और इसकी ठंड आगे के बैकअप और पुनर्प्राप्ति की संभावना को रोक देगी।
• क्लाइंट और डायरेक्टर दोनों के लिए कॉन्फिग्रेशन जेनरेट करना आवश्यक है। यहां तक ​​कि अगर हम इसे (हमारे मामले में, शेफ, अन्सिबल, और हमारे अपने विकास को अलग-अलग समय पर उपयोग किया गया था) को स्वचालित करते हैं, तो हमें यह निगरानी करने की आवश्यकता है कि निदेशक, उसके पुन: लोड करने के बाद , वास्तव में कॉन्फ़िगरेशन को उठाए। यह केवल पुनः लोड कमांड के आउटपुट में और बाद के संदेशों के कॉल में ट्रैक किया जाता है (त्रुटि पाठ को स्वयं प्राप्त करने के लिए)।
• बैकअप शेड्यूल करें। बकुला के डेवलपर्स ने अपने तरीके से जाने का फैसला किया और अपना स्वयं का शेड्यूल प्रारूप लिखा, जिसे आप केवल पार्स नहीं कर सकते या दूसरे में परिवर्तित नहीं कर सकते। हमारे पुराने प्रतिष्ठानों में मानक बैकअप शेड्यूल के उदाहरण इस प्रकार हैं:
  • बुधवार को दैनिक पूर्ण बैकअप और अन्य दिनों में वृद्धि:
    Run = Level=Full Pool="Foobar-low7" wed at 18:00
Run = Level=Incremental Pool="Foobar-low7" at 18:00
  • महीने में 2 बार वॉल-फाइल्स का पूरा बैकअप और हर घंटे वेतन वृद्धि:
    Run = Level=Full FullPool=CustomerWALPool 1st fri at 01:45
Run = Level=Full FullPool=CustomerWALPool 3rd fri at 01:45
Run = Level=Incremental FullPool=CustomerWALPool IncrementalPool=CustomerWALPool on hourly
  • सभी अवसरों (सप्ताह के हर 2 घंटे पर अलग-अलग दिनों) के लिए जनरेट किया गया schedule हमें 1665 के बारे में मिला ... क्योंकि बकुला / बरोस समय-समय पर पागल हो गए थे।
• Bacula-fd (और bareos-fd) में बहुत अधिक डेटा वाली निर्देशिकाएं हैं (40 टीबी कहते हैं, जिनमें से 35 टीबी में बड़ी फाइलें [100+ एमबी] हैं, और शेष 5 टीबी में छोटी फाइलें हैं [1 KB से 100 एमबी] ]) एक धीमी मेमोरी रिसाव शुरू होता है, जो उत्पादन पर एक बहुत अप्रिय स्थिति है।
  
  
• बड़ी संख्या में फ़ाइलों के साथ बैकअप पर, बकुला और बेरोस उपयोग किए गए डीबीएमएस के प्रदर्शन पर बहुत निर्भर हैं। इसमें क्या ड्राइव है? कितनी कुशलता से आप जानते हैं कि उसे इन विशिष्ट आवश्यकताओं के अनुरूप कैसे बनाया जाए? और डेटाबेस में, वैसे, एक (!) गैर-विभाजन तालिका सभी बैकअप में सभी फ़ाइलों की सूची के साथ बनाई गई है और दूसरी - सभी बैकअप में सभी पथों की सूची के साथ। यदि आप अपने बैकअप सर्वर के लिए आधार + 40 जीबी एसएसडी के लिए कम से कम 8 जीबी रैम आवंटित करने के लिए तैयार नहीं हैं - तुरंत ब्रेक के लिए तैयार हो जाएं।
• डेटाबेस निर्भरता एक और बिंदु के योग्य है। प्रत्येक फ़ाइल के लिए Bacula / Bareos निर्देशक से पूछता है कि क्या ऐसी कोई फ़ाइल पहले से थी। निर्देशक, ज़ाहिर है, डेटाबेस में क्रॉल करता है, उन बहुत विशाल तालिकाओं में ... यह पता चलता है कि बैकअप को केवल इस तथ्य से अवरुद्ध किया जा सकता है कि एक ही समय में कई भारी बैकअप शुरू हुए - भले ही वह अंतर कई मेगाबाइट हो।

यह कहना अनुचित होगा कि कोई भी समस्या बिल्कुल हल नहीं हुई थी, लेकिन हम उस बिंदु पर पहुंच गए, जहां हम वास्तव में विभिन्न कार्यक्षेत्रों से थक गए थे और "यहां और अब" एक विश्वसनीय समाधान चाहते थे।

बकुला / बेरोज़ एक समान संख्या (10-30) की समान नौकरियों के साथ महान काम करते हैं। क्या हफ्ते में एक बार थोड़ी सी बात टूट जाती है? यह ठीक है: उन्होंने कार्य अधिकारी (या अन्य इंजीनियर) को दिया - उन्होंने इसकी मरम्मत की। हालांकि, हमारे पास ऐसी परियोजनाएं हैं जहां नौकरियों की संख्या सैकड़ों में है, और उनमें फाइलों की संख्या सैकड़ों हजारों है। परिणामस्वरूप, बैकअप को ठीक करने के लिए सप्ताह में 5 मिनट (इससे पहले कई घंटों की सेटिंग्स की गणना नहीं करना) गुणा करना शुरू कर दिया। यह सब इस तथ्य के कारण था कि दिन में 2 घंटे सभी परियोजनाओं में बैकअप को ठीक करने के लिए आवश्यक था, क्योंकि शाब्दिक रूप से हर जगह कुछ ट्रिफ़्लिंग या गंभीरता से टूट रहा था।

तब कोई सोच सकता है कि इसके लिए समर्पित एक इंजीनियर को बैकअप करना चाहिए। निश्चित रूप से, वह जितना संभव हो उतना दाढ़ी और गंभीर होगा, और अपने लुक से, बैकअप की तुरंत मरम्मत की जाती है, जबकि वह शांति से कॉफी पीता है। और यह विचार किसी भी तरह से सच हो सकता है ... लेकिन वहाँ हमेशा एक है। हर कोई घड़ी के आसपास बैकअप की मरम्मत और निगरानी करने का जोखिम नहीं उठा सकता है, और इससे भी अधिक - इन उद्देश्यों के लिए आवंटित एक इंजीनियर। हम सिर्फ यह सुनिश्चित कर रहे हैं कि कुछ अधिक उत्पादक और उपयोगी चीजों पर इन 2 घंटे एक दिन बिताना बेहतर है। इसलिए, हम वैकल्पिक समाधानों की तलाश में आगे बढ़े जो "बस काम करते हैं।"

एक नए तरीके के रूप में बोर्ग

अन्य ओपन सोर्स विकल्पों की खोज समय के साथ फैल गई थी, इसलिए कुल लागतों का अनुमान लगाना मुश्किल है, लेकिन एक बिंदु पर (पिछले साल), हमारा ध्यान "अवसर के नायक " पर गया - बोर्गबैक (या बस बोर्ग)। भाग में, यह हमारे इंजीनियरों में से एक (काम के पिछले स्थान पर) द्वारा इसके उपयोग के वास्तविक अनुभव की सुविधा थी।

बोर्ग को पायथन (संस्करण> = 3.4.0 की आवश्यकता है) में लिखा गया है, और प्रदर्शन-मांग कोड (संपीड़न, एन्क्रिप्शन, आदि) C / Cython में लागू किया गया है। एक नि: शुल्क बीएसडी लाइसेंस (3-खंड) के तहत वितरित किया गया। यह लिनक्स सहित कई प्लेटफार्मों का समर्थन करता है, * बीएसडी, मैकओएस, साथ ही साथ प्रयोगात्मक स्तर पर सिग्विन और विंडोज 10 के लिनक्स सबसिस्टम। बोर्गबैक को स्थापित करने के लिए, लोकप्रिय लिनक्स वितरण और अन्य ओएस के लिए पैकेज उपलब्ध हैं, साथ ही साथ स्रोत कोड, जिसे पाइप के माध्यम से भी स्थापित किया जा सकता है। - इस बारे में अधिक विस्तृत जानकारी परियोजना प्रलेखन में पाई जा सकती है।

बोर्ग ने हमें इतना रिश्वत क्यों दी? यहाँ इसके मुख्य लाभ हैं:

• Deduplication : वास्तविक और बहुत प्रभावी (उदाहरण नीचे)। एक एकल Borg रिपॉजिटरी (यानी, Borg- विशिष्ट प्रारूप में एक विशेष निर्देशिका) के भीतर की फाइलें n मेगाबाइट के ब्लॉक में विभाजित हैं, और दोहराए जाने वाले Borg ब्लॉक काट दिए गए हैं। Deduplication संपीड़न से पहले ठीक होता है।
• संपीड़न : कटौती के बाद, डेटा भी संपीड़ित होता है। विभिन्न संपीड़न एल्गोरिदम उपलब्ध हैं: lz4, lzma, zlib, zstd। किसी भी बैकअप की मानक विशेषता, लेकिन यह कम उपयोगी नहीं है।
• एसएसएच पर काम : एसएसएच के माध्यम से एक दूरस्थ सर्वर के लिए बोर्ग बैकअप। सर्वर की ओर, आपको बस बोर्ग स्थापित करने की आवश्यकता है और यह बात है! यहां से, सुरक्षा और एन्क्रिप्शन जैसे फायदे तुरंत अनुसरण करते हैं। आप केवल कुंजियों द्वारा पहुंच को कॉन्फ़िगर कर सकते हैं और, इसके अलावा, सर्वर में प्रवेश करते समय बोर्ग के केवल एक आदेश को निष्पादित कर सकते हैं। उदाहरण के लिए, इस तरह:
  
  

   $ cat .ssh/authorized_keys command="/usr/bin/borg serve" ssh-rsa AAAAB3NzaC1yc… 

• यह पीपीए (हम मुख्य रूप से उबंटू का उपयोग करते हैं) और एक स्थिर बाइनरी में दोनों दिया जाता है। एक स्थिर बाइनरी के रूप में बोर्ग लगभग हर जगह इसे चलाने के लिए संभव बनाता है जहां कम से कम एक आधुनिक ग्लिबक है। (लेकिन हर जगह नहीं - उदाहरण के लिए, CentOS 5. पर शुरू करना संभव नहीं था)
• पुराने बैकअप की लचीली सफाई । आप अंतिम n बैकअप, और 2 बैकअप प्रति घंटे / दिन / सप्ताह का संग्रहण सेट कर सकते हैं। उत्तरार्द्ध मामले में, सप्ताह के अंत में अंतिम बैकअप छोड़ दिया जाएगा। पिछले 7 दिनों और 4 साप्ताहिक बैकअप के लिए 7 दैनिक बैकअप संग्रहीत करके शर्तों को जोड़ा जा सकता है।

बोर्ग के लिए संक्रमण धीरे-धीरे छोटी परियोजनाओं पर शुरू हुआ। सबसे पहले, ये सरल क्रोन स्क्रिप्ट थे जो हर दिन अपना काम करते थे। यह करीब छह महीने तक चला। इस समय के दौरान, हमें कई बार बैकअप लेने पड़े ... और यह पता चला कि बोर्ग को वास्तव में मरम्मत नहीं करनी थी! क्यों? क्योंकि साधारण सिद्धांत यहां काम करता है: "तंत्र जितना सरल होगा, उतनी ही कम जगह जहां यह टूट जाएगा।"

अभ्यास: बोर्ग के साथ बैकअप कैसे करें?

बैकअप बनाने के एक सरल उदाहरण पर विचार करें:

1. बैकअप सर्वर और मशीन का नवीनतम रिलीज बाइनरी डाउनलोड करें जिसे हम आधिकारिक रिपॉजिटरी से बैकअप देंगे:
   
   

    sudo wget https://github.com/borgbackup/borg/releases/download/1.1.6/borg-linux64 -O /usr/local/bin/borg sudo chmod +x /usr/local/bin/borg 

   
   नोट : यदि आप एक स्रोत और एक रिसीवर के रूप में परीक्षण के लिए एक स्थानीय मशीन का उपयोग करते हैं, तो पूरा अंतर केवल यूआरआई में होगा, जिसे हम पास करेंगे, लेकिन हमें याद है कि बैकअप को अलग से संग्रहीत करने की आवश्यकता है, और एक ही मशीन पर नहीं।
2. बैकअप सर्वर पर, borg उपयोगकर्ता बनाएँ:
   
   

    sudo useradd -m borg 

   
   सरल: समूहों के बिना और एक मानक शेल के साथ, लेकिन हमेशा एक घर निर्देशिका के साथ।
3. ग्राहक पर एक SSH कुंजी उत्पन्न होती है:
   
   

    ssh-keygen 

4. सर्वर पर, borg उपयोगकर्ता के लिए उत्पन्न कुंजी जोड़ें:
   
   

    mkdir ~borg/.ssh echo 'command="/usr/local/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf/XmSVWfF7PfjGlbKW00MJ63zal/E/mxm+vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU/JNU0jITLx+vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk/QmteOOclzx684t9d6BhMvFE9w9r+c76aVBIdbEyrkloiYd+vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44/Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam+9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y+IQM7fbDR' > ~borg/.ssh/authorized_keys chown -R borg:borg ~borg/.ssh स्थानीय / bin / बोर्ग की सेवा" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf / XmSVWfF7PfjGlbKW00MJ63zal / ई / MXM + vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU / JNU0jITLx + vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk / QmteOOclzx684t9d6BhMvFE9w9r + c76aVBIdbEyrkloiYd + vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44 / Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam + 9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y + IQM7fbDR'> ~ बोर्ग / .ssh mkdir ~borg/.ssh echo 'command="/usr/local/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf/XmSVWfF7PfjGlbKW00MJ63zal/E/mxm+vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU/JNU0jITLx+vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk/QmteOOclzx684t9d6BhMvFE9w9r+c76aVBIdbEyrkloiYd+vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44/Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam+9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y+IQM7fbDR' > ~borg/.ssh/authorized_keys chown -R borg:borg ~borg/.ssh 

5. हम क्लाइंट से सर्वर पर बोर्ग रेपो को इनिशियलाइज़ करते हैं:
   
   

    ssh borg@172.17.0.3 hostname #     borg init -e none borg@172.17.0.3:MyBorgRepo 

   
   -e स्विच का उपयोग रिपॉजिटरी के लिए एन्क्रिप्शन विधि का चयन करने के लिए किया जाता है (हाँ, आप अपने पासवर्ड के साथ प्रत्येक रिपॉजिट को एन्क्रिप्ट कर सकते हैं!)। इस मामले में, क्योंकि यह एक उदाहरण है, हम एन्क्रिप्शन का उपयोग नहीं करते हैं। MyBorgRepo उस निर्देशिका का नाम है जिसमें borg repo होगा (आपको इसे पहले से बनाने की आवश्यकता नहीं है - Borg खुद ही सब कुछ कर देगा)।
6. बोर्ग का उपयोग कर पहला बैकअप लॉन्च करें:
   
   

    borg create --stats --list borg@172.17.0.3:MyBorgRepo::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" /etc /root 

   
   कुंजियों के बारे में:
   
   • --stats और --list हमें बैकअप और उस पर मिलने वाली फ़ाइलों पर आँकड़े देते हैं;
   • borg@172.17.0.3:MyBorgRepo - यहां सब कुछ स्पष्ट है, यह हमारा सर्वर और निर्देशिका है। और जादू के लिए आगे क्या है?
   • ::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" संग्रह के अंदर संग्रह का नाम है। यह मनमाना है, लेकिन हम _-timestamp (पायथन प्रारूप में टाइमस्टैम्प) प्रारूप का पालन करते हैं।

आगे क्या है? बेशक, देखें कि हमारे बैकअप में क्या मिला! भंडार के अंदर अभिलेखों की सूची:

 borg@b3e51b9ed2c2:~$ borg list MyBorgRepo/ Warning: Attempting to access a previously unknown unencrypted repository! Do you want to continue? [yN] y MyFirstBackup-2018-08-04_16:55:53 Sat, 2018-08-04 16:55:54 [89f7b5bccfb1ed2d72c8b84b1baf477a8220955c72e7fcf0ecc6cd5a9943d78d] 

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

हम फाइलों की सूची देखते हैं:

 borg list MyBorgRepo::MyFirstBackup-2018-08-04_16:55:53 

हमें बैकअप से फ़ाइल मिलती है (आप पूरी निर्देशिका भी कर सकते हैं):

 borg@b3e51b9ed2c2:~$ borg extract MyBorgRepo::MyFirstBackup-2018-08-04_16:55:53 etc/hostname borg@b3e51b9ed2c2:~$ ll etc/hostname -rw-r--r-- 1 borg borg 13 Aug 4 16:27 etc/hostname 

बधाई हो, आपका पहला बोर्ग बैकअप तैयार है!

अभ्यास: इसे [GitLab के साथ] स्वचालित करें!

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

और यहाँ हम का सामना करना पड़ रहा है जो बरोज में है, लेकिन बोर्ग में नहीं! अर्थात्: WebUI या बैकअप को कॉन्फ़िगर करने के लिए किसी प्रकार का केंद्रीकृत स्थान। और हम वास्तव में आशा करते हैं कि यह एक अस्थायी घटना है, लेकिन अभी तक हमें कुछ हल करना था। तैयार किए गए औजारों को देखने और एक वीडियो कॉन्फ्रेंस में इकट्ठा होने के बाद, हम व्यापार में उतर गए। हमारी आंतरिक सेवाओं के साथ बोर्ग को एकीकृत करने के लिए यह एक महान विचार था, जैसा कि हमने बकुला से पहले किया था (बकुला ने खुद ही हमारे केंद्रीकृत एपीआई से नौकरियों की सूची छीन ली थी, जिसमें हमारे पास अपना इंटरफ़ेस अन्य परियोजना सेटिंग्स के साथ एकीकृत था)। हमने सोचा कि इसे कैसे किया जाए, इसे कैसे और कहां बनाया जाए, इसकी एक योजना की रूपरेखा तैयार की गई है ... लेकिन अब सामान्य बैकअप की आवश्यकता है, लेकिन ग्रैंड टाइम प्लान लेने के लिए कोई जगह नहीं है। क्या करें?

प्रश्न और आवश्यकताएं लगभग इस प्रकार थीं:

• केंद्रीकृत बैकअप प्रबंधन के रूप में क्या उपयोग करें?
• कोई लिनक्स प्रशासक क्या कर सकता है?
• एक प्रबंधक भी क्या कर सकता है जो ग्राहकों को एक बैकअप शेड्यूल दिखाता है वह समझने और कॉन्फ़िगर करने में सक्षम हो सकता है?
• हर दिन एक निर्धारित कार्य आपके सिस्टम पर क्या करता है?
• क्या कॉन्फ़िगर करना मुश्किल नहीं होगा और नहीं टूटेगा? "

जवाब स्पष्ट था: यह अच्छा पुराना क्रोन है, जो हर दिन वीरतापूर्वक अपना कर्तव्य निभाता है। सरल। यह जमता नहीं है। यहां तक ​​कि प्रबंधक जो यूनिक्स से "आप" है, उसे ठीक कर सकते हैं।

तो crontab, लेकिन आप यह सब कहाँ रखते हैं? क्या हर बार प्रोजेक्ट मशीन पर जाना है और अपने हाथों से फाइल को एडिट करना है? बिल्कुल नहीं। हम अपने शेड्यूल को Git रिपॉजिटरी में रख सकते हैं और GitLab Runner को कॉन्फ़िगर कर सकते हैं, जो कमिट द्वारा इसे होस्ट पर अपडेट करेगा।

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

आप एक परिचित स्वचालन उपकरण या आम तौर पर मैन्युअल रूप से (छोटी परियोजनाओं या घरेलू प्रतिष्ठानों पर) बैकअप के लिए कॉन्टैब का विस्तार कर सकते हैं।

तो, यहाँ है कि आप सरल स्वचालन के लिए क्या चाहिए:

1. गिटलैब और रिपॉजिटरी , जिसमें शुरुआत के लिए दो फाइलें होंगी:

• schedule - बैकअप अनुसूची
• borg_backup_files.sh - बैकअप फ़ाइलों के लिए एक सरल स्क्रिप्ट (ऊपर उदाहरण में)।

schedule उदाहरण:

 # WARNING! CRONTAB MANAGED FROM GITLAB CI RUNNER IN ${CI_PROJECT_URL} # CI_COMMIT_SHA: ${CI_COMMIT_SHA} # Branch/tag: ${CI_COMMIT_REF_NAME} # Timestamp: ${TIMESTAMP} PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # MyRemoteHost 0 0 * * * ${CI_PROJECT_DIR}/borg_backup_files.sh 'SYSTEM /etc,/opt' 

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

उदाहरण borg_backup_files.sh :

 #!/bin/bash BORG_SERVER="borg@10.100.1.1" NAMEOFBACKUP=${1} DIRS=${2} REPOSITORY="${BORG_SERVER}:$(hostname)-${NAMEOFBACKUP}" borg create --list -v --stats \ $REPOSITORY::"files-{now:%Y-%m-%d_%H:%M:%S}" \ $(echo $DIRS | tr ',' ' ') || \ echo "borg create failed" 

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

2. GitLab रनर , उस मशीन पर चल रहा है जिसे बैकअप की आवश्यकता है, और केवल इस रिपॉजिटरी के काम के लिए अवरुद्ध है।

3. सीआई स्क्रिप्ट ही , .gitlab-ci.yml द्वारा कार्यान्वित:

 stages: - deploy Deploy: stage: deploy script: - export TIMESTAMP=$(date '+%Y.%m.%d %H:%M:%S') - cat schedule | envsubst | crontab - tags: - borg-backup 

4. gitlab-runner उपयोगकर्ता के लिए SSH कुंजी gitlab-runner सर्वर तक पहुँच के साथ (उदाहरण के लिए, यह 10.100.1.1 है)। डिफ़ॉल्ट रूप से, यह gitlab-runner .ssh/id_rsa होम डायरेक्टरी ( gitlab-runner ) में होना चाहिए।

एक ही 10.100.1.1 पर borg उपयोगकर्ता केवल borg serve पहुंच के साथ:

 $ cat .ssh/authorized_keys command="/usr/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAA... 

अब, जब आप रनर रिपॉजिटरी के लिए प्रतिबद्ध होते हैं, तो यह कॉन्टैब की सामग्री को पॉप्युलेट करेगा। और जब क्रोन का प्रतिक्रिया समय आता है, तो /etc और /opt निर्देशिकाओं का एक बैकअप किया जाएगा, जो कि MyHostname-SYSTEM सर्वर के MyHostname-SYSTEM निर्देशिका में बैकअप सर्वर पर होगा।

निष्कर्ष के बजाय: आप और क्या कर सकते हैं?

इस पर बोर्ग का उपयोग, ज़ाहिर है, वहाँ समाप्त नहीं होता है। आगे के कार्यान्वयन के लिए यहां कुछ विचार दिए गए हैं, जिनमें से कुछ हम पहले ही घर पर लागू कर चुके हैं:

• विभिन्न बैकअप के लिए सार्वभौमिक स्क्रिप्ट जोड़ें , जो निष्पादन के अंत में borg_backup_files.sh चलाते हैं, जिसका उद्देश्य उनके काम के परिणाम के साथ निर्देशिका में है। उदाहरण के लिए, आप PostgreSQL (pg_basebackup), MySQL (innobackupex), GitLab (बिल्ट-इन रेक जॉब, एक आर्काइव बनाने) का बैकअप ले सकते हैं।
• बैकअप के लिए अनुसूची के साथ केंद्रीय मेजबान । प्रत्येक होस्ट GitLab धावक पर कॉन्फ़िगर करने के लिए नहीं? इसे बैकअप सर्वर पर अकेले रहने दें, और स्टार्टअप पर crontab बैकअप स्क्रिप्ट को मशीन में स्थानांतरित करता है और इसे वहां चलाता है। इसके लिए, निश्चित रूप से, आपको क्लाइंट मशीन और ssh-agent पर borg उपयोगकर्ता की आवश्यकता होगी, ताकि प्रत्येक मशीन पर बैकअप सर्वर की कुंजी को न रखें।
• की निगरानी करना। उसके बिना कहाँ! गलत तरीके से पूर्ण किए गए बैकअप के बारे में अलर्ट होना चाहिए।
• पुराने अभिलेखागार से क्लियरिंग बोर्ग भंडार। अच्छे समर्पण के बावजूद, पुराने बैकअप को अभी भी साफ करना होगा। ऐसा करने के लिए, आप बैकअप स्क्रिप्ट के अंत में borg prune को कॉल कर सकते हैं।
• अनुसूची के लिए वेब इंटरफ़ेस । यह काम में आएगा अगर हाथ से या वेब-इंटरफ़ेस में कॉन्टैब को संपादित करना आपके लिए ठोस / असुविधाजनक नहीं दिखता है।
• पाई चार्ट । सफलतापूर्वक पूरा किए गए बैकअप के प्रतिशत, उनके निष्पादन समय, "खाया" चैनल की चौड़ाई के दृश्य प्रतिनिधित्व के लिए कुछ रेखांकन। कोई आश्चर्य नहीं कि मैंने लिखा है कि पर्याप्त वेबयूआई नहीं है, जैसा कि बरोस में ...
• सरल क्रियाएं जो मैं एक बटन द्वारा प्राप्त करना चाहता हूं: मांग पर एक बैकअप लॉन्च करना, मशीन को पुनर्स्थापित करना, आदि।

और बहुत अंत में, मैं एक उत्पादन वातावरण में PostgreSQL वाल फाइलों के एक वास्तविक काम कर बैकअप पर समर्पण की प्रभावशीलता का एक उदाहरण जोड़ना चाहूंगा:

 borg@backup ~ $ borg info PROJECT-PG-WAL Repository ID: 177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 Location: /mnt/borg/PROJECT-PG-WAL Encrypted: No Cache: /mnt/borg/.cache/borg/177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 Security dir: /mnt/borg/.config/borg/security/177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 ------------------------------------------------------------------------------ Original size Compressed size Deduplicated size All archives: 6.68 TB 6.70 TB 19.74 GB Unique chunks Total chunks Chunk index: 11708 3230099 

ये 65 दिनों का बैकअप हैं, जो हर घंटे किया जाता है। बकुला / बेरोस का उपयोग करते समय, अर्थात्। कटौती के बिना, हमें 6.7 टीबी डेटा मिलेगा। ज़रा सोचिए: हम लगभग 7 टेराबाइट के डेटा को पोस्टग्रेक्यूक्यूएल के माध्यम से स्टोर करने का जोखिम उठा सकते हैं, जो वास्तव में कब्जे वाले स्थान का केवल 20 जीबी है।

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

• " उबंटू में अप्राप्य उन्नयन के सिद्धांत और अभ्यास ";
• " जूनियर, जिन्होंने काम के पहले दिन डेटाबेस को उत्पादन से हटा दिया था ";
• " कुबेरनेट्स के साथ बड़े डेटाबेस के बूटस्ट्रैप को तेज करना ।"