نظرية وممارسة النسخ الاحتياطية مع برج

لدهشتنا العظيمة ، لم يكن هناك مادة واحدة حول أداة Open Source الرائعة الرائعة للنسخ الاحتياطي للبيانات - Borg (لا ينبغي الخلط بينه وبين السلف Kubernetes المسمى!) . نظرًا لأننا نستخدمه في الإنتاج لأكثر من عام ، فسوف أشارك في هذه المقالة "الانطباعات" التي اكتسبناها عن برج.

الخلفية: تجربة مع Bacula و Bareos

في عام 2017 ، سئمنا من Bacula و Bareos ، التي استخدمناها منذ بداية نشاطنا (أي حوالي 9 سنوات في الإنتاج في ذلك الوقت). لماذا؟ أثناء العملية ، تراكمت لدينا الكثير من السخط:

• تجمد SD (التخزين الخفي). إذا قمت بتكوين التوازي ، فإن صيانة SD تصبح أكثر تعقيدًا ، وسوف يؤدي تجميدها إلى حظر المزيد من النسخ الاحتياطية في الموعد المحدد وإمكانية الاسترداد.
• من الضروري إنشاء تكوينات لكل من العميل والمدير. حتى إذا قمنا بأتمتة هذا (في حالتنا ، تم استخدام Chef ، Ansible ، وتطورنا الخاص في أوقات مختلفة) ، نحتاج إلى مراقبة أن المخرج ، بعد إعادة تحميله ، قام بالفعل باختيار التكوين. يتم تتبع هذا فقط في إخراج أمر إعادة التحميل وفي استدعاء الرسائل بعد (للحصول على نص الخطأ نفسه).
• جدولة النسخ الاحتياطية. قرر مطورو Bacula السير على طريقتهم وكتبوا تنسيق الجدول الزمني الخاص بهم ، والذي لا يمكنك فقط تحليله أو تحويله إلى آخر. فيما يلي أمثلة على جداول النسخ الاحتياطي القياسية في منشآتنا القديمة:
  • نسخ احتياطي يومي كامل في أيام الأربعاء وتزايد في أيام أخرى:
    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
  • schedule الذي تم إنشاؤه لجميع المناسبات (في أيام مختلفة من الأسبوع كل ساعتين) حصلنا على حوالي 1665 ... بسبب ما أصيب به باكولا / باروس بشكل دوري.
• يحتوي Bacula-fd (و bareos-fd) على أدلة تحتوي على الكثير من البيانات (على سبيل المثال 40 تيرابايت ، منها 35 تيرابايت تحتوي على ملفات كبيرة [100+ ميجا بايت] ، وتحتوي 5 تيرابايت المتبقية على ملفات صغيرة [1 كيلو بايت إلى 100 ميجا بايت ]) يبدأ تسرب ذاكرة بطيء ، وهو وضع غير سار للغاية على الإنتاج.
  
  
• في النسخ الاحتياطية التي تحتوي على عدد كبير من الملفات ، يعتمد Bacula و Bareos بشكل كبير على أداء نظام إدارة قواعد البيانات (DBMS) المستخدم. ما هي محركات الأقراص لديها؟ ما مدى مهارتك في معرفة كيفية ضبطها لهذه الاحتياجات المحددة؟ وفي قاعدة البيانات ، بالمناسبة ، يتم إنشاء جدول واحد (!) غير قابل للتقسيم بقائمة بجميع الملفات في جميع النسخ الاحتياطية والثاني - مع قائمة بجميع المسارات في جميع النسخ الاحتياطية. إذا لم تكن مستعدًا لتخصيص ما لا يقل عن 8 غيغابايت من ذاكرة الوصول العشوائي للقاعدة + 40 غيغابايت من SSD لخادم النسخ الاحتياطي - فاستعد على الفور للفرامل.
• التبعية لقاعدة البيانات تستحق نقطة أخرى. يسأل Bacula / Bareos لكل ملف المدير إذا كان هناك مثل هذا الملف بالفعل. المخرج ، بالطبع ، يزحف إلى قاعدة البيانات ، إلى تلك الجداول الضخمة للغاية ... اتضح أنه يمكن حظر النسخ الاحتياطي ببساطة من خلال حقيقة أن العديد من النسخ الاحتياطية الثقيلة بدأت في نفس الوقت - حتى لو كان الفرق هناك عدة ميغابايت هناك.

