التراجع الآمن عن تحديث SLES الفاشل باستخدام Snapper

في تثبيت SUSE Linux Enterprise Server (SLES) القياسي مع نظام ملفات Btrfs الجذر و Snapper مُفعّل، فإنّ أفضل طريقة للاستعادة هي تشغيل نسخة احتياطية تم إنشاؤها قبل فشل التحديث، واختبارها أثناء كونها للقراءة فقط، ثم تشغيل الأمر sudo snapper rollback. هذا يُنشئ جذرًا جديدًا قابلًا للكتابة من الحالة المختبرة؛ ولا يُعيد كل قرص أو وحدة تخزين فرعية أو قاعدة بيانات تطبيق إلى حالتها الأصلية.

لا تزال إرشادات إدارة SLES 15 SP7 الحالية تستخدم سير عمل التمهيد والاختبار هذا. قبل اتباعه، تأكد من أن الجهاز يفي بمتطلبات SUSE فيما يتعلق بتخطيط التراجع المدعوم، وحدد اللقطة السابقة لعملية Zypper أو YaST الفاشلة.

هل سيؤدي التراجع باستخدام Snapper إلى استعادة الخادم بالكامل؟

لا. ينطبق التراجع عن النظام القابل للتشغيل على اللقطات في تكوين Snapper الافتراضي root. تدعم SUSE ترتيب المجلدات الفرعية الجذرية الافتراضي، مع نظام ملفات Btrfs على جهاز جذر واحد وبرنامج تحميل إقلاع مثبت يعمل بشكل صحيح. يُغير التراجع محتويات المجلد الفرعي `<sub>sub>` /؛ ولا يشمل المجلدات الفرعية الأخرى. في تخطيطات SLES النموذجية، غالبًا ما تكون مسارات مثل /var` <sub>sub /srv>` و`< sub>sub /opt> /usr/local` و`<sub>sub>` و`<sub>sub>` /homeخارج نطاق اللقطة. لذلك، قد تحتفظ قاعدة البيانات أو الخدمة بالبيانات المكتوبة بعد اللقطة حتى أثناء عودة حزم النظام الخاصة بها.

قم بأخذ نسخة احتياطية منفصلة أو التحقق منها لبيانات التطبيق المهمة قبل إجراء عملية التراجع. تجنب هذه العملية أيضًا إذا قمت بتغيير تخطيط وحدة التخزين الفرعية الافتراضي لنظام Btrfs أو كنت تستخدم جذرًا متعدد الأجهزة: متطلبات التراجع القابلة للتشغيل الموثقة لنظام SLES 15 SP7 لا تغطي هذه الإعدادات. اقرأ متطلبات استعادة Snapper من SUSE قبل المتابعة.

ما هي اللقطة التي تم التقاطها قبل فشل التحديث؟

استخدم إعدادات Snapper لنظام الملفات الجذر وقارن بين لقطات ما قبل وما بعد العملية. في نظام SLES نموذجي مع تمكين لقطات جذر Btrfs، يقوم Zypper وYaST بإنشاء لقطات حول عمليات الحزم. تمثل لقطة ما قبل العملية حالة الجذر قبل تنفيذها، بينما تمثل لقطة ما بعد العملية الحالة بعد تنفيذها، بما في ذلك أي عملية فشلت جزئيًا.

1. تأكد من وجود ملف الإعدادات الرئيسي باستخدام الأمر ` sudo snapper list-configs.`. ابحث عن ملف إعدادات باسم ` root.`
2. تأكد من نوع نظام الملفات الجذر باستخدام الأمر المناسب findmnt -no FSTYPE /. في عملية استعادة النظام القابلة للتشغيل هذه، يجب أن يُظهر الأمر معلومات تفيد بذلك btrfs. ثم شغّل الأمر sudo btrfs filesystem show /وتأكد من صحة تقارير نظام الملفات الجذر Total devices 1.
3. اعرض أزواج المعاملات مع sudo snapper -c root list -t pre-post. طابق التاريخ والوصف مع التحديث الفاشل. سجل الرقم في Pre #العمود، وليس المقترن Post #.
4. راجع التغييرات التي طرأت بين الزوجين. استبدل القيمتين PREو POSTبالأرقام الموضحة على جهازك:

sudo snapper -c root status PRE..POST
sudo snapper -c root diff PRE..POST

تُدرج هذه الأوامر المسارات المُعدّلة واختلافات الملفات. تختلف أرقام اللقطات وتواريخها وأوصاف الحزم ومخرجاتها باختلاف المضيف؛ لذا لا تنسخ رقمًا من لقطة شاشة. إذا لم يظهر أي زوج ذي صلة، فتحقق مما إذا كان Snapper مُفعّلاً وما إذا كانت سياسة التنظيف قد أزالت اللقطة بالفعل. لا يمكن لـ Snapper إعادة إنشاء لقطة مفقودة بعد حذفها.

كيف تختبر الجذر القديم قبل جعله دائمًا؟

أعد تشغيل الجهاز واستخدم خيار اللقطة في مُحمِّل الإقلاع. في نظام SLES، اختر Start Bootloader from a read-only snapshot، ثم حدد اللقطة التي يعود تاريخها إلى ما قبل العملية الفاشلة مباشرةً. تُصنِّف قائمة الإقلاع الخيارات بتاريخها ووصفها، والذي قد يتضمن zypp(zypper)عملية YaST أو . اختر اللقطة التي سجلتها قبل التحديث؛ لا تختر اللقطة التي سجلتها بعد التحديث لمجرد أن وصفها أسهل في التعرف عليه.

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

متى يجب عليك تشغيل برنامج Snapper Rollback؟

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

sudo snapper rollback

ثم أعد تشغيل الجهاز واختر خيار الإقلاع الافتراضي العادي:

sudo reboot

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

ما الذي يجب عليك التحقق منه بعد إعادة التشغيل؟

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

sudo snapper -c root list

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

sudo zypper ref -fs
sudo zypper lr
sudo SUSEConnect --status

يجب أن تتطابق المستودعات مع حزمة الخدمة التي قمت بالرجوع إليها، ويجب تسجيل المنتجات المثبتة. في حال عدم استعادة التسجيل، يُرجى الرجوع إلى إجراءات استعادة حزمة الخدمة SLES 15 SP7sudo SUSEConnect --rollback الخاصة بـ SUSE كخطوة إصلاح. يُذكر أن أمر التسجيل هذا خاص باستعادة النظام بعد الترحيل؛ لذا لا تقم بتشغيله لتحديث حزمة النظام بشكل روتيني.

إذا كان هذا المضيف يستخدم transactional-update(على سبيل المثال، نظام SLE Micro للمعاملات)، فاتبع إجراءات ذلك المنتج بدلاً من تطبيق تسلسل أوامر SLES التقليدي. تستخدم وثائقه sudo transactional-update rollback SNAPSHOT_NUMBERطريقة لاختيار لقطة من النظام قيد التشغيل، وسير عمل منفصل للقطة للقراءة فقط عند بدء التشغيل في حالة تعطل النظام الجذر الحالي. راجع تعليمات SUSE للتراجع عن تحديثات المعاملات .