🥇كيف يساعدك GitLab في عمل نسخة احتياطية من وحدات تخزين NextCloud الكبيرة

يا هبر!

أريد اليوم أن أتحدث عن تجربتنا في أتمتة النسخ الاحتياطي للبيانات الضخمة لمخازن Nextcloud بتكوينات مختلفة. أنا أعمل في محطة خدمة في Molniya AK، حيث نشارك في إدارة تكوين أنظمة تكنولوجيا المعلومات، ويتم استخدام Nextcloud لتخزين البيانات. بما في ذلك، مع هيكل موزع، مع التكرار.

المشاكل الناشئة عن خصوصيات التثبيتات هي وجود الكثير من البيانات. الإصدار الذي يقدمه Nextcloud والتكرار والأسباب الذاتية والمزيد يخلق الكثير من الازدواجية.

قبل التاريخ

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

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

هناك العديد من العملاء، كل منهم بتكوينات مختلفة، وكلهم على مواقعهم وبخصائصهم الخاصة. هنا الأسلوب القياسي هو عندما يكون الموقع بأكمله ملكًا لك، ويتم عمل نسخ احتياطية من التاج، فهو لا يناسبك جيدًا.

أولا، دعونا نلقي نظرة على البيانات المدخلة. نحن نحتاج:

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

لحل مشكلة إدارة النسخ الاحتياطية، قمنا بإفساد GitLab. المزيد من المتداول.

بالطبع، لسنا أول من حل مثل هذه المشكلة، ولكن يبدو لنا أن تجربتنا العملية مع المعاناة يمكن أن تكون مثيرة للاهتمام ونحن على استعداد لمشاركتها.

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

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

لقد بدأنا البحث عن طرق الحل عن طريق اختيار أداة إنشاء النسخ الاحتياطي.

لا يعمل tar + gzip العادي بشكل جيد - البيانات مكررة. غالبًا ما تحتوي الزيادة على تغييرات قليلة جدًا في الواقع، ويتم تكرار معظم البيانات الموجودة في نفس الملف.
هناك مشكلة أخرى - التكرار في مستودع البيانات الموزعة. نحن نستخدم minio وبياناته زائدة عن الحاجة. أو كان من الضروري عمل نسخة احتياطية من خلال Minio نفسه - قم بتحميله واستخدام جميع الفواصل بين نظام الملفات، وما لا يقل أهمية، هناك خطر نسيان بعض المجموعات والمعلومات الوصفية. أو استخدم إلغاء البيانات المكررة.

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

إدارة النسخ الاحتياطي

إن Borg وRestic منتجان جيدان، لكن لا يتمتع أي من المنتجين بآلية تحكم مركزية. لغرض الإدارة والتحكم، اخترنا الأداة التي قمنا بتنفيذها بالفعل، والتي بدونها لا يمكننا تخيل عملنا، بما في ذلك الأتمتة - وهذا هو CI / CD المعروف - GitLab.

الفكرة هي كما يلي: يتم وضع gitlab-runner على كل عقدة تخزن بيانات Nextcloud. يقوم العداء بتشغيل برنامج نصي مجدول يراقب عملية النسخ الاحتياطي، ويبدأ تشغيل Borg أو Restic.

ماذا حصلنا؟ ردود الفعل من التنفيذ والتحكم المريح في التغييرات والتفاصيل في حالة حدوث خطأ.

ها هو هنا على جيثب لقد نشرنا أمثلة على البرنامج النصي لمختلف المهام، ونتيجة لذلك، قمنا بإرفاقه بالنسخة الاحتياطية ليس فقط لـ Nextcloud، ولكن أيضًا للعديد من الخدمات الأخرى. يوجد أيضًا برنامج جدولة، إذا كنت لا ترغب في إعداده بيديك (ونحن لا نريد ذلك) و.gitlab-ci.yml

ليس لدى Gitlab API القدرة على تغيير مهلة CI / CD، وهي صغيرة هناك. ولا بد من زيادتها، على سبيل المثال 1d.

لحسن الحظ، يمكن لـ GitLab أن يعمل ليس فقط وفقًا للالتزام، ولكن فقط وفقًا لجدول زمني، وهذا هو بالضبط ما نحتاجه.

الآن عن البرنامج النصي المجمع.

لقد قمنا بتعيين الشروط التالية لهذا البرنامج النصي:

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

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

سنكون سعداء بالنظر في أي اقتراحات وتعليقات بشأن المصادر المفتوحة - مرحبًا بك.

كيف يعمل هذا؟

يتم تشغيل عداء مع منفذ bash على العقدة الاحتياطية. وفقًا للمجدول، يتم إطلاق مهمة CI / CD في لفت خاص. يطلق العداء برنامجًا نصيًا شاملاً لمثل هذه المهام، ويتحقق من صحة مستودع النسخ الاحتياطي ونقاط التثبيت وكل ما نريده، ثم يقوم بعمل نسخة احتياطية من المستودع القديم وينظفه. يتم إرسال النسخة الاحتياطية النهائية نفسها إلى S3.

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

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

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

لدى Borg وضع عدم التشفير 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 - لون الرسالة (الأصفر الافتراضي).

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

ريستيك ضد بورغ

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

معايير الاختيار لدينا، بالإضافة إلى تلك المذكورة سابقًا (إلغاء البيانات المكررة، والاسترداد السريع، وما إلى ذلك):