سيكون من الظلم أن نقول أنه لم يتم حل أي مشاكل على الإطلاق ، ولكننا وصلنا إلى النقطة التي سئمنا فيها بالفعل من الحلول المختلفة وأردنا حلاً موثوقًا به "هنا والآن".

يعمل Bacula / Bareos بشكل رائع مع عدد صغير (10-30) من الوظائف الموحدة. هل كسر شيء صغير مرة واحدة في الأسبوع؟ لا بأس: لقد أعطوا المهمة إلى الضابط المناوب (أو مهندس آخر) - قاموا بإصلاحها. ومع ذلك ، لدينا مشاريع يبلغ عدد الوظائف فيها المئات ، وعدد الملفات فيها مئات الآلاف. ونتيجة لذلك ، بدأت مضاعفة 5 دقائق في الأسبوع لإصلاح النسخة الاحتياطية (دون احتساب عدة ساعات من الإعدادات قبل ذلك). كل هذا أدى إلى حقيقة أنه كان من الضروري إصلاح ساعتين يوميًا في جميع المشاريع ، لأنه في كل مكان كان هناك شيء تافه أو ينكسر بشكل خطير.

ثم قد يعتقد شخص ما أن مهندسًا مخصصًا لهذا الغرض يجب أن يقوم بعمل نسخ احتياطية. بالتأكيد ، سيكون ملتحيًا وشديدًا قدر الإمكان ، ومن مظهره ، يتم إصلاح النسخ الاحتياطية على الفور ، بينما يشرب القهوة بهدوء. وقد تكون هذه الفكرة صحيحة بطريقة ما ... ولكن هناك دائمًا شيء من ذلك. لا يستطيع الجميع تحمل تكاليف إصلاح النسخ الاحتياطية ومراقبتها على مدار الساعة ، بل وأكثر من ذلك - مهندس مخصص لهذه الأغراض. نحن على يقين من أنه من الأفضل قضاء ساعتين في اليوم على شيء أكثر إنتاجية وفائدة. لذلك ، انتقلنا إلى البحث عن حلول بديلة "تعمل فقط".

برج كطريقة جديدة

انتشر البحث عن خيارات أخرى مفتوحة المصدر بمرور الوقت ، لذلك من الصعب تقدير إجمالي التكاليف ، ولكن في مرحلة ما (العام الماضي) ، تحول انتباهنا إلى " بطل المناسبة" - BorgBackup (أو ببساطة Borg). جزئيًا ، تم تسهيل ذلك من خلال التجربة الحقيقية لاستخدامه من قبل أحد مهندسينا (في مكان العمل السابق).

Borg مكتوب بلغة Python (الإصدار> = 3.4.0 مطلوب) ، ويتم تنفيذ التعليمات البرمجية التي تتطلب الأداء (الضغط والتشفير ، إلخ) في C / Cython. توزع تحت رخصة BSD مجانية (بند 3). وهو يدعم العديد من المنصات بما في ذلك Linux و * BSD و macOS ، وكذلك على المستوى التجريبي Cygwin و Linux Subsystem of Windows 10. لتثبيت BorgBackup ، تتوفر حزم لتوزيعات Linux الشائعة وأنظمة تشغيل أخرى ، بالإضافة إلى المصادر المثبتة من خلال pip ، - يمكن العثور على معلومات أكثر تفصيلا حول هذا في وثائق المشروع .

لماذا رشانا بورغ كثيرا؟ فيما يلي مزاياها الرئيسية:

