تكمل هذه المذكرة دورة النسخ الاحتياطي. سيناقش التنظيم المنطقي لخادم مخصص (أو VPS)، مناسب للنسخ الاحتياطي، وسيقدم أيضًا خيارًا لاستعادة الخادم بسرعة من نسخة احتياطية دون توقف كبير في حالة وقوع كارثة.
البيانات الأولية
غالبًا ما يحتوي الخادم المخصص على محركي أقراص ثابتة على الأقل يعملان على تنظيم مصفوفة RAID من المستوى الأول (المرآة). يعد ذلك ضروريًا لتتمكن من متابعة تشغيل الخادم في حالة فشل أحد الأقراص. إذا كان هذا خادمًا مخصصًا عاديًا، فقد تكون هناك وحدة تحكم RAID منفصلة للأجهزة مع تقنية التخزين المؤقت النشطة على SSD، بحيث يمكن توصيل واحد أو أكثر من محركات أقراص SSD بالإضافة إلى محركات الأقراص الثابتة العادية. في بعض الأحيان يتم تقديم خوادم مخصصة، حيث تكون الأقراص المحلية الوحيدة هي SATADOM (أقراص صغيرة، محرك أقراص محمول من الناحية الهيكلية متصل بمنفذ SATA)، أو حتى محرك أقراص محمول صغير عادي (8-16 جيجابايت) متصل بمنفذ داخلي خاص، و يتم أخذ البيانات من نظام التخزين، ويتم توصيلها عبر شبكة تخزين مخصصة (Ethernet 10G، FC، وما إلى ذلك)، وهناك خوادم مخصصة يتم تحميلها مباشرة من نظام التخزين. لن أفكر في مثل هذه الخيارات، لأنه في مثل هذه الحالات، تنتقل مهمة النسخ الاحتياطي للخادم بسلاسة إلى المتخصص الذي يحافظ على نظام التخزين؛ عادةً ما تكون هناك تقنيات خاصة مختلفة لإنشاء اللقطات وإلغاء البيانات المكررة المضمنة وغيرها من أفراح مسؤول النظام ، تمت مناقشته في الأجزاء السابقة من هذه السلسلة. يمكن أن يصل حجم مصفوفة الأقراص الخاصة بالخادم المخصص إلى عدة عشرات من التيرابايت، اعتمادًا على عدد وحجم الأقراص المتصلة بالخادم. في حالة VPS، تكون الأحجام أكثر تواضعًا: عادةً لا تزيد عن 100 جيجابايت (ولكن هناك أيضًا المزيد)، ويمكن أن تكون تعريفات VPS هذه أكثر تكلفة بسهولة من أرخص الخوادم المخصصة من نفس المضيف. غالبًا ما يحتوي VPS على قرص واحد، لأنه سيكون هناك نظام تخزين (أو شيء متقارب للغاية) أسفله. في بعض الأحيان يحتوي VPS على عدة أقراص ذات خصائص مختلفة، لأغراض مختلفة:
- نظام صغير - لتثبيت نظام التشغيل.
- كبير - تخزين بيانات المستخدم.
عند إعادة تثبيت النظام باستخدام لوحة التحكم، لا تتم الكتابة فوق القرص الذي يحتوي على بيانات المستخدم، ولكن تتم إعادة تعبئة قرص النظام بالكامل. أيضًا، في حالة VPS، قد يقدم المضيف زرًا يأخذ لقطة لحالة VPS (أو القرص)، ولكن إذا قمت بتثبيت نظام التشغيل الخاص بك أو نسيت تنشيط الخدمة المطلوبة داخل VPS، فإن بعض من البيانات قد لا تزال مفقودة. بالإضافة إلى الزر، يتم تقديم خدمة تخزين البيانات عادةً، وغالبًا ما تكون محدودة جدًا. عادةً ما يكون هذا حسابًا يتمتع بإمكانية الوصول عبر FTP أو SFTP، وأحيانًا مع SSH، مع غلاف مُجرد (على سبيل المثال، rbash)، أو قيود على تشغيل الأوامر من خلال المفاتيح المعتمدة (عبر ForcedCommand).
يتم توصيل الخادم المخصص بالشبكة عن طريق منفذين بسرعة 1 جيجابت في الثانية، وفي بعض الأحيان يمكن أن تكون هذه بطاقات بسرعة 10 جيجابت في الثانية. غالبًا ما يحتوي VPS على واجهة شبكة واحدة. في أغلب الأحيان، لا تحد مراكز البيانات من سرعة الشبكة داخل مركز البيانات، ولكنها تحد من سرعة الوصول إلى الإنترنت.
التحميل النموذجي لمثل هذا الخادم المخصص أو VPS هو خادم ويب وقاعدة بيانات وخادم تطبيقات. في بعض الأحيان قد يتم تثبيت العديد من الخدمات الإضافية الإضافية، بما في ذلك خادم الويب أو قاعدة البيانات: محرك البحث، نظام البريد، إلخ.
يعمل الخادم المجهز خصيصًا كمساحة لتخزين النسخ الاحتياطية، وسنكتب عنه بمزيد من التفصيل لاحقًا.
التنظيم المنطقي لنظام القرص
إذا كان لديك وحدة تحكم RAID، أو VPS بقرص واحد، ولا توجد تفضيلات خاصة لتشغيل النظام الفرعي للقرص (على سبيل المثال، قرص سريع منفصل لقاعدة البيانات)، يتم تقسيم كل المساحة الحرة على النحو التالي: قسم واحد يتم إنشاء مجموعة مجلدات LVM فوقها، ويتم إنشاء عدة مجلدات فيها: مجلدان صغيران من نفس الحجم، يستخدمان كنظام ملفات جذر (يتم تغييرهما واحدًا تلو الآخر أثناء التحديثات لإمكانية التراجع السريع، تم التقاط الفكرة من توزيعة Calculate Linux)، فكرة أخرى مخصصة لقسم المبادلة، أما باقي المساحة الحرة فهي مقسمة إلى وحدات تخزين صغيرة، تُستخدم كنظام ملفات جذر للحاويات الكاملة، وأقراص للأجهزة الافتراضية، والملفات أنظمة الحسابات في /home (كل حساب له نظام ملفات خاص به)، وأنظمة الملفات لحاويات التطبيقات.
ملاحظة هامة: يجب أن تكون المجلدات مستقلة تمامًا، أي. لا ينبغي أن تعتمد على بعضها البعض أو على نظام الملفات الجذر. في حالة الأجهزة الافتراضية أو الحاويات، يتم ملاحظة هذه النقطة تلقائيًا. إذا كانت هذه حاويات تطبيقات أو أدلة منزلية، فيجب أن تفكر في فصل ملفات التكوين الخاصة بخادم الويب والخدمات الأخرى بطريقة تزيل التبعيات بين وحدات التخزين قدر الإمكان. على سبيل المثال، يتم تشغيل كل موقع من المستخدم الخاص به، وملفات تكوين الموقع موجودة في الدليل الرئيسي للمستخدم، وفي إعدادات خادم الويب، لا يتم تضمين ملفات تكوين الموقع عبر /etc/nginx/conf.d/.conf، وعلى سبيل المثال، /home//configs/nginx/*.conf
إذا كان هناك عدة أقراص، فيمكنك إنشاء مصفوفة RAID برمجية (وتكوين التخزين المؤقت الخاص بها على SSD، إذا كانت هناك حاجة وفرصة)، وفوقها يمكنك إنشاء LVM وفقًا للقواعد المقترحة أعلاه. في هذه الحالة أيضًا، يمكنك استخدام ZFS أو BtrFS، ولكن يجب أن تفكر مليًا في هذا الأمر: كلاهما يتطلب نهجًا أكثر جدية للموارد، وإلى جانب ذلك، لم يتم تضمين ZFS في Linux kernel.
بغض النظر عن المخطط المستخدم، فمن المفيد دائمًا تقدير السرعة التقريبية لكتابة التغييرات على الأقراص مسبقًا، ثم حساب مقدار المساحة الحرة التي سيتم حجزها لإنشاء لقطات. على سبيل المثال، إذا كان خادمنا يكتب البيانات بسرعة 10 ميغا بايت في الثانية، وكان حجم مصفوفة البيانات بأكملها 10 تيرابايت - يمكن أن يصل وقت المزامنة إلى يوم (22 ساعة - وهذا هو مقدار هذا الحجم الذي سيتم نقله عبر الشبكة 1 جيجابت في الثانية) - يستحق حجز حوالي 800 جيجا بايت . في الواقع، سيكون الرقم أصغر، ويمكنك تقسيمه بأمان على عدد المجلدات المنطقية.
جهاز خادم تخزين النسخ الاحتياطي
والفرق الرئيسي بين خادم تخزين النسخ الاحتياطية هو أقراصه الكبيرة والرخيصة والبطيئة نسبيًا. نظرًا لأن محركات الأقراص الثابتة الحديثة قد تجاوزت بالفعل شريط 10 تيرابايت في قرص واحد، فمن الضروري استخدام أنظمة الملفات أو RAID مع المجاميع الاختبارية، لأنه أثناء إعادة بناء المصفوفة أو استعادة نظام الملفات (عدة أيام!) قد يفشل القرص الثاني بسبب لزيادة الحمل. على الأقراص التي تصل سعتها إلى 1 تيرابايت، لم يكن هذا الأمر حساسًا جدًا. لتبسيط الوصف، أفترض أن مساحة القرص مقسمة إلى جزأين متساويين في الحجم تقريبًا (مرة أخرى، على سبيل المثال، باستخدام LVM):
- وحدات التخزين المقابلة للخوادم المستخدمة لتخزين بيانات المستخدم (سيتم نشر آخر نسخة احتياطية تم إجراؤها عليها للتحقق)؛
- وحدات التخزين المستخدمة كمستودعات BorgBackup (سيتم نقل بيانات النسخ الاحتياطية مباشرة هنا).
مبدأ التشغيل هو إنشاء وحدات تخزين منفصلة لكل خادم لمستودعات BorgBackup، حيث ستذهب البيانات من الخوادم القتالية. تعمل المستودعات في وضع الإلحاق فقط، مما يلغي إمكانية حذف البيانات عمدًا، وبسبب إلغاء البيانات المكررة والتنظيف الدوري للمستودعات من النسخ الاحتياطية القديمة (تبقى نسخ سنوية، شهريًا للعام الماضي، وأسبوعيًا للشهر الأخير، ويوميًا للشهر الماضي) الأسبوع الماضي، ربما في حالات خاصة - كل ساعة في اليوم الأخير: إجمالي 24 + 7 + 4 + 12 + سنوي - حوالي 50 نسخة لكل خادم).
لا تقوم مستودعات BorgBackup بتمكين وضع الإلحاق فقط؛ بدلاً من ذلك، يتم استخدام ForcedCommand في .ssh/authorized_keys بشيء من هذا القبيل:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......يحتوي المسار المحدد على برنامج نصي مجمّع أعلى borg، والذي، بالإضافة إلى تشغيل الملف الثنائي باستخدام المعلمات، يبدأ أيضًا عملية استعادة النسخة الاحتياطية بعد إزالة البيانات. للقيام بذلك، يقوم البرنامج النصي المجمع بإنشاء ملف علامة بجوار المستودع المقابل. تتم استعادة آخر نسخة احتياطية تم إجراؤها تلقائيًا إلى وحدة التخزين المنطقية المقابلة بعد اكتمال عملية ملء البيانات.
يتيح لك هذا التصميم تنظيف النسخ الاحتياطية غير الضرورية بشكل دوري، ويمنع أيضًا الخوادم القتالية من حذف أي شيء على خادم تخزين النسخ الاحتياطي.
عملية النسخ الاحتياطي
بادئ النسخ الاحتياطي هو الخادم المخصص أو VPS نفسه، حيث أن هذا المخطط يمنح المزيد من التحكم في عملية النسخ الاحتياطي من جانب هذا الخادم. أولاً، يتم أخذ لقطة لحالة نظام الملفات الجذر النشط، والتي يتم تركيبها وتحميلها باستخدام BorgBackup إلى خادم تخزين النسخ الاحتياطي. بعد اكتمال التقاط البيانات، يتم إلغاء تحميل اللقطة وحذفها.
إذا كانت هناك قاعدة بيانات صغيرة (تصل إلى 1 جيجابايت لكل موقع)، يتم عمل تفريغ لقاعدة البيانات، والتي يتم حفظها في المجلد المنطقي المناسب، حيث توجد بقية البيانات لنفس الموقع، ولكن بحيث يتم التفريغ لا يمكن الوصول إليها من خلال خادم الويب. إذا كانت قواعد البيانات كبيرة، فيجب عليك تكوين إزالة البيانات "الساخنة"، على سبيل المثال، باستخدام xtrabackup لـ MySQL، أو العمل مع WAL باستخدام archive_command في PostgreSQL. وفي هذه الحالة، سيتم استعادة قاعدة البيانات بشكل منفصل عن بيانات الموقع.
إذا تم استخدام حاويات أو أجهزة افتراضية، فيجب عليك تكوين qemu-guest-agent أو CRIU أو التقنيات الضرورية الأخرى. في حالات أخرى، لا تكون هناك حاجة إلى إعدادات إضافية في أغلب الأحيان - فنحن ببساطة نقوم بإنشاء لقطات من وحدات التخزين المنطقية، والتي تتم معالجتها بعد ذلك بنفس طريقة معالجة لقطة حالة نظام الملفات الجذر. بعد التقاط البيانات، يتم حذف الصور.
يتم تنفيذ المزيد من العمل على خادم تخزين النسخ الاحتياطي:
- يتم التحقق من آخر نسخة احتياطية تم إجراؤها في كل مستودع،
- يتم التأكد من وجود ملف العلامة مما يدل على اكتمال عملية جمع البيانات،
- يتم توسيع البيانات إلى الحجم المحلي المقابل،
- يتم حذف ملف العلامة
عملية استرداد الخادم
إذا مات الخادم الرئيسي، فسيتم إطلاق خادم مخصص مماثل، والذي يتم تشغيله من بعض الصور القياسية. من المرجح أن يتم التنزيل عبر الشبكة، ولكن يمكن لفني مركز البيانات الذي يقوم بإعداد الخادم نسخ هذه الصورة القياسية على الفور إلى أحد الأقراص. يتم التنزيل في ذاكرة الوصول العشوائي (RAM)، وبعد ذلك تبدأ عملية الاسترداد:
- يتم تقديم طلب لإرفاق جهاز كتلة عبر iscsinbd أو بروتوكول آخر مشابه لوحدة تخزين منطقية تحتوي على نظام الملفات الجذر للخادم المتوفى؛ نظرًا لأن نظام الملفات الجذر يجب أن يكون صغيرًا، فيجب إكمال هذه الخطوة في بضع دقائق. يتم أيضًا استعادة أداة تحميل التشغيل؛
- تتم إعادة إنشاء بنية وحدات التخزين المنطقية المحلية، ويتم إرفاق وحدات التخزين المنطقية من خادم النسخ الاحتياطي باستخدام وحدة kernel dm_clone: تبدأ عملية استعادة البيانات، وتتم كتابة التغييرات على الفور على الأقراص المحلية
- يتم تشغيل الحاوية بجميع الأقراص الفعلية المتاحة - تتم استعادة وظائف الخادم بالكامل، ولكن مع انخفاض الأداء؛
- بعد اكتمال مزامنة البيانات، يتم فصل وحدات التخزين المنطقية من خادم النسخ الاحتياطي، ويتم إيقاف تشغيل الحاوية، وإعادة تشغيل الخادم؛
بعد إعادة التشغيل، سيحتوي الخادم على جميع البيانات التي كانت موجودة في وقت إنشاء النسخة الاحتياطية، وسيتضمن أيضًا جميع التغييرات التي تم إجراؤها أثناء عملية الاستعادة.
مقالات أخرى في السلسلة
جزء النسخ الاحتياطي 7: الاستنتاجات
أدعوك لمناقشة الخيار المقترح في التعليقات، شكرًا لك على اهتمامك!
المصدر: www.habr.com