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

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

يجب أن أقول ، أن هذه النصوص عملت على أكمل وجه. ولكن كلما نمت ، ظهرت مشاريع أكثر تنوعًا ببرامج مختلفة ومستودعات خارجية لم تدعمها نصوصنا. على سبيل المثال ، لم يكن لدينا دعم لـ Redis ونسخ MySQL و PostgreSQL الساخنة التي ظهرت لاحقًا. لم تتم مراقبة عملية النسخ الاحتياطي ، وكانت هناك تنبيهات بالبريد الإلكتروني فقط.

مشكلة أخرى كانت عملية الدعم. على مر السنين ، نمت نصوصنا المدمجة مرة واحدة وتحولت إلى وحش ضخم محرج. وعندما اجتمعنا وأصدرنا إصدارًا جديدًا ، كان الأمر يستحق الجهد لنشر التحديث لهذا الجزء من العملاء الذين استخدموا الإصدار السابق مع نوع من التخصيص.

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

• قم بعمل نسخة احتياطية من بيانات البرنامج الأكثر استخدامًا:
  
  • الملفات (نسخ منفصلة ومتزايدة)
  • MySQL (نسخ احتياطي بارد / ساخن)
  • PostgreSQL (نسخ احتياطي بارد / ساخن)
  • مونغودب
  • ريديس
• تخزين النسخ الاحتياطية في المستودعات الشعبية:
  
  • محلي
  • بروتوكول نقل الملفات
  • Ssh
  • SMB
  • نففس
  • Webdav
  • ق 3
• تلقي تنبيهات في حالة حدوث أي مشاكل أثناء عملية النسخ الاحتياطي
• لديك ملف تكوين واحد يسمح لك بإدارة النسخ الاحتياطية بشكل مركزي
• أضف دعمًا للبرامج الجديدة عن طريق توصيل الوحدات الخارجية
• حدد خيارات إضافية لجمع مكبات النفايات
• لديها القدرة على استعادة النسخ الاحتياطية بالوسائل العادية
• التكوين الأولي السهل

نقوم بتحليل الحلول المتاحة

نظرنا في الحلول مفتوحة المصدر الموجودة بالفعل:

• باكولا وشوكها ، على سبيل المثال ، باروس
• أماندا
• برج
• دوبليكاتي
• الازدواجية
• Rsnapshot
• رديف النسخ الاحتياطي

لكن لكل منهم عيوبه. على سبيل المثال ، يتم تحميل Bacula بوظائف لا نحتاجها ، فالتكوين الأولي هو مهمة شاقة إلى حد ما بسبب الكمية الكبيرة من العمل اليدوي (على سبيل المثال ، الكتابة / البحث عن نصوص النسخ الاحتياطي لقاعدة البيانات) ، واستعادة النسخ التي تحتاجها لاستخدام أدوات مساعدة خاصة ، إلخ.

في النهاية توصلنا إلى استنتاجين هامين:

1. لا أحد من الحلول الحالية يناسبنا تمامًا ؛
2. يبدو أن لدينا أنفسنا ما يكفي من الخبرة والجنون لبدء كتابة قرارنا.

لذا فعلنا.

ولادة nxs-backup

تم اختيار Python كلغة للتنفيذ - من السهل الكتابة والصيانة والمرونة والملاءمة. تقرر وصف ملفات التكوين بتنسيق yaml.

من أجل راحة دعم النسخ الاحتياطية للبرامج الجديدة وإضافتها ، تم اختيار بنية معيارية حيث يتم وصف عملية جمع النسخ الاحتياطية لكل برنامج محدد (على سبيل المثال ، MySQL) في وحدة منفصلة.

دعم الملفات وقواعد البيانات والتخزين عن بعد

حاليًا ، يتم دعم الأنواع التالية من النسخ الاحتياطية للملفات وقواعد البيانات والمستودعات البعيدة:

DB:

• MySQL (نسخ احتياطي ساخن / بارد)
• PostgreSQL (نسخ احتياطي ساخن / بارد)
• ريديس
• مونغودب

الملفات:

• النسخ المنفصل
• النسخ التزايدي

المستودعات البعيدة:

• محلي
• ق 3
• SMB
• نففس
• بروتوكول نقل الملفات
• Ssh
• Webdav

نسخ احتياطي منفصل

بالنسبة للمهام المختلفة ، تكون النسخ الاحتياطية المنفصلة أو الإضافية مناسبة ، لذلك قاموا بتنفيذ كلا النوعين. يمكنك تحديد الطريقة التي ستستخدمها على مستوى الملفات والأدلة الفردية.

بالنسبة للنسخ المنفصلة (الملفات وقواعد البيانات) ، يمكنك تعيين نظرة استرجاعية بتنسيق الأيام / الأسابيع / الأشهر.

نسخ احتياطي تزايدي

يتم عمل نسخ متزايدة من الملفات على النحو التالي:

في بداية العام ، سيتم عمل نسخة احتياطية كاملة. بعد ذلك ، في بداية كل شهر - نسخة شهرية إضافية مقارنة بالنسخة السنوية. ضمن الحيض - عشري تزايدي بالنسبة للشهر. في غضون كل عشرة أيام من اليوم التدريجي بالنسبة إلى فترة العشرة أيام.

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

نتعافى من النسخ الاحتياطية الإضافية

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

1. قم بتوسيع نسخة احتياطية لمدة سنة واحدة ، حتى إذا كانت في حالتنا تبدأ من 1 يناير 2018 (في الواقع ، يمكن أن يكون هذا أي تاريخ ، اعتمادًا على الوقت الذي تقرر فيه تنفيذ عمليات النسخ الاحتياطي الإضافية)
2. لف عليه نسخة احتياطية شهرية لشهر يوليو
3. نشمر النسخ الاحتياطي عقد 21 يوليو
4. قم بتجميع النسخ الاحتياطي اليومي لـ 24 يوليو