• إلغاء البيانات المكررة : حقيقي وفعال للغاية (الأمثلة أدناه). تنقسم الملفات داخل مستودع Borg واحد (أي ، دليل خاص بتنسيق Borg الخاص) إلى كتل من n ميغابايت ، ويتم إلغاء تكرار كتل Borg المتكررة. يحدث إلغاء البيانات المكررة بدقة قبل الضغط.
• الضغط : بعد إلغاء البيانات المكررة ، يتم ضغط البيانات أيضًا. تتوفر خوارزميات ضغط مختلفة: lz4 و lzma و zlib و zstd. الميزة القياسية لأي نسخة احتياطية ، ولكن هذا لا يقل فائدة.
• العمل على SSH : النسخ الاحتياطية برج إلى خادم بعيد عبر SSH. على جانب الخادم ، تحتاج فقط إلى تثبيت Borg وهذا كل شيء! من هنا ، تليها على الفور مزايا مثل الأمان والتشفير. يمكنك تكوين الوصول فقط عن طريق المفاتيح ، علاوة على ذلك ، تنفيذ بورغ لأمر واحد فقط من الأوامر عند دخول الخادم. على سبيل المثال ، مثل هذا:
  
  

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

• يتم تسليمها في كل من PPA (نستخدم بشكل أساسي Ubuntu) وفي ثنائي ثابت . Borg في شكل ثنائي ثابت يجعل من الممكن تشغيله في كل مكان تقريبًا حيث يوجد على الأقل حد أدنى حديث. (ولكن ليس في كل مكان - على سبيل المثال ، لم يكن من الممكن البدء في CentOS 5.)
• التنظيف المرن للنسخ الاحتياطية القديمة . يمكنك ضبط تخزين آخر نسخ احتياطية ، ونسختين احتياطيتين لكل ساعة / يوم / أسبوع. في الحالة الأخيرة ، سيتم ترك آخر نسخة احتياطية في نهاية الأسبوع. يمكن دمج الشروط من خلال تخزين 7 نسخ احتياطية يومية لآخر 7 أيام و 4 نسخ احتياطية أسبوعية.

بدأ الانتقال إلى بورغ ببطء في المشاريع الصغيرة. في البداية ، كانت هذه مخطوطات كرون بسيطة تقوم بعملها كل يوم. استمر هذا لمدة ستة أشهر. خلال هذا الوقت ، كان علينا الحصول على نسخ احتياطية عدة مرات ... واتضح أن برج لم يكن بحاجة إلى إصلاح حرفي على الإطلاق! لماذا؟ لأن المبدأ البسيط يعمل هنا: "كلما كانت الآلية أبسط ، قل عدد الأماكن التي ستنكسر فيها."

تدريب: كيفية عمل نسخة احتياطية من Borg؟

فكر في مثال بسيط لإنشاء نسخة احتياطية:

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 

   
   ملاحظة : إذا كنت تستخدم جهازًا محليًا للاختبار كمصدر وكجهاز استقبال ، فسيكون الفرق بالكامل في URI فقط ، والذي سنرسله ، لكننا نتذكر أنه يجب تخزين النسخة الاحتياطية بشكل منفصل ، وليس على نفس الجهاز.
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 المحلية / بن / البرج خدمة "سه-آر إس إيه AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf / XmSVWfF7PfjGlbKW00MJ63zal / E / 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. نقوم بتهيئة borg repo على الخادم من العميل:
   
   

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

   
   يتم استخدام المفتاح -e لتحديد طريقة التشفير للمستودع (نعم ، يمكنك أيضًا تشفير كل مستودع بكلمة المرور الخاصة بك!). في هذه الحالة ، لأن هذا مثال ، نحن لا نستخدم التشفير. MyBorgRepo هو اسم الدليل الذي سيكون فيه borg repo (لا تحتاج إلى إنشائه مقدمًا - سيقوم Borg بكل شيء بنفسه).
6. قم بتشغيل النسخة الاحتياطية الأولى باستخدام Borg:
   
   

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

   
   حول المفاتيح:
   
   • --stats و - --stats تعطينا إحصائيات عن النسخ الاحتياطي والملفات التي دخلت فيه ؛
   • borg@172.17.0.3:MyBorgRepo - كل شيء واضح هنا ، هذا هو borg@172.17.0.3:MyBorgRepo . وماذا بعد للسحر؟ ..
   • ::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" هو اسم الأرشيف داخل المستودع. إنه إجراء تعسفي ، ولكننا نلتزم بتنسيق _-timestamp (الطابع الزمني بتنسيق Python).