المرونة في العمل الجاري. تحقق من القتل -9.
حجم القرص.
الطلب على الموارد (وحدة المعالجة المركزية والذاكرة).
حجم النقط المخزنة.
العمل مع S3.
التحقق من النزاهة.

للاختبار، أخذنا عميلًا واحدًا لديه بيانات حقيقية ويبلغ حجمها الإجمالي 1,6 تيرابايت.
الظروف.

لا يعمل بورغ مباشرة مع S3، وقمنا بتركيبه كقرص منصهر، عبر أبله. أرسلها ريستيك إلى S3 نفسها.

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

لتقليل تأثير الشبكة، استخدمنا مزودًا محليًا - Yandex Cloud.

نتائج اختبار المقارنة.

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

النسخ الاحتياطي
القياس

برج
562Gb

ريستيك
628Gb

بواسطة وحدة المعالجة المركزية
في حد ذاته، يستهلك borg القليل، مع الضغط الافتراضي، ولكن يجب تقييمه جنبًا إلى جنب مع عملية goofys. في المجمل، فهي قابلة للمقارنة وتستخدم حوالي 1,2 مركزًا على نفس الجهاز الظاهري للاختبار.
ذاكرة. Restic حوالي 0,5 جيجا بايت، بورج حوالي 200 ميجا بايت. لكن هذا كله غير مهم مقارنة بذاكرة التخزين المؤقت لملفات النظام. لذلك فمن المستحسن تخصيص المزيد من الذاكرة.
كان الفرق في حجم النقط مذهلاً.

النسخ الاحتياطي
القياس

برج
حوالي 500 ميجابايت

ريستيك
حوالي 5 ميجابايت

يعد العمل مع Restic's S3 أمرًا رائعًا. عمل Borg من خلال goofys لا يثير أي أسئلة، ولكن لوحظ أنه من المستحسن القيام بـ umount في نهاية النسخة الاحتياطية من أجل إعادة تعيين ذاكرة التخزين المؤقت بالكامل. خصوصية S3 هي أن الأجزاء التي تم تنزيلها بشكل ناقص لن يتم إرسالها أبدًا إلى المجموعة، مما يعني أن البيانات المملوءة بشكل غير كامل تؤدي إلى ضرر كبير.
يعمل فحص السلامة بشكل جيد في كلتا الحالتين، ولكن تختلف السرعة بشكل كبير.
ريستيك- ساعات 3,5.
Borg، مع ذاكرة تخزين مؤقت للملفات SSD سعة 100 جيجابايت - ساعات 5.تقريبا نفس النتيجة من حيث السرعة إذا كانت البيانات موجودة على القرص المحلي.
يقرأ Borg مباشرة من S3 بدون ذاكرة تخزين مؤقت ساعات 33. طويلة بشكل مدهش.

خلاصة القول هي أن Borg يمكنه الضغط ولديه نقاط أكبر - مما يجعل التخزين وعمليات GET/PUT في S3 أرخص. ولكن هذا يأتي على حساب فحص أكثر تعقيدًا وأبطأ. أما بالنسبة لسرعة الاسترداد فلم نلاحظ فرقا. يقوم Restic بإجراء عمليات النسخ الاحتياطي اللاحقة (بعد النسخة الأولى) لفترة أطول قليلاً، ولكن ليس بشكل ملحوظ.

لم يكن الأخير في الاختيار هو حجم المجتمع.

واخترنا بورج.

بضع كلمات عن الضغط

لدى Borg خوارزمية ضغط جديدة ممتازة في ترسانتها - zstd. جودة الضغط ليست أسوأ من gzip، ولكنها أسرع بكثير. وقابلة للمقارنة في السرعة مع lz4 الافتراضي.

على سبيل المثال، يتم ضغط تفريغ قاعدة بيانات MySQL مرتين أفضل من ضغط lz4 بنفس السرعة. ومع ذلك، تظهر تجربة البيانات الحقيقية أن هناك اختلافًا بسيطًا جدًا في نسبة الضغط لعقدة Nextcloud.

لدى Borg وضع ضغط إضافي إلى حد ما - إذا كان الملف يحتوي على إنتروبيا كبيرة، فلن يتم تطبيق الضغط على الإطلاق، مما يزيد من سرعة العمل. تمكين بواسطة الخيار عند الإنشاء
-C auto,zstd
لخوارزمية zstd
لذلك مع هذا الخيار، بالمقارنة مع الضغط الافتراضي، حصلنا على ذلك
560 جيجا بايت و 562 جيجا بايت على التوالي. البيانات من المثال أعلاه، اسمحوا لي أن أذكركم، بدون ضغط، النتيجة هي 628 جيجا بايت. لقد فاجأتنا نتيجة فرق 2 جيجا بايت قليلاً، لكننا اعتقدنا أننا سنختار على أي حال 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/

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

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

اختتام

نتيجة لذلك، نحن نعلم بالتأكيد أننا نقوم بإجراء نسخ احتياطية أن النسخ الاحتياطية لدينا صالحة، والمشاكل التي تنشأ معها تستغرق القليل من الوقت ويتم حلها على مستوى المسؤول المناوب. تشغل النسخ الاحتياطية مساحة صغيرة جدًا مقارنةً بـ tar.gz أو Bacula.

المصدر: www.habr.com