Snapper: snapshots e recuperação controlada no Linux

Atualizações são necessárias, mas nem sempre produzem o resultado esperado. Um pacote pode mudar uma configuração, uma dependência pode alterar o comportamento de um serviço ou uma atualização do sistema pode revelar um problema apenas depois da reinicialização.

É nesse momento que o Snapper se torna uma ferramenta muito útil. Ele administra snapshots, especialmente em sistemas de arquivos Btrfs, e cria uma forma organizada de acompanhar estados do sistema antes e depois de mudanças.

O que é o Snapper

O Snapper é um gerenciador de snapshots. Ele não é um sistema de arquivos e não substitui o Btrfs; trabalha sobre uma configuração de subvolume e usa os recursos disponíveis para criar, listar, comparar, apagar e, em situações compatíveis, restaurar estados anteriores.

Em uma instalação openSUSE, por exemplo, o gerenciador de pacotes pode criar snapshots antes e depois de determinadas operações. Assim, uma atualização deixa de ser apenas uma sequência de pacotes modificados e passa a ter pontos de comparação.

O recurso depende do layout da máquina. Um snapshot da raiz pode não incluir /home, bancos de dados em outros volumes ou dados armazenados fora do subvolume configurado. Antes de confiar em um rollback, preciso saber exatamente o que está sendo protegido.

Snapshots antes e depois de uma mudança

Uma configuração do Snapper pode manter snapshots numerados e descritos. O primeiro representa o estado antes de uma alteração; o segundo, o estado depois dela.

Para consultar a configuração root, posso usar:

sudo snapper -c root list

Também posso criar um ponto manual antes de uma alteração importante:

sudo snapper -c root create --description "Antes da atualização do sistema"

A descrição é parte da manutenção. Um snapshot com uma finalidade clara é muito mais útil meses depois do que uma sequência de números sem contexto.

Entendendo o que mudou

O Snapper permite comparar dois snapshots. O comando status mostra arquivos criados, removidos ou alterados, enquanto diff ajuda a examinar o conteúdo das diferenças:

sudo snapper -c root status 120..121
sudo snapper -c root diff 120..121

Essa comparação é uma etapa importante antes de desfazer qualquer coisa. Em vez de restaurar cegamente um estado antigo, posso verificar se a mudança problemática realmente está naquele intervalo e se o rollback não vai remover uma correção aplicada depois.

Quando a alteração é localizada e o objetivo é desfazer apenas aquele conjunto, existe a possibilidade de usar:

sudo snapper -c root undochange 120..121

Esse comando deve ser usado com atenção e, de preferência, depois de revisar o diff. Recuperação segura começa por entender o que será alterado.

Rollback do sistema

Em um sistema preparado para isso, um snapshot anterior pode servir de base para um rollback da raiz. O comportamento exato depende da distribuição, do bootloader, dos subvolumes e da forma como o sistema foi instalado.

Antes de testar, verifico a documentação da distribuição e confirmo se /boot, /home, bancos de dados e arquivos de configuração externos ao subvolume também serão tratados. Restaurar apenas a raiz pode deixar partes do ambiente em estados diferentes.

Um rollback também não deve ser a primeira resposta para qualquer problema. Se a causa pode ser corrigida com uma alteração pequena, é preferível entender a diferença e desfazer somente o necessário. O rollback amplo faz sentido quando o estado anterior é conhecido e o conjunto de mudanças realmente precisa ser revertido.

Retenção e limpeza

Snapshots ocupam pouco espaço no início, mas preservam blocos antigos conforme os arquivos mudam. Uma máquina atualizada diariamente pode acumular muitos estados e consumir espaço sem que isso seja evidente de imediato.

Por isso, configuro políticas de retenção e acompanho o uso do volume. A limpeza manual pode ser feita com um comando como:

sudo snapper -c root cleanup number

O nome do tipo de limpeza depende da configuração existente. Antes de remover snapshots, verifico se há algum ponto marcado como importante para uma recuperação em andamento e se os backups externos estão atualizados.

Reter snapshots indefinidamente não é uma política de segurança. É preciso definir quantos estados recentes são necessários, por quanto tempo manter referências mensais e quando uma cópia antiga deixa de ter valor operacional.

Segurança dos snapshots

Um snapshot herda o conteúdo e, em grande parte, as permissões do estado original. Se uma chave privada, senha ou token foi salvo no sistema, a versão pode continuar disponível em um snapshot mesmo depois de o arquivo ter sido apagado da árvore atual.

Isso tem consequências importantes:

1. Snapshots não devem ser tratados como uma área segura para guardar segredos.
2. Credenciais que podem ter sido expostas precisam ser revogadas ou rotacionadas.
3. O acesso aos comandos do Snapper deve ser restrito a administradores confiáveis.
4. A retenção precisa considerar privacidade e requisitos de descarte, não apenas capacidade.

O Snapper também não impede que uma atualização maliciosa ou um usuário com privilégios administrativos altere o sistema. Ele oferece recuperação operacional, não uma fronteira de segurança. Atualizações, menor privilégio, criptografia de disco e monitoramento continuam necessários.

Snapshot não é backup

O Snapper normalmente mantém seus snapshots no mesmo volume do sistema. Uma falha no disco, um erro grave no controlador ou um problema que torne o volume inacessível pode levar junto o estado atual e todos os snapshots.

Para dados importantes, mantenho uma cópia independente. O Btrfs send e receive, ferramentas tradicionais de backup ou uma solução remota podem ser usados conforme o cenário. O essencial é ter outro dispositivo ou local, versões úteis e restaurações testadas.

Também separo a recuperação do sistema da proteção dos dados pessoais. Voltar a uma configuração anterior é diferente de restaurar documentos, fotos, bancos de dados e chaves que precisam continuar existindo.

Uma rotina que faz sentido

Antes de uma atualização relevante, confirmo espaço livre, backup recente e funcionamento dos serviços essenciais. Crio um snapshot descritivo quando a operação não gerar um automaticamente.

Depois da atualização, verifico logs, rede, armazenamento e aplicações. Se algo falhar, comparo os snapshots e identifico a menor mudança que resolve o problema. Só então decido entre corrigir manualmente, desfazer uma alteração ou fazer um rollback completo.

Em seguida, removo snapshots que já não precisam ser mantidos e registro a solução. A ferramenta é mais valiosa quando faz parte de um processo repetível, e não quando fica esquecida até uma emergência.

Minha conclusão

O Snapper transforma snapshots do Btrfs em uma ferramenta prática de manutenção. Ele ajuda a visualizar mudanças, recuperar configurações e reduzir o risco operacional de atualizações importantes.

Seu uso seguro exige conhecer o layout do sistema, revisar diferenças, controlar a retenção e manter backups fora do volume. Snapshot não é backup e rollback não é uma forma de apagar o histórico de um segredo. Com essas limitações claras, o Snapper oferece uma camada de recuperação rápida e bem mais organizada do que tentar reconstruir o estado anterior apenas pela memória.