ما هي الخطوة التالية؟ بالطبع ، انظر ما حصل في نسختنا الاحتياطية! قائمة المحفوظات داخل المستودع:

 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 مضيفًا. إدراكًا أن Borg يعمل حقًا ، بدأوا في نقل المزيد والمزيد من المشاريع إليه ...

وهنا نواجه ما يوجد في باروس ، ولكن ليس في برج! وهي: WebUI أو نوع من المكان المركزي لتكوين النسخ الاحتياطية. ونأمل حقًا أن تكون هذه ظاهرة مؤقتة ، ولكن كان علينا حتى الآن حل شيء ما. Googling الأدوات الجاهزة والتجمع في مؤتمر بالفيديو ، بدأنا العمل. لقد كانت فكرة رائعة لدمج Borg مع خدماتنا الداخلية ، كما فعلنا من قبل مع Bacula (أخذ Bacula نفسه قائمة الوظائف من واجهة برمجة التطبيقات المركزية الخاصة بنا ، والتي كانت لدينا واجهة خاصة بنا متكاملة مع إعدادات المشروع الأخرى). فكرنا في كيفية القيام بذلك ، وحددنا خطة لكيفية ومكان بنائه ، ولكن ... هناك حاجة الآن إلى نسخ احتياطية عادية ، ولكن لا توجد أماكن لاتخاذ خطط زمنية فخمة. ماذا تفعل

كانت الأسئلة والمتطلبات على النحو التالي تقريبًا:

• ما لاستخدام إدارة النسخ الاحتياطي المركزية؟
• ماذا يمكن أن يفعل أي مسؤول لينكس؟
• ما الذي يمكن حتى للمدير الذي يعرض جدول النسخ الاحتياطي للعملاء أن يكون قادرًا على فهمه وتكوينه؟
• ماذا تفعل المهمة المجدولة على نظامك كل يوم؟
• ما الذي لن يكون من الصعب تكوينه ولن ينكسر؟ ..

كان الجواب واضحًا: هذا هو الوغد القديم الجيد ، الذي يؤدي واجبه بشكل بطولي كل يوم. بسيط. لا تجمد. حتى المدير من Unix إلى "أنت" يمكنه إصلاحه.

لذا كرونتاب ، ولكن أين تحتفظ بكل هذا؟ هل في كل مرة تذهب إلى آلة المشروع وتحرير الملف بيديك؟ بالطبع لا. يمكننا وضع جدولنا الزمني في مستودع Git وتكوين GitLab Runner ، والذي من خلال الالتزام سيحدثه على المضيف.

ملاحظة : لقد تم اختيار GitLab كأداة للتشغيل التلقائي ، لأنها مناسبة للمهمة وفي حالتنا فهي في كل مكان تقريبًا. ولكن يجب أن أقول إنه ليس بالضرورة ضرورة.

يمكنك توسيع crontab للنسخ الاحتياطية باستخدام أداة أتمتة مألوفة أو يدويًا بشكل عام (في المشاريع الصغيرة أو التركيبات المنزلية).

لذا ، إليك ما تحتاجه لأتمتة بسيطة:

1. GitLab ومستودع ، حيث سيكون هناك في البداية ملفان:

• 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' 

يتم استخدام متغيرات CI للتحقق من نجاح تحديث 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 Runner ، يعمل على الجهاز الذي يحتاج إلى نسخ احتياطي ، وممنوع فقط لمهام هذا المستودع.

3. سكربت CI نفسه ، ينفذ بواسطة .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. مفتاح SSH gitlab-runner الوصول إلى خادم gitlab-runner (في المثال ، هو 10.100.1.1). بشكل افتراضي ، يجب أن يكون في الدليل الرئيسي .ssh/id_rsa ( gitlab-runner ).

