Revierte de forma segura una actualización fallida de SLES con Snapper.

En una instalación estándar de SUSE Linux Enterprise Server (SLES) con un sistema de archivos raíz Btrfs y Snapper habilitado, la recuperación más segura consiste en arrancar una instantánea creada antes de la actualización fallida, probarla en modo de solo lectura y, a continuación, ejecutar sudo snapper rollback. Esto crea un nuevo sistema de archivos raíz con permisos de escritura a partir del estado probado; no revierte todos los discos, subvolúmenes ni bases de datos de aplicaciones.

La guía de administración actual de SLES 15 SP7 aún utiliza este flujo de trabajo de arranque y prueba. Antes de seguirlo, confirme que la máquina cumple con el esquema de reversión compatible con SUSE e identifique la instantánea previa de la transacción fallida de Zypper o YaST.

¿Una reversión de Snapper restaurará todo el servidor?

No. La reversión del sistema de arranque se aplica a las instantáneas en la rootconfiguración predeterminada de Snapper. SUSE documenta la compatibilidad con la disposición predeterminada del subvolumen raíz, con Btrfs en un único dispositivo raíz y un cargador de arranque instalado y en funcionamiento. La reversión cambia el contenido del subvolumen /; otros subvolúmenes no se incluyen. En diseños típicos de SLES, las rutas como /var, /srv, /opt, /usr/local, y a menudo /homeestán fuera de la instantánea. Por lo tanto, una base de datos o un servicio puede conservar datos escritos después de la instantánea incluso cuando sus paquetes del sistema vuelven a la versión anterior.

Realice o verifique una copia de seguridad independiente de los datos importantes de la aplicación antes de realizar una reversión. Evite este procedimiento si modificó la configuración predeterminada del subvolumen Btrfs o si utiliza una raíz de varios dispositivos: los requisitos de reversión de arranque documentados de SLES 15 SP7 no cubren estas configuraciones. Lea los requisitos de recuperación de Snapper de SUSE antes de continuar.

¿Qué instantánea se creó antes de la actualización fallida?

Utilice la configuración de Snapper para el sistema de archivos raíz y compare el par pre/post de la transacción. En un sistema SLES típico con instantáneas de raíz Btrfs habilitadas, Zypper y YaST crean instantáneas en torno a las operaciones de paquetes. La instantánea pre representa el estado de la raíz antes de la operación; la instantánea post representa el estado después de su ejecución, incluyendo una transacción parcialmente fallida.

1. Compruebe que la configuración raíz existe con sudo snapper list-configs. Busque una configuración llamada root.
2. Confirme el tipo de sistema de archivos raíz con findmnt -no FSTYPE /. Para este procedimiento de reversión de arranque debería informar btrfs. Luego ejecute sudo btrfs filesystem show /y confirme que el sistema de archivos raíz informa Total devices 1.
3. Enumere los pares de transacciones con sudo snapper -c root list -t pre-post. Haga coincidir la fecha y la descripción con la actualización fallida. Registre el número en la Pre #columna, no el par Post #.
4. Revisa qué cambió entre ambos. Reemplaza PREy POSTcon los números que aparecen en tu máquina:

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

Estos comandos muestran las rutas modificadas y las diferencias en los archivos. Los números de instantánea, las fechas, las descripciones de los paquetes y la salida varían según el host; no copie un número de ejemplo de una captura de pantalla. Si no aparece ningún par relevante, compruebe si Snapper está habilitado y si una política de limpieza ya eliminó la instantánea. Snapper no puede recrear una instantánea que falta.

¿Cómo se prueba la raíz antigua antes de hacerla permanente?

Reinicia y usa la entrada de instantánea del cargador de arranque. En SLES, elige Start Bootloader from a read-only snapshoty luego selecciona la instantánea con fecha inmediatamente anterior a la transacción fallida. El menú de arranque etiqueta las entradas con su fecha y descripción, que puede incluir zypp(zypper)o una operación de YaST. Elige la instantánea previa a la actualización que registraste; no selecciones la instantánea posterior solo porque su descripción sea más fácil de reconocer.

Inicie sesión y pruebe los servicios o aplicaciones que fallaron. Los archivos raíz de la instantánea son de solo lectura durante esta prueba, por lo que este arranque por sí solo no cambia la raíz predeterminada. Si la instantánea es incorrecta o el sistema sigue fallando, reinicie y pruebe con otra instantánea o utilice el sistema de recuperación. No fuerce una reversión solo para que la opción del menú sea permanente.

¿Cuándo se debe ejecutar el retroceso de Snapper?

Ejecuta la reversión solo después de que la instantánea anterior se inicie y supere tus comprobaciones. Desde esa instantánea de solo lectura, ejecuta:

sudo snapper rollback

Luego, reinicie y elija la entrada de arranque predeterminada normal:

sudo reboot

Snapper conserva una instantánea del estado del sistema anterior a la reversión y crea una nueva raíz de lectura y escritura basada en la instantánea probada. No se debe pasar el número de instantánea anterior a este comando en el flujo de trabajo documentado de arranque desde instantánea. El resultado es una nueva raíz predeterminada, no una conversión con permisos de escritura de la instantánea de solo lectura. Las instantáneas pueden eliminarse posteriormente mediante reglas de limpieza, por lo que se recomienda copiar los archivos necesarios antes de utilizar una instantánea de reversión anterior como archivo a largo plazo.

¿Qué debes verificar después de reiniciar?

Inicie la entrada predeterminada y verifique la recuperación real, no solo la finalización del comando. Confirme el estado esperado del kernel y del paquete, revise el estado y los registros del servicio fallido y ejecute una pequeña verificación a nivel de aplicación. Luego, inspeccione el nuevo estado de Snapper:

sudo snapper -c root list

Para una actualización de paquete normal, esto suele ser suficiente para confirmar que la máquina arranca desde la nueva raíz. Si la operación fallida fue una migración de paquete de servicio , siga también las comprobaciones posteriores a la reversión de SUSE: actualice e inspeccione los repositorios y, a continuación, compruebe el registro:

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

Los repositorios deben coincidir con el Service Pack al que se regresó, y los productos instalados deben estar registrados. Si no se restablece el registro, el procedimiento de reversión del Service Pack SLES 15 SP7 de SUSE documenta sudo SUSEConnect --rollbackeste paso de reparación. Este comando de registro es específico para la recuperación de la migración; no lo ejecute para una actualización de paquete rutinaria.

Si este host utiliza transactional-update(por ejemplo, un sistema SLE Micro transaccional), siga el procedimiento de ese producto en lugar de aplicar la secuencia de comandos SLES clásica. Su documentación utiliza sudo transactional-update rollback SNAPSHOT_NUMBERpara seleccionar una instantánea del sistema en ejecución y un flujo de trabajo de instantánea de solo lectura de arranque independiente cuando la raíz actual está dañada. Consulte las instrucciones de reversión de actualización transaccional de SUSE .