Crie rollbacks instantâneos com subvolumes btrfs e snapper

Configurar subvolumes btrfs e snapper no Linux é a melhor garantia contra atualizações desastrosas, falhas de driver e alterações de sistema mal-sucedidas. Quando atualizamos pacotes críticos em distribuições modernas como o Debian 13.7 ou o Ubuntu 26.04.1, qualquer inconsistência no kernel ou nos módulos do sistema pode impedir a inicialização. Em vez de recorrer a mídias externas de resgate ou reinstalações demoradas, o uso correto do Btrfs permite reverter todo o sistema operacional ao seu estado funcional anterior em poucos segundos.

O grande diferencial do Btrfs em relação a sistemas de arquivos tradicionais como o ext4 é o suporte nativo a Copy-On-Write (COW). Quando um arquivo é modificado, o Btrfs não sobrescreve os blocos existentes; em vez disso, ele escreve os novos dados em um espaço livre do disco e atualiza os ponteiros da arvore de arquivos. Isso significa que criar um snapshot nada mais é do que capturar uma foto estática dessa estrutura de ponteiros. O processo é instantâneo e ocupa zero espaço adicional no momento da criação.

Contudo, criar snapshots sem um planejamento prévio da estrutura de subvolumes cria armadilhas sérias. Se a sua partição raiz contiver diretórios como /home, /var/log ou /var/lib/libvirt sem o devido isolamento, realizar um rollback da raiz fará você perder documentos recentes, logs de auditoria e até imagens de máquinas virtuais. Neste guia, vamos definir a topologia ideal de subvolumes e automatizar backups de estado com o Snapper.

Por que o layout padrão do instalador quebra o rollback de sistema?

A maioria dos instaladores gráficos de distribuições Linux cria um layout de subvolumes extremamente simplificado, geralmente limitando-se a um subvolume @ para a raiz e um subvolume @home para o diretório dos usuários. Embora essa separação seja suficiente para isolar arquivos pessoais de arquivos do sistema operacional, ela falha miseravelmente quando precisamos realizar um rollback completo do sistema usando ferramentas automatizadas como o Snapper.

O principal problema do layout aninhado ou simplista é a poluição de estados voláteis. Quando você restaura a raiz do sistema para um ponto do tempo criado há dois dias, tudo o que estava gravado no diretório do sistema é substituído. Se diretórios como /var/log, /var/cache ou /var/tmp estiverem dentro do subvolume raiz @, você perderá o histórico de depuração necessário para entender o motivo pelo qual o sistema quebrou em primeiro lugar.

Outro ponto crítico diz respeito ao banco de dados interno de gerenciadores de pacotes e contêineres. Se a pasta /var/lib/docker ou /var/lib/flatpak estiver aninhada no subvolume raiz sem ser um subvolume separado, a restauração da raiz provocará uma dessincronização grave entre as imagens registradas e o estado atual dos arquivos em disco. O Snapper exige um layout plano (flat subvolume layout) para funcionar com eficiência, no qual cada diretório de estado independente possui seu próprio subvolume montado em tempo de execução.

Por fim, a pasta onde o próprio Snapper armazena seus metadados e snapshots, localizada em /.snapshots, não pode residir dentro do subvolume raiz @. Se /.snapshots estiver dentro de @, ao restaurar um snapshot antigo de @, você estará substituindo a própria pasta de snapshots pela versão antiga, perdendo todos os snapshots criados entre aquele momento do passado e o presente. A solução é transformar /.snapshots em um subvolume Btrfs independente.

Como organizar o layout de subvolumes btrfs e snapper para rollbacks?

Para garantir que os rollbacks funcionem perfeitamente sem colaterais indesejados, devemos adotar o padrão de subvolumes planos. Nessa abordagem, todos os subvolumes são criados diretamente na raiz do sistema de arquivos Btrfs (o subvolume ID 5) e montados individualmente na arvore de diretórios da distribuição durante o boot pelo arquivo /etc/fstab.

Abaixo está a estrutura recomendada de subvolumes para uma instalação robusta e resiliente:

• @: subvolume montado no ponto de montagem / (raiz do sistema).
• @home: subvolume montado em /home para preservar os dados dos usuários.
• @snapshots: subvolume montado em /.snapshots para armazenar a árvore de snapshots gerenciada pelo Snapper.
• @log: subvolume montado em /var/log para garantir a integridade dos logs do sistema após o rollback.
• @cache: subvolume montado em /var/cache para evitar o download duplicado de pacotes de repositórios.
• @tmp: subvolume montado em /var/tmp para isolar arquivos temporários de longa duração.