5. مستخدم borg على نفس 10.100.1.1 مع وصول فقط إلى أمر borg serve :

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

الآن ، عندما تلتزم بمخزن Runner ، سيتم ملء محتويات crontab. وعندما يحين وقت استجابة cron ، سيتم عمل نسخة احتياطية من أدلة /etc و /opt ، والتي ستكون على خادم النسخ الاحتياطي في دليل MyHostname-SYSTEM للخادم 10.100.1.1.

بدلاً من الاستنتاج: ماذا يمكنك أن تفعل؟

استخدام بورغ في هذا ، بالطبع ، لا ينتهي عند هذا الحد. فيما يلي بعض الأفكار لمزيد من التنفيذ ، والتي قمنا بتنفيذ بعضها بالفعل في المنزل:

• أضف نصوصًا عامة للنسخ الاحتياطية المختلفة ، والتي تعمل في نهاية التنفيذ على borg_backup_files.sh ، والتي تهدف إلى الدليل مع نتيجة عملها. على سبيل المثال ، يمكنك الاحتفاظ بنسخة احتياطية من PostgreSQL (pg_basebackup) و MySQL (innobackupex) و GitLab (وظيفة أشعل النار مضمنة وإنشاء أرشيف).
• المضيف المركزي مع الجدول الزمني للنسخ الاحتياطي . ألا تريد التهيئة على كل مضيف GitLab Runner؟ دعه يكون بمفرده على خادم النسخ الاحتياطي ، ويقوم crontab عند بدء التشغيل بنقل البرنامج النصي للنسخ الاحتياطي إلى الجهاز وتشغيله هناك. لهذا ، بالطبع ، ستحتاج إلى مستخدم borg على جهاز العميل و ssh-agent ، حتى لا تضع مفتاح خادم النسخ الاحتياطي على كل جهاز.
• المراقبة أين بدونه! يجب أن تكون التنبيهات حول نسخة احتياطية مكتملة بشكل غير صحيح.
• تطهير مستودع البرج من الأرشيف القديم. على الرغم من التكرار الجيد ، لا يزال يتعين تنظيف النسخ الاحتياطية القديمة. للقيام بذلك ، يمكنك إجراء مكالمة ل borg prune في نهاية البرنامج النصي للنسخ الاحتياطي.
• واجهة الويب للجدول الزمني. سيكون مفيدًا إذا كان تحرير crontab يدويًا أو في واجهة الويب لا يبدو صلبًا / غير مريح بالنسبة لك.
• المخططات الدائرية . بعض الرسوم البيانية لتمثيل مرئي للنسبة المئوية للنسخ الاحتياطية المكتملة بنجاح ، ووقت تنفيذها ، وعرض القناة "التي تم تناولها". لا عجب أنني كتبت أنه ليس هناك ما يكفي من WebUI ، كما هو الحال في Bareos ...
• إجراءات بسيطة أود تلقيها بواسطة زر: تشغيل نسخة احتياطية عند الطلب ، واستعادة الجهاز ، وما إلى ذلك.

وفي النهاية ، أود أن أضيف مثالاً لفعالية إلغاء البيانات المكررة على نسخة احتياطية عمل حقيقية لملفات PostgreSQL WAL في بيئة إنتاج:

 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 يومًا من النسخ الاحتياطي لملفات WAL التي تتم كل ساعة. عند استخدام Bacula / Bareos ، أي بدون تكرار البيانات ، سنحصل على 6.7 تيرابايت من البيانات. فكر فقط: يمكننا تخزين ما يقرب من 7 تيرابايت من البيانات التي يتم تمريرها عبر PostgreSQL ، فقط 20 غيغابايت من المساحة المشغولة بالفعل.

ملاحظة

اقرأ أيضا في مدونتنا:

• " نظرية وممارسة الترقيات غير المراقب في أوبونتو " ؛
• " جونيور ، الذي قام في اليوم الأول من العمل بحذف قاعدة البيانات من الإنتاج " ؛
• " تسريع تمهيد قواعد البيانات الكبيرة مع Kubernetes ."