دليل الاستعادة الآمنة لنظام SLES Btrfs Snapper بعد فشل التحديث

لا يعني فشل تحديث SLES بالضرورة إعادة تثبيت الخادم. ففي تثبيت SUSE Linux Enterprise Server القياسي الذي يستخدم نظام ملفات Btrfs كنظام ملفات جذر مع تفعيل Snapper، يمكنك غالبًا تشغيل نسخة احتياطية قبل التحديث، واختبارها دون تغيير النظام الحالي، ثم جعل تلك النسخة السليمة هي نظام الملفات الجذر الجديد القابل للكتابة.

القرار المهم ليس ببساطة "أي نسخة احتياطية هي الأحدث؟" بل "إلى أي مدى يجب عليّ التراجع؟" يُعد التراجع الكامل لنظام Snapper مناسبًا عندما يُغيّر تحديثٌ ما العديد من الحزم أو المكتبات أو الخدمات أو ملفات التكوين، ويصبح الجهاز غير مستقر. أما إذا كان ملف تكوين واحد فقط معيبًا، فإن استعادة هذا الملف عادةً ما تكون أقل تأثيرًا على النظام. يشرح هذا الدليل كلا الخيارين، ويتبع نموذج استعادة SLES 15 SP7 الموثق من قِبل SUSE والمتاح في أكتوبر 2026.

اختر طريقة الاستعادة قبل تغيير أي شيء

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

الخطوة 1: تأكد من أن هذا الخادم يدعم مسار التراجع القياسي لبرنامج Snapper

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

findmnt /
sudo snapper list-configs
sudo /sbin/btrfs filesystem show /

إذا findmnt /أبلغ النظام عن نظام ملفات مثل XFS أو Ext4، فتوقف: عملية التمهيد باستخدام لقطات Btrfs غير متاحة لهذا الجذر. إذا snapper list-configsلم يكن هناك rootإدخال، فقد لا تكون لقطات الجذر التلقائية مُفعّلة. توقف أيضًا إذا btrfs filesystem show /أبلغ النظام عن أكثر من جهاز واحد؛ لا تُدرج وثائق SLES 15 SP7 هذا التخطيط ضمن الأنظمة المدعومة للرجوع إلى الجذر القابل للتمهيد.

الخطوة الثانية: تحديد اللقطة المأخوذة مباشرة قبل فشل التحديث

قم بإدراج اللقطات وانظر إلى تاريخها ونوعها وعلاقتها باللقطة السابقة ووصفها:

sudo snapper list

في الإعداد الافتراضي لنظام SLES، يمكن لبرنامجي YaST وZypper إنشاء أزواج من اللقطات preوحفظها post. preتمثل اللقطة حالة نظام الملفات قبل العملية، بينما postتمثل اللقطة المطابقة لها الحالة بعدها. لا تختر لقطة لمجرد أنها أقدم من وقت حدوث العطل. طابق الطابع الزمني للقطة ووصفها مع نافذة التحديث.

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

الخطوة 3: تفحص ما الذي ستغيره لقطة المرشح فعلياً

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

sudo snapper status SNAPSHOT_ID..0
sudo snapper diff SNAPSHOT_ID..0 /etc/some-file.conf

عندما يكون الاستعادة الانتقائية هي الخيار الأفضل

إذا كان أحد الملفات المعروفة به خلل، بينما بقية النظام المُحدَّث سليم، فإن استعادة ذلك الملف فقط تجنّب التراجع عن تغييرات النظام غير ذات الصلة. توثّق SUSE هذا النموذج:

sudo snapper -c root -v undochange SNAPSHOT_ID..0 /etc/some-file.conf

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

الخطوة 4: تشغيل لقطة المرشح من GRUB

أعد تشغيل الجهاز. في قائمة SLES GRUB 2، اختر خيار بدء تشغيل مُحمّل الإقلاع من لقطة للقراءة فقط، ثم حدد اللقطة التي تُطابق حالة ما قبل التحديث. قد يختلف تخطيط الشاشة باختلاف البرامج الثابتة وإعدادات الإقلاع، ولكن SLES 15 SP7 يُشير إلى هذا الخيار باسم " بدء تشغيل مُحمّل الإقلاع من لقطة للقراءة فقط" .

لا يمكن الإقلاع عبر آلية SLES هذه إلا من خلال لقطات من إعدادات Snapper الافتراضية root. إذا كانت قائمة اللقطات مفقودة، فلا تقم بإنشاء مدخل إقلاع. أعد التحقق مما إذا كان Snapper مُفعّلاً، وما إذا كان تخطيط الجذر لا يزال هو البنية المدعومة افتراضيًا، وما إذا كان مُحمّل الإقلاع المُثبّت يعمل بشكل صحيح.

الخطوة 5: اختبر اللقطة بينما يكون الجذر للقراءة فقط

بعد تشغيل اللقطة، تحقق من أنك تقوم بالتشغيل منها بالفعل وأن نظام الملفات الجذر للقراءة فقط:

findmnt /
mount | grep ' on / '

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

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

الخطوة 6: قم بتنفيذ عملية التراجع فقط بعد أن تجتاز اللقطة عمليات التحقق الخاصة بك

عندما تعمل اللقطة التي تم تشغيلها كما هو متوقع، اجعلها دائمة:

sudo snapper rollback

يمكنك إضافة وصف لتسهيل التعرف على اللقطة الناتجة لاحقًا:

sudo snapper rollback -d "Rollback after failed update"

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