Ao manter essa divisão rigorosa, qualquer operação de rollback afeta exclusivamente os arquivos executáveis do sistema, as bibliotecas em /usr, as configurações em /etc e o núcleo em /boot. Os dados de usuários e logs permanecem intactos.

A tabela a seguir resume as responsabilidades e os comportamentos de cada subvolume durante um evento de restauração de sistema:

Como criar a estrutura de subvolumes no terminal passo a passo?

Se você está realizando uma instalação limpa ou reestruturando um disco secundário pelo terminal, o procedimento de criação dos subvolumes deve ser executado logo após a formatação da partição com o sistema de arquivos Btrfs. Supondo que a sua partição formatada seja /dev/sda2, comece montando o subvolume do nível mais alto (ID 5) em um diretório provisório como /mnt.

Abra um terminal com privilégios de superusuário e execute os comandos de criação dos subvolumes de forma sequencial:

mount /dev/sda2 /mnt

btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@home
btrfs subvolume create /mnt/@snapshots
btrfs subvolume create /mnt/@log
btrfs subvolume create /mnt/@cache
btrfs subvolume create /mnt/@tmp

umount /mnt

Com os subvolumes devidamente criados, o próximo passo é realizar a montagem organizada da árvore de diretórios antes de instalar o sistema operacional ou migrar os arquivos. Primeiro, montamos o subvolume raiz @ no ponto /mnt e criamos os diretórios de destino para os demais subvolumes:

mount -o noatime,compress=zstd:1,space_cache=v2,subvol=@ /dev/sda2 /mnt

mkdir -p /mnt/{home,.snapshots,var/log,var/cache,var/tmp}

mount -o noatime,compress=zstd:1,space_cache=v2,subvol=@home /dev/sda2 /mnt/home
mount -o noatime,compress=zstd:1,space_cache=v2,subvol=@snapshots /dev/sda2 /mnt/.snapshots
mount -o noatime,compress=zstd:1,space_cache=v2,subvol=@log /dev/sda2 /mnt/var/log
mount -o noatime,compress=zstd:1,space_cache=v2,subvol=@cache /dev/sda2 /mnt/var/cache
mount -o noatime,compress=zstd:1,space_cache=v2,subvol=@tmp /dev/sda2 /mnt/var/tmp

Note a presença das opções de montagem recomendadas para Btrfs em dispositivos SSD e NVMe modernos. A opção compress=zstd:1 ativa a compressão transparente em tempo real com uso insignificante de CPU, reduzindo o consumo de espaço em disco e estendendo a vida útil da memória flash. A opção noatime evita operações desnecessárias de escrita de metadados a cada leitura de arquivo.

Para que o sistema monte essa estrutura automaticamente em cada inicialização, edite o arquivo /etc/fstab da máquina montada garantindo que os parâmetros de UUID e subvolumes fiquem mapeados corretamente:

UUID=4a2b3c4d-1234-5678-9abc-def012345678 /              btrfs subvol=@,noatime,compress=zstd:1,space_cache=v2 0 0
UUID=4a2b3c4d-1234-5678-9abc-def012345678 /home          btrfs subvol=@home,noatime,compress=zstd:1,space_cache=v2 0 0
UUID=4a2b3c4d-1234-5678-9abc-def012345678 /.snapshots    btrfs subvol=@snapshots,noatime,compress=zstd:1,space_cache=v2 0 0
UUID=4a2b3c4d-1234-5678-9abc-def012345678 /var/log       btrfs subvol=@log,noatime,compress=zstd:1,space_cache=v2 0 0
UUID=4a2b3c4d-1234-5678-9abc-def012345678 /var/cache     btrfs subvol=@cache,noatime,compress=zstd:1,space_cache=v2 0 0
UUID=4a2b3c4d-1234-5678-9abc-def012345678 /var/tmp       btrfs subvol=@tmp,noatime,compress=zstd:1,space_cache=v2 0 0

Como configurar o Snapper e desativar o snapshot da raiz?

O Snapper é o utilitário oficial mantido pela SUSE para gerenciar snapshots Btrfs de forma automatizada. Ele permite criar rotinas cronológicas de retenção (por hora, dia ou mês) e integrar a criação de snapshots antes e depois de cada transação do gerenciador de pacotes (como apt ou zypper).

