Reverter com segurança uma atualização do SLES com falha usando o Snapper.

Em uma instalação padrão do SUSE Linux Enterprise Server (SLES) com raiz Btrfs e Snapper habilitado, a recuperação mais segura é inicializar a partir de um snapshot criado antes da atualização com falha, testá-lo enquanto estiver em modo somente leitura e, em seguida, executar o comando sudo snapper rollback. Isso cria uma nova raiz gravável a partir do estado testado; não restaura todos os discos, subvolumes ou bancos de dados de aplicativos.

As diretrizes de administração atuais do SLES 15 SP7 ainda utilizam esse fluxo de trabalho de inicialização e teste. Antes de segui-lo, confirme se a máquina atende ao layout de reversão suportado pela SUSE e identifique o snapshot anterior à transação Zypper ou YaST com falha.

Um rollback do Snapper restaurará todo o servidor?

Não. O rollback do sistema inicializável se aplica a snapshots na rootconfiguração padrão do Snapper. A SUSE documenta o suporte para o arranjo padrão de subvolumes raiz, com Btrfs em um único dispositivo raiz e um carregador de inicialização instalado e funcionando. O rollback altera o conteúdo do subvolume `/var/lib/snapshot` /; outros subvolumes não são incluídos. Em layouts típicos do SLES, caminhos como /var`/ /srvvar/ /optlib /snapshot` /usr/local, ... e `/var/lib/snapshot` geralmente /homeestão fora do snapshot. Um banco de dados ou serviço pode, portanto, reter dados gravados após o snapshot, mesmo que seus pacotes de sistema sejam revertidos.

Faça ou verifique um backup separado dos dados importantes do aplicativo antes de confirmar o rollback. Evite também este procedimento se você alterou o layout padrão do subvolume Btrfs ou usa um sistema raiz com vários dispositivos: os requisitos de rollback inicializável documentados para o SLES 15 SP7 não abrangem essas configurações. Leia os requisitos de recuperação do Snapper da SUSE antes de prosseguir.

Qual captura de tela foi feita antes da atualização falhar?

Utilize a configuração do Snapper para o sistema de arquivos raiz e compare o par pré/pós da transação. Em um sistema SLES típico com snapshots de raiz Btrfs habilitados, o Zypper e o YaST criam snapshots em torno das operações de pacotes. O snapshot pré representa o estado da raiz antes da operação; o snapshot pós representa o estado após a execução, incluindo uma transação parcialmente falha.

1. Verifique se a configuração raiz existe com sudo snapper list-configs. Procure por uma configuração chamada root.
2. Confirme o tipo do sistema de arquivos raiz com findmnt -no FSTYPE /. Para este procedimento de reversão inicializável, ele deve retornar btrfs. Em seguida, execute sudo btrfs filesystem show /e confirme se o sistema de arquivos raiz retorna Total devices 1.
3. Liste os pares de transações com sudo snapper -c root list -t pre-post. Associe a data e a descrição à atualização com falha. Registre o número na Pre #coluna, não o par Post #.
4. Analise o que mudou entre os dois. Substitua <número> PREe POST<número> pelos números exibidos na sua máquina:

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

Esses comandos listam os caminhos alterados e as diferenças nos arquivos. Os números de snapshot, datas, descrições de pacotes e saídas variam de acordo com o host; não copie um número de exemplo de uma captura de tela. Se nenhum par relevante aparecer, verifique se o Snapper está habilitado e se uma política de limpeza já removeu o snapshot. Um snapshot ausente não pode ser recriado pelo Snapper posteriormente.

Como testar a raiz antiga antes de torná-la permanente?

Reinicie e use a entrada de snapshot do carregador de inicialização. No SLES, escolha `SES` Start Bootloader from a read-only snapshot, depois selecione o snapshot com a data imediatamente anterior à transação com falha. O menu de inicialização rotula as entradas com sua data e descrição, que podem incluir zypp(zypper)uma operação do YaST. Escolha o snapshot pré-atualização que você gravou; não selecione o snapshot pós-atualização apenas porque sua descrição é mais fácil de reconhecer.

Faça login e teste os serviços ou aplicativos que apresentaram falhas. Os arquivos raiz do snapshot são somente leitura durante este período de teste, portanto, esta inicialização por si só não altera a raiz padrão. Se o snapshot estiver incorreto ou se o sistema ainda apresentar falhas, reinicie e tente outro snapshot ou use o sistema de recuperação. Não force um rollback apenas para tornar a opção do menu permanente.

Quando você deve executar o snapper rollback?

Execute o rollback somente depois que o snapshot anterior inicializar e passar nas suas verificações. A partir desse snapshot somente leitura, execute:

sudo snapper rollback

Em seguida, reinicie e escolha a entrada de inicialização padrão normal:

sudo reboot

O Snapper preserva um instantâneo do estado do sistema antes do rollback e cria uma nova raiz de leitura e gravação com base no instantâneo testado. Você não deve passar o número do instantâneo antigo para este comando no fluxo de trabalho documentado de inicialização a partir de um instantâneo. O resultado é uma nova raiz padrão, não uma conversão gravável do próprio instantâneo somente leitura. Os instantâneos podem ser removidos posteriormente por regras de limpeza, portanto, copie todos os arquivos necessários antes de usar um instantâneo de rollback antigo como um arquivo de longo prazo.

O que você deve verificar após reiniciar?

Inicie o sistema com a entrada padrão e verifique a recuperação propriamente dita, não apenas a conclusão do comando. Confirme o estado esperado do kernel e dos pacotes, revise o status e os logs do serviço com falha e execute uma pequena verificação em nível de aplicativo. Em seguida, inspecione o novo estado do Snapper:

sudo snapper -c root list

Para uma atualização de pacote comum, isso geralmente é suficiente para confirmar que a máquina inicializa a partir do novo diretório raiz. Se a operação com falha foi uma migração de service pack , siga também as verificações pós-rollback da SUSE: atualize e inspecione os repositórios e, em seguida, verifique o registro.

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

Os repositórios devem corresponder ao service pack para o qual você retornou e os produtos instalados devem estar registrados. Se o registro não for restaurado, consulte o procedimento de reversão do service pack do SUSE SLES 15 SP7sudo SUSEConnect --rollback como etapa de reparo. Esse comando de registro é específico para recuperação de migração; não o execute para uma atualização de pacote de rotina.

Se este host utiliza transactional-update(por exemplo, um sistema SLE Micro transacional), siga o procedimento desse produto em vez de aplicar a sequência de comandos clássica do SLES. A documentação do produto utiliza o comando `snapshot` para selecionar um snapshot do sistema em execução e um fluxo de trabalho separado para inicialização com snapshot somente leitura quando a raiz atual estiver corrompida. Consulte as instruções de reversão de atualização transacionalsudo transactional-update rollback SNAPSHOT_NUMBER da SUSE .