Gerenciando boot environments ZFS com beadm e revertendo uma atualização que falhou

Objetivo

Listar, criar, ativar e destruir boot environments (BEs) ZFS no Oracle Solaris 11.4 e usá-los para recuperar um host depois de um pkg update que deu errado.

Pré-requisitos

Papel root ou um perfil atribuído com direitos para gerenciar boot environments; um pool raiz ZFS, exigido pelos BEs e que é o layout de raiz padrão e o único suportado no 11.4.

Passos

1. Liste o que existe: beadm list mostra todos os boot environments, qual está ativo agora, qual estará ativo no próximo boot e o espaço que cada um ocupa.
2. Crie um BE manualmente antes de uma alteração manual arriscada: beadm create <new-be-name> clona o BE em execução sem alterar o sistema em funcionamento. Observe as duas formas com snapshot: beadm create <be-name>@<snapshot> apenas tira um snapshot de um BE existente, enquanto beadm create -e <be-name>@<snapshot> <new-be-name> cria um novo BE a partir desse snapshot.
3. Deixe o pkg criar um automaticamente: conforme descrito no artigo sobre o IPS desta série, o pkg update cria e ativa um novo BE quando a atualização afeta pacotes que exigem reinicialização (toda atualização SRU exige), de acordo com a propriedade be-policy da imagem; operações que não exigem reinicialização alteram o BE em execução, no máximo com a criação de um BE de backup.
4. Ative um BE para que ele seja usado no próximo boot: beadm activate <be-name>. Isso não reinicia o host; o BE em execução continua em execução até a próxima reinicialização.
5. Reinicie para de fato passar ao BE recém-ativado e confirme com beadm list que ele agora é o BE ativo atual.
6. Se o novo BE estiver com defeito, mas ainda iniciar: execute beadm activate <previous-be-name> e reinicie novamente. Se ele não iniciar de jeito nenhum, o beadm não pode ser executado dentro dele: selecione o BE anterior durante o boot — pelo menu do GRUB em x86 ou com boot -L no prompt ok em SPARC — e, depois de iniciado, execute beadm activate <previous-be-name> para que as reinicializações seguintes não voltem ao BE com defeito.
7. Faça a limpeza quando confiar no resultado: beadm destroy <be-name> remove um boot environment que não é mais necessário, junto com todos os seus snapshots; ele pede confirmação (-F dispensa a pergunta) e não consegue remover o BE que você está usando.

Resultado esperado

Depois de beadm activate e de uma reinicialização, beadm list mostra o BE de destino como ativo e o host executando o software contido nesse BE; um BE destruído deixa de aparecer na lista e seu espaço é recuperado.

Limites e base de verificação

Ativar um BE anterior e reiniciar é a reversão suportada para um pkg update malsucedido — não é preciso reinstalar pacotes manualmente. Mantenha pelo menos o BE anterior até que o novo seja verificado em produção; o beadm destroy não pode ser desfeito, a não ser restaurando a partir de um backup do pool. Como os BEs compartilham o pool raiz, destruir os antigos também é a maneira de recuperar espaço quando o pkg update é recusado por falta de espaço. Uma reversão desfaz apenas os datasets próprios do BE (sistema de arquivos raiz e /var); datasets compartilhados, como /export/home ou /var/share, não são revertidos, então os dados gravados ali depois da atualização permanecem. Isto vale para o Oracle Solaris 11.4; sistemas baseados em illumos que usam boot environments ZFS seguem o mesmo padrão de ativar, reiniciar e reverter, embora os nomes das ferramentas e as opções possam diferir.