Após instalar o pacote snapper na sua distribuição, a tentativa imediata de gerar a configuração padrão para o diretório raiz causará um erro se o diretório /.snapshots já existir como um ponto de montagem. O comando padrão do Snapper tenta criar um subvolume próprio dentro do diretório, o que quebra nossa arquitetura plana.

Para contornar esse comportamento e forçar o uso do nosso subvolume @snapshots, siga o procedimento correto no terminal:

umount /.snapshots
rmdir /.snapshots

snapper -c root create-config /

btrfs subvolume delete /.snapshots
mkdir /.snapshots

mount -a
chmod 750 /.snapshots

Com esse fluxo, dizemos ao Snapper para registrar a configuração do perfil root, mas descartamos o subvolume aninhado que ele tentou criar automaticamente, re-montando o subvolume @snapshots que definimos no /etc/fstab.

Agora, precisamos ajustar a política de retenção para evitar que o disco fique lotado com centenas de cópias antigas do sistema. Abra o arquivo de configuração do perfil recém-criado em /etc/snapper/configs/root e modifique os limites numéricos conforme o exemplo abaixo:

SUBVOLUME="/"
FSTYPE="btrfs"

ALLOW_GROUPS="wheel sudo"
NUMBER_CLEANUP="yes"
NUMBER_LIMIT="10"
NUMBER_LIMIT_IMPORTANT="5"

TIMELINE_CREATE="yes"
TIMELINE_CLEANUP="yes"

TIMELINE_LIMIT_HOURLY="5"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_WEEKLY="4"
TIMELINE_LIMIT_MONTHLY="12"
TIMELINE_LIMIT_YEARLY="0"

Essa configuração mantém 10 snapshots baseados em alterações do sistema de pacotes, 5 snapshots por hora nas últimas horas, 7 snapshots diários para a última semana e 4 semanais para o último mês. É um equilíbrio ideal para uso em estações de trabalho e servidores de produção.

Por fim, ative os timers do systemd para que o Snapper crie os pontos de restauração automaticamente em segundo plano:

systemctl enable --now snapper-timeline.timer snapper-cleanup.timer

Como integrar o grub-btrfs para dar boot direto nos snapshots?

A criação automática de snapshots de nada adianta se o sistema operacional sofrer um Kernel Panic ou uma falha de carregamento do servidor gráfico que impeça o acesso ao terminal. A solução para essa limitação é a ferramenta grub-btrfs, que lê automaticamente a lista de snapshots do Snapper e gera entradas dinâmicas no menu de boot do GRUB.

Quando o grub-btrfs está instalado e configurado, o menu do carregador de inicialização exibe um submenu contendo todos os snapshots disponíveis. O usuário pode selecionar qualquer ponto do tempo e dar boot diretamente no sistema em modo somente leitura (read-only) para verificar se tudo funciona antes de oficializar a restauração.

Para instalar e ativar a atualização automática do menu do GRUB sempre que um novo snapshot for criado pelo Snapper, instale o pacote correspondente e ative o serviço de monitoramento via systemd:

systemctl enable --now grub-btrfsd.service

Se você precisar testar uma restauração após uma atualização quebrada, o fluxo completo de rollback em produção ocorre em duas etapas simples:

1. Reinicie a máquina e selecione a entrada do snapshot desejado no menu secundário do GRUB.
2. Assim que o sistema carregar a interface ou o terminal a partir do snapshot em modo somente leitura, abra o terminal e execute o comando oficial do Snapper para efetivar a troca do subvolume raiz:

snapper rollback

O comando snapper rollback localiza o snapshot atual no qual você iniciou a sessão, torna esse snapshot o novo subvolume padrão de boot no Btrfs e move a raiz com defeito para um snapshot secundário de segurança. Na próxima reinicialização da máquina, você estará rodando o sistema completamente funcional e em modo de escrita normal.

Conclusão

Aprender a organizar subvolumes btrfs e snapper transforma radicalmente a relação com a manutenção e atualização de sistemas Linux. A combinação da arquitetura de subvolumes planos com a automação de snapshots permite que desenvolvedores e administradores de sistemas experimentem novos drivers, compilações de kernel e atualizações de pacotes sem o receio de perder o ambiente de trabalho.

Ao manter diretórios críticos como /home e /var/log devidamente isolados do subvolume raiz, você garante a proteção total dos seus dados e logs durante qualquer operação de recuperação. A inclusão do grub-btrfs fecha o ciclo de confiabilidade, oferecendo um mecanismo de boot direto que resgata o computador mesmo nas piores falhas de inicialização.