أعد تشغيل الجهاز بعد انتهاء تنفيذ الأمر:

sudo reboot

عند إعادة التشغيل التالية، اختر إدخال SLES الافتراضي العادي بدلاً من إعادة تشغيل اللقطة القديمة للقراءة فقط.

الخطوة 7: تحقق من أن الجذر المستعاد قابل للكتابة وأنه الآن هو الجذر الافتراضي

بعد بدء التشغيل العادي، تحقق من قائمة التثبيت الجذرية وقائمة اللقطات:

findmnt /
sudo snapper list

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

الخطوة 8: تحديث المستودعات والتحقق من حالة الحزمة

لتحديث حزمة عادية، قم بتحديث المستودعات وتحقق من تبعيات الحزمة قبل محاولة تحديث آخر. أما عند التراجع عن حزمة خدمة، فإن التحقق من المستودع وتسجيل المنتج يُعدّ بالغ الأهمية، لأن عدم تطابق مجموعة المستودعات قد يُعيد النظام فورًا إلى حالة غير متناسقة.

sudo zypper ref -fs
sudo zypper lr -u
sudo zypper verify

لاستعادة حزمة الخدمة، اتبع عمليات التحقق الواردة في دليل ترقية SLES الرسمي ، والذي يدعو صراحةً إلى التحقق من تكوين المستودع وتسجيل المنتج بعد التراجع.

ما لا يُصلحه التراجع عن جذر Snapper

/homeهذا هو القيد الأهم الذي يجب فهمه قبل استخدام خاصية التراجع على خادم الإنتاج. تستثني لقطة جذر SLES الافتراضية عدة وحدات تخزين فرعية لضمان عدم استعادة البيانات المتغيرة وبيانات المستخدم أو التطبيق بشكل غير متوقع. قد تتضمن القائمة الخاصة بالمنتج مسارات /optمُحمِّل الإقلاع الخاصة بالمعمارية. راجع وثائق مفاهيم Snapper الأساسية من SUSE للاطلاع على القائمة الحالية وأسبابها./usr/local/srv/tmp/var/run

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

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

أخطاء شائعة يجب تجنبها

• التراجع قبل اختبار اللقطة. يُعد تشغيل اللقطة للقراءة فقط أولاً سير عمل SLES الأكثر أمانًا لأنه يسمح لك بالتحقق من حالة الهدف.
• اختيار لقطة ما بعد التحديث عن طريق الخطأ. تحقق من النوع والتاريخ والوصف والعلاقة بين ما قبل التحديث وما بعده بدلاً من الاعتماد على رقم اللقطة فقط.
• يُستخدم هذا undochangeالأسلوب لمعالجة حزمة كاملة من البيانات. وهو مفيد لملفات محددة؛ وتوصي SUSE بطريقة إعادة التشغيل والتراجع لاستعادة النظام بالكامل.
• توقع /varأو /homeالسفر للخلف باستخدام الجذر. استثناءات المجلدات الفرعية الافتراضية مقصودة.
• بغض النظر عن شرط الجهاز الواحد، توثق SLES 15 SP7 دعم التراجع عن نظام التشغيل الأساسي القابل للتشغيل لجهاز واحد باستخدام نظام ملفات Btrfs الأساسي.
• إعادة محاولة التحديث نفسه فوراً. أولاً، حدد سبب فشل التحديث، وتأكد من المستودعات، وحدد ما إذا كان الفشل ناتجاً عن خلل في الحزمة، أو برنامج طرف ثالث غير متوافق، أو نقص مساحة القرص، أو مشكلة في التكوين المحلي.

إذا كان النظام يستخدم التحديثات المعاملاتية

يمكن أيضًا تثبيت SLES مع دور خادم المعاملات. هذا نموذج تشغيل مختلف: تُطبَّق التحديثات على اللقطات وتُفعَّل عند إعادة التشغيل. في هذه الأنظمة، تُتيح SUSE transactional-update rollbackإمكانية تعيين لقطة كجذر افتراضي. لا تدمج وصفة استعادة خادم المعاملات في تثبيت SLES تقليدي للقراءة والكتابة دون تحديد دور النظام أولًا. يُشرح السلوك الرسمي في وثائق تحديثات المعاملات لـ SLES 15 SP7 .

قائمة التحقق من التعافي

• تأكد من أن نظام الملفات /هو Btrfs، وأن rootتكوين Snapper موجود، وأن نظام ملفات Btrfs الجذر موجود على جهاز واحد.
• حدد اللقطة التي حدثت مباشرة قبل فشل التحديث.
• استخدمها snapper statusعندما snapper diffتحتاج إلى فهم نطاق التغيير.
• يُفضل استخدام الوضع الانتقائي undochangeفقط للملفات المعزولة بوضوح.
• في حالة فشل التحديث النظامي، قم بتشغيل اللقطة المرشحة من GRUB واختبرها في وضع القراءة فقط.
• قم بتشغيل البرنامج snapper rollbackفقط بعد أن يتصرف المرشح بشكل صحيح.
• أعد تشغيل الإدخال الافتراضي العادي وتحقق من أن الجذر المستعاد قابل للكتابة.
• قم بتحديث المستودعات، وتحقق من حالة الحزمة، وتحقق من التسجيل بعد استعادة حزمة الخدمة.
• قم بمراجعة المجلدات الفرعية المستبعدة بحثًا عن أي اختلافات في التطبيق أو تنسيق البيانات قبل إعلان اكتمال عملية الاسترداد.

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