Reversão do Snapper do SLES Btrfs após uma atualização com falha: Guia de recuperação segura

Uma atualização do SLES com falha nem sempre significa que você precisa reinstalar o servidor. Em uma instalação padrão do SUSE Linux Enterprise Server que usa Btrfs como sistema de arquivos raiz e tem o Snapper habilitado, você geralmente pode inicializar um snapshot anterior à atualização, testá-lo sem alterar o sistema atual e, em seguida, tornar esse estado funcional o novo diretório raiz gravável.

A decisão importante não é simplesmente “qual snapshot é o mais recente?”, mas sim “quanto devo reverter?”. Uma reversão completa do sistema Snapper é apropriada quando uma atualização alterou vários pacotes, bibliotecas, serviços ou arquivos de configuração e a máquina deixa de funcionar de forma confiável. Se apenas um arquivo de configuração estiver com problemas, restaurá-lo geralmente causa menos transtornos. Este guia explica ambas as opções e segue o modelo de recuperação do SLES 15 SP7 documentado pela SUSE e disponível em outubro de 2026.

Escolha o método de recuperação antes de alterar qualquer coisa.

A SUSE distingue entre desfazer alterações e reverter o sistema . Desfazer alterações compara snapshots e reverte alterações selecionadas em arquivos. Uma reversão torna o estado de um snapshot a base para um novo estado raiz gravável. A SUSE recomenda especificamente inicializar o snapshot de destino primeiro ao executar uma reversão do sistema de arquivos raiz, pois isso permite verificar o estado candidato antes de confirmá-lo. Consulte o Guia de Administração do SLES 15 SP7 .

Passo 1: Confirme se este servidor suporta o caminho de reversão padrão do Snapper.

Antes de escolher um snapshot, confirme três coisas: o sistema de arquivos raiz é Btrfs, o Snapper possui uma configuração chamada `<nome_da_configuração>` root, e a raiz Btrfs está em um único dispositivo. A documentação da SUSE sobre suporte a rollback inicializável para o layout de subvolume raiz padrão afirma que o sistema de arquivos raiz Btrfs deve reportar um único dispositivo.

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

Se findmnt /o sistema de arquivos reportado for XFS ou Ext4, interrompa o processo: o fluxo de trabalho de inicialização com snapshot Btrfs não está disponível para esse diretório raiz. Se snapper list-configsnão houver nenhuma rootentrada, os snapshots automáticos do diretório raiz podem não estar habilitados. Interrompa também o processo se btrfs filesystem show /o sistema reportado contiver mais de um dispositivo; a documentação do SLES 15 SP7 não lista esse layout como compatível com o rollback do diretório raiz inicializável.

Etapa 2: Identifique o instantâneo imediatamente anterior à atualização com falha.

Liste as fotos e observe a data, o tipo, o relacionamento anterior à foto e a descrição:

sudo snapper list

Na configuração padrão do SLES, o YaST e o Zypper podem criar pares prede postsnapshots. Um presnapshot representa o estado do sistema de arquivos antes da transação; o postsnapshot correspondente representa o estado posterior. Não selecione um snapshot apenas por ser mais antigo que a falha. Certifique-se de que o carimbo de data/hora e a descrição do snapshot correspondam à janela de atualização.

Se a alteração com falha foi uma migração de pacote de serviços, o Guia de Atualização do SLES 15 SP7 da SUSE instrui especificamente os administradores a localizar o snapshot criado imediatamente antes da migração e observa que o snapshot relevante está marcado como importante.

Etapa 3: Inspecione o que o instantâneo candidato realmente mudaria.

Se o sistema atual ainda inicializar, compare o snapshot candidato com o estado atual antes de reiniciar. Isso pode revelar se a atualização afetou apenas um arquivo de configuração ou se alterou um conjunto amplo de arquivos do sistema.

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

Quando a restauração seletiva é a melhor opção

Se um arquivo conhecido estiver corrompido e o restante do sistema atualizado estiver íntegro, restaurar apenas esse arquivo evita reverter alterações não relacionadas do sistema. A SUSE documenta esse processo:

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