في نفس الوقت ، لإجراء 2-4 نقاط ، يجب عليك إضافة مفتاح التبديل -G إلى الأمر tar ، مما يشير إلى أن هذه نسخة احتياطية متزايدة. بالطبع ، هذه ليست أسرع عملية ، ولكن بالنظر إلى أنه ليس من الضروري في كثير من الأحيان التعافي من النسخ الاحتياطية وفعالية التكلفة أمر مهم ، فقد تبين أن هذا المخطط فعال للغاية.

الاستثناءات

في كثير من الأحيان ، تحتاج إلى استبعاد الملفات الفردية أو الأدلة من النسخ الاحتياطية ، على سبيل المثال ، الأدلة مع ذاكرة التخزين المؤقت. يمكن القيام بذلك عن طريق تحديد قواعد الاستثناء المناسبة:

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

دوران النسخ الاحتياطي

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

في التطبيق الجديد ، قررنا تغيير هذا النهج: أولاً حذف الأسلوب القديم ثم جمع نسخة جديدة فقط. ويجب مراقبة عملية جمع النسخ الاحتياطية لمعرفة أي مشاكل.

بالنسبة للنسخ الاحتياطية المنفصلة ، يعتبر الأرشيف نسخة قديمة تتجاوز نظام التخزين المحدد بتنسيق الأيام / الأسابيع / الأشهر. في حالة النسخ الاحتياطية الإضافية ، يتم تخزين النسخ الاحتياطية افتراضيًا لمدة عام ، ويتم حذف النسخ القديمة في بداية كل شهر ، في حين تعتبر الأرشيفات لنفس الشهر من العام الماضي نسخًا احتياطية قديمة. على سبيل المثال ، قبل جمع نسخة احتياطية شهرية في 1 أغسطس 2018 ، سيتحقق النظام مما إذا كانت هناك نسخ احتياطية لشهر أغسطس 2017 ، وإذا كان الأمر كذلك ، فسيحذفها. هذا يسمح بالاستخدام الأمثل لمساحة القرص.

تسجيل الدخول

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

تنقسم الأحداث إلى مستويين:

• معلومات : مستوى المعلومات - الرحلة طبيعية ، تم الانتهاء من المرحلة التالية بنجاح ، يتم إدخال المعلومات المقابلة في السجل
• خطأ : مستوى الخطأ - حدث خطأ ما ، فشلت المرحلة التالية ، سجل خطأ مطابق في السجل

إخطارات البريد الإلكتروني

في نهاية مجموعة النسخ الاحتياطي ، يمكن للنظام إرسال إشعارات بالبريد الإلكتروني.

قائمتا المستلمين مدعومتان:

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

هيكل ملف التكوين

هيكل ملفات التكوين كما يلي:

 /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 ومنفذ 3307 لـ bitrix_2_db).

تكون بنية ملف مشروع Bitrix نموذجي تقريبًا كما يلي:

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

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

ستبدو ملفات التكوين الناتجة لهذا الإعداد كما يلي:

  - 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 

  - 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 

  - 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-backup.

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

يجب إيلاء اهتمام خاص لمفتاح dump_cmd ، حيث القيمة هي الأمر الكامل لتشغيل برنامج نصي خارجي. علاوة على ذلك ، عند الانتهاء من هذا الأمر ، من المتوقع أن:

• سيتم جمع أرشيف جاهز لبيانات البرامج
• سيتم إرسال البيانات إلى stdout بتنسيق 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. إذا لم يكن الأمر كذلك ، فسيتم إكمال هذه المهمة بالعلامة المقابلة في السجل.

الدعم والتحديث

تم تنفيذ عملية تطوير ودعم نظام النسخ الاحتياطي الجديد بجميع شرائع CI / CD. لا مزيد من التحديثات وتعديلات البرنامج النصي على خوادم المعارك. تمر جميع التغييرات من خلال مستودع git المركزي الخاص بنا في Gitlab ، حيث يتم تسجيل تجميع الإصدارات الجديدة من حزم deb / rpm في خط الأنابيب ، والتي يتم تحميلها بعد ذلك إلى مستودعات deb / rpm. وبعد ذلك ، من خلال مدير الحزم ، يتم تسليمها إلى خوادم العملاء النهائيين.

كيفية تحميل nxs-backup؟

لقد صنعنا nxs-backup مشروع مفتوح المصدر. يمكن لأي شخص تنزيله واستخدامه لتنظيم عملية النسخ الاحتياطي في مشاريعه ، وكذلك تعديل احتياجاته ، وكتابة وحدات خارجية.

يمكن تحميل كود مصدر nxs-backup من مستودع Github على هذا الرابط . هناك أيضًا تعليمات التثبيت والتكوين.

قمنا أيضًا بإعداد صورة Docker ونشرناها على DockerHub .

إذا كانت لديك أي أسئلة أثناء عملية الإعداد أو الاستخدام ، فاكتب إلينا. سنساعد على فهم التعليمات وإنهائها.

الخلاصة

في المستقبل القريب ، سنقوم بتنفيذ الوظائف التالية:

• مراقبة التكامل
• تشفير النسخ الاحتياطي
• واجهة على شبكة الإنترنت لإدارة إعدادات النسخ الاحتياطي
• نشر النسخ الاحتياطية باستخدام nxs-backup
• وغير ذلك الكثير