Gestión de entornos de arranque ZFS con beadm y reversión de una actualización fallida

Objetivo

Listar, crear, activar y destruir entornos de arranque (BE, por sus siglas en inglés) ZFS en Oracle Solaris 11.4, y usarlos para recuperar un host tras un pkg update que salió mal.

Requisitos previos

El rol root o un perfil asignado con derechos para gestionar entornos de arranque; un pool raíz ZFS, que los BE requieren y que es la disposición de raíz predeterminada y la única admitida en 11.4.

Pasos

1. Lista lo que existe: beadm list muestra todos los entornos de arranque, cuál está activo ahora, cuál lo estará en el próximo arranque y cuánto espacio usa cada uno.
2. Crea un BE manualmente antes de un cambio manual arriesgado: beadm create <new-be-name> clona el BE en ejecución sin tocar el sistema que está funcionando. Ten en cuenta las dos formas con snapshot: beadm create <be-name>@<snapshot> solo toma un snapshot de un BE existente, mientras que beadm create -e <be-name>@<snapshot> <new-be-name> crea un BE nuevo a partir de ese snapshot.
3. Deja que pkg cree uno automáticamente: como se describe en el artículo sobre IPS de esta serie, pkg update crea y activa un BE nuevo cuando la actualización afecta a paquetes que requieren reinicio (toda actualización SRU lo hace), según la propiedad be-policy de la imagen; las operaciones que no requieren reinicio modifican el BE en ejecución, a lo sumo con un BE de respaldo.
4. Activa un BE para que arranque la próxima vez: beadm activate <be-name>. Esto no reinicia el host; el BE en ejecución sigue funcionando hasta el siguiente reinicio.
5. Reinicia para cambiar realmente al BE recién activado y confirma con beadm list que ahora es el activo en ejecución.
6. Si el nuevo BE está dañado pero aún arranca: ejecuta beadm activate <previous-be-name> y reinicia de nuevo. Si no arranca en absoluto, beadm no puede ejecutarse dentro de él: selecciona en su lugar el BE anterior durante el arranque (desde el menú GRUB en x86, o con boot -L en el prompt ok en SPARC) y, una vez iniciado el sistema, ejecuta beadm activate <previous-be-name> para que los reinicios posteriores no vuelvan al BE dañado.
7. Limpia cuando confíes en el resultado: beadm destroy <be-name> elimina un entorno de arranque que ya no necesitas, junto con todos sus snapshots; pide confirmación (-F omite el aviso) y no puede eliminar el BE que estás usando.

Resultado esperado

Tras beadm activate y un reinicio, beadm list muestra el BE de destino como activo y el host ejecuta el software que ese BE contiene; un BE destruido ya no aparece en la lista y su espacio queda liberado.

Límites y base de verificación

Activar un BE anterior y reiniciar es la reversión admitida para un pkg update fallido; no hace falta reinstalar paquetes manualmente. Conserva al menos el BE anterior hasta que el nuevo esté verificado en producción; beadm destroy no se puede deshacer, salvo restaurando desde una copia de seguridad del pool. Como los BE comparten el pool raíz, destruir los antiguos también es la forma de recuperar espacio si pkg update se rechaza por falta de él. Una reversión solo revierte los datasets propios del BE (el sistema de archivos raíz y /var); los datasets compartidos, como /export/home o /var/share, no se revierten, por lo que los datos escritos allí después de la actualización permanecen. Esto cubre Oracle Solaris 11.4; los sistemas basados en illumos que usan entornos de arranque ZFS siguen el mismo patrón de activar, reiniciar y revertir, aunque los nombres de las herramientas y sus opciones pueden diferir.