Não omita o nome do arquivo de forma leviana. Sem os nomes dos arquivos, undochangeé possível reverter todas as alterações feitas nos arquivos entre os dois estados. A SUSE alerta que usar a restauração de arquivos para simular um rollback completo do sistema raiz não é o método recomendado. Transações de pacotes podem alterar muitos arquivos interdependentes, portanto, um rollback completo e testado geralmente é mais fácil de avaliar quando a falha na atualização é sistêmica.

Etapa 4: Inicialize o snapshot candidato a partir do GRUB

Reinicie a máquina. No menu GRUB 2 do SLES, escolha a opção para iniciar o carregador de inicialização a partir de um snapshot somente leitura e, em seguida, selecione o snapshot que corresponde ao estado anterior à atualização. O layout exato da tela pode variar de acordo com o firmware e a configuração de inicialização, mas o SLES 15 SP7 documenta a entrada como " Iniciar o carregador de inicialização a partir de um snapshot somente leitura" .

Somente snapshots da rootconfiguração padrão do Snapper são inicializáveis ​​por meio deste mecanismo SLES. Se o menu de snapshots estiver ausente, não crie uma entrada de inicialização. Verifique novamente se o Snapper foi ativado, se o layout raiz ainda é a estrutura padrão suportada e se o carregador de inicialização instalado está funcionando.

Etapa 5: Teste o snapshot enquanto o diretório raiz estiver em modo somente leitura.

Após a inicialização do snapshot, verifique se você está realmente executando a partir dele e se o sistema de arquivos raiz está em modo somente leitura:

findmnt /
mount | grep ' on / '

Agora teste os itens que falharam após a atualização: inicialização de serviços, configuração de rede, autenticação, inicialização de aplicativos, comportamento dependente do kernel ou outras verificações relevantes. Evite tratar o snapshot somente leitura como uma inicialização normal de produção. Algumas operações falharão simplesmente porque a parte do sistema de arquivos raiz que foi capturada pelo snapshot não pode ser gravada.

Se o snapshot não for o correto, reinicie o sistema e tente outro. Até que você execute o comando de reversão, esse snapshot não terá se tornado a nova raiz gravável do sistema.

Passo 6: Confirme o rollback somente depois que o snapshot passar nas suas verificações.

Quando o snapshot inicializado se comportar como esperado, torne-o permanente:

sudo snapper rollback

Você pode adicionar uma descrição para facilitar a identificação da imagem resultante posteriormente:

sudo snapper rollback -d "Rollback after failed update"

De acordo com a documentação de administração do SLES, o Snapper cria um instantâneo do estado anterior ao rollback e cria um novo instantâneo gravável que se torna a raiz padrão. Esta é uma importante propriedade de segurança: o rollback não sobrescreve simplesmente a raiz antiga.

Reinicie após a conclusão do comando:

sudo reboot

Na próxima inicialização, escolha a entrada padrão do SLES em vez de inicializar novamente o snapshot antigo somente leitura.

Passo 7: Verifique se o diretório raiz restaurado é gravável e se agora é o padrão.

Após a inicialização normal, verifique o ponto de montagem raiz e a lista de snapshots:

findmnt /
sudo snapper list

Repita as verificações funcionais que falharam inicialmente. Se um aplicativo ainda falhar, verifique se parte desse aplicativo reside em um diretório que o snapshot raiz não incluiu.

Etapa 8: Atualize os repositórios e verifique o estado dos pacotes.

Para uma atualização de pacote comum, atualize os repositórios e verifique as dependências do pacote antes de tentar outra atualização. Para um rollback de service pack, as verificações de repositório e registro de produto são especialmente importantes, pois um conjunto de repositórios incompatível pode imediatamente colocar o sistema de volta em um estado inconsistente.

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

Para recuperação de pacotes de serviços, siga as verificações no Guia de Atualização do SLES oficial , que recomenda explicitamente a verificação da configuração do repositório e do registro do produto após o rollback.

O que um rollback root do Snapper não restaura

Esta é a limitação mais importante a ser compreendida antes de usar o rollback em um servidor de produção. O snapshot raiz padrão do SLES exclui vários subvolumes para que dados voláteis e dados de usuários ou aplicativos não sejam revertidos inesperadamente. A lista específica do produto pode incluir /home, /opt, /usr/local, /srv, /tmp, /var, /run, e caminhos de bootloader específicos da arquitetura. Consulte a documentação de conceitos básicos do Snapper da SUSE para obter a lista atual e a justificativa.

Esse design protege os dados, mas cria uma contrapartida: o código do sistema pode retroceder enquanto os dados em um subvolume excluído permanecem no estado mais recente. A SUSE destaca várias consequências possíveis, incluindo /optincompatibilidade de software de terceiros, alteração de permissões e aplicativos que deixam de entender formatos de dados gravados após a criação do snapshot.

Isso é particularmente importante para bancos de dados e aplicativos de servidor. Se uma atualização incluiu uma migração de esquema ou alterou dados do aplicativo em `/etc/systemd` /varou /srv`/etc/systemd`, um rollback raiz pode não reverter essa alteração de dados. Verifique o procedimento de downgrade ou restauração do próprio aplicativo antes de presumir que o snapshot do sistema por si só seja suficiente.

Erros comuns a evitar

• Reverter antes de testar o snapshot. Inicializar primeiro o snapshot somente leitura é o fluxo de trabalho mais seguro do SLES, pois permite verificar o estado de destino.
• Selecionar acidentalmente um instantâneo pós-atualização. Verifique o tipo, a data, a descrição e a relação pré/pós-atualização, em vez de confiar apenas no número do instantâneo.
• Utilizado undochangepara transações de pacotes completos. É útil para arquivos selecionados; a SUSE recomenda o método de inicialização e reversão para recuperação completa do sistema com privilégios de root.
• Espera /var- se /homeque o usuário percorra o caminho inverso com o root. As exclusões de subvolumes padrão são intencionais.
• Ignorando o requisito de dispositivo único. O SLES 15 SP7 documenta o suporte a rollback de raiz inicializável para uma raiz Btrfs de dispositivo único.
• Tente novamente a mesma atualização imediatamente. Primeiro, identifique por que a atualização falhou, confirme os repositórios e determine se a falha foi causada por um defeito no pacote, software de terceiros incompatível, pouco espaço em disco ou um problema de configuração local.

Se o sistema usar atualizações transacionais

O SLES também pode ser instalado com a função de Servidor Transacional. Esse é um modelo operacional diferente: as atualizações são aplicadas a snapshots e ativadas na reinicialização. Nesses sistemas, a SUSE permite transactional-update rollbackdefinir um snapshot como raiz padrão. Não misture uma receita de recuperação de servidor transacional com uma instalação convencional de leitura e gravação do SLES sem antes identificar a função do sistema. O comportamento oficial é descrito na documentação de atualizações transacionais do SLES 15 SP7 .

Lista de verificação para recuperação

• Confirme /se é Btrfs, se a rootconfiguração do Snapper existe e se o sistema de arquivos raiz Btrfs está em um dispositivo.
• Identifique o instantâneo imediatamente anterior à atualização com falha.
• Use " snapper statuse" snapper diffquando precisar entender o alcance da mudança.
• Prefira a seleção seletiva undochangeapenas para arquivos claramente isolados.
• Em caso de falha na atualização sistêmica, inicialize o snapshot candidato a partir do GRUB e teste-o em modo somente leitura.
• Execute a execução snapper rollbacksomente após o candidato se comportar corretamente.
• Reinicie a entrada padrão normal e verifique se o diretório raiz restaurado é gravável.
• Atualize os repositórios, verifique o estado dos pacotes e verifique o registro após a recuperação do pacote de serviços.
• Analise os subvolumes excluídos quanto a incompatibilidades de aplicação ou formato de dados antes de declarar a recuperação como concluída.

A principal questão é o equilíbrio entre precisão e consistência. A restauração seletiva de arquivos altera menos, mas exige que você saiba exatamente o que falhou. Um rollback de sistema testado altera mais, mas restaura um estado raiz coerente, obtido por meio de um snapshot, e é a melhor opção para uma atualização com falha que afetou vários componentes. No SLES, o fluxo de trabalho mais seguro é usar a inicialização por snapshot somente leitura como ponto de decisão, em vez de tornar o rollback irreversível antes de verificar a solução.