Btrfs além do Hype: Domine Subvolumes, Snapshots e Backups Incrementais

Vamos ser honestos: o Btrfs teve uma adolescência difícil. Perda de dados, instabilidade em RAID 5/6 e uma complexidade que afugentou muitos administradores conservadores. Mas se você ainda está tratando o armazenamento como se estivéssemos em 2005, formatando tudo em EXT4 e confiando cegamente que o disco não está mentindo para você, está na hora de atualizar seus conceitos.

O Btrfs não é apenas "outro sistema de arquivos". É uma mudança fundamental na forma como gerenciamos a persistência de dados. Esqueça a ideia de que um arquivo ocupa um lugar fixo no prato do disco. Aqui, tudo é dinâmico, tudo é versionável e, se você não entender a física por trás disso, vai acabar com um disco cheio que se recusa a liberar espaço.

Vamos cortar o marketing e olhar para a engenharia: como usar subvolumes, snapshots e replicação incremental para criar uma infraestrutura de dados resiliente, sem depender de ferramentas externas lentas.

O que é Btrfs e Copy-on-Write (CoW)?

Btrfs (B-Tree Filesystem) é um sistema de arquivos moderno baseado em Copy-on-Write (CoW). Diferente de sistemas tradicionais que sobrescrevem dados no local (in-place), o CoW grava novos dados em blocos livres e, somente após a confirmação da gravação, atualiza os metadados para apontar para o novo local. Isso garante consistência atômica (sem necessidade de fsck demorados após quedas de energia) e permite funcionalidades avançadas como snapshots instantâneos e subvolumes dinâmicos.

---

Entendendo Copy-on-Write (CoW) e Árvores B no Btrfs

A maioria dos sysadmins visualiza o disco rígido como um estacionamento: o arquivo "A" está na vaga 10. Se eu edito o arquivo "A", o sistema vai lá na vaga 10 e pinta por cima do carro antigo. Isso é destrutivo. Se a energia cair no meio da pintura, você tem meio carro antigo e meio carro novo. O resultado é corrupção.

No Btrfs, a lógica é diferente. É um livro-razão (ledger) contínuo.

Quando você altera um bloco de dados, o Btrfs não toca no bloco original. Ele grava a alteração em um novo espaço livre. Só depois que essa nova gravação é validada (checksum verificado), ele atualiza a "Árvore B" (a estrutura de metadados) para dizer: "A versão atual deste arquivo agora vive no endereço Y, não mais no X".

Figura: Mecânica do CoW no Btrfs: O snapshot não copia dados, ele preserva ponteiros para blocos antigos.

Isso significa que, a qualquer momento, o estado anterior ainda existe no disco até ser explicitamente liberado. É essa característica física que permite a mágica dos snapshots. Não é mágica, é apenas gerenciamento inteligente de ponteiros.

Subvolumes Btrfs vs Diretórios: A Estrutura Lógica

O erro número um de quem vem do mundo EXT4/XFS é tratar subvolumes como se fossem diretórios comuns ou partições LVM.

Um Subvolume parece um diretório quando você dá um ls, mas tecnicamente ele é uma raiz de sistema de arquivos independente, com sua própria árvore de inodes, dentro do mesmo pool de armazenamento.

Por que isso importa? Porque você pode montar subvolumes individualmente, snapshotar subvolumes individualmente e definir quotas para eles.

Por que 'mountar' a raiz é um erro de iniciante

Muitas instalações padrão montam a raiz do Btrfs (ID 5) diretamente em /. Isso é ruim para a gestão a longo prazo. O layout ideal separa o sistema operacional dos dados e dos snapshots.

Em vez de ter tudo misturado, você deve criar uma estrutura plana (flat layout):

# NÃO FAÇA ISSO (Hierarquia aninhada complexa)
/ (root)
  /home
  /var

# FAÇA ISSO (Layout Plano)
/ (toplevel - ID 5, não montado por padrão)
  @ (montado em /)
  @home (montado em /home)
  @var (montado em /var)
  @snapshots

Isso permite que você reverta o sistema operacional (@) sem tocar nos dados dos usuários (@home). Se você aninhar subvolumes, o snapshot do pai não inclui os filhos automaticamente, o que cria confusão operacional.

A Física dos Snapshots Btrfs: O que acontece com os blocos

Aqui é onde o ceticismo geralmente aparece: "Como posso fazer um backup de 1TB em menos de 1 segundo?".

A resposta está na referência, não na cópia. Um snapshot no Btrfs não copia dados. Ao criar um snapshot, o sistema de arquivos simplesmente cria uma cópia da árvore raiz (os metadados) apontando para os mesmos blocos de dados no disco.

• Custo de Criação: O(1). É quase instantâneo, independentemente do tamanho do volume.

• Custo de Espaço Inicial: Zero. O snapshot aponta para os mesmos dados do original.

O consumo de espaço começa apenas quando você modifica o sistema de arquivos original. Como o Btrfs é CoW, os novos dados são gravados em outro lugar, e o snapshot continua segurando a referência (lock) nos blocos antigos. O "peso" do snapshot é exatamente o tamanho da divergência (delta) entre o estado original e o atual.

Adeus Rsync: A supremacia do 'btrfs send' e 'receive'

O rsync é uma ferramenta fantástica, mas é ineficiente para grandes volumes de dados. Para saber o que mudou, o rsync precisa "caminhar" por toda a árvore de diretórios, ler metadados (ou checksums) de milhões de arquivos, comparar com o destino e então transferir. Isso gera IOPS massivo e carga de CPU, mesmo que apenas 1KB tenha mudado.

O btrfs send opera em um nível inferior. Ele não escaneia o disco procurando mudanças; ele já sabe o que mudou. Ele consulta a árvore B e diz: "Quais blocos são diferentes entre o Snapshot A e o Snapshot B?".

Isso gera um fluxo (stream) de instruções binárias que pode ser enviado via pipe para outro disco, outra máquina via SSH, ou um arquivo.

Comparativo: Rsync vs Btrfs Send

Característica	Rsync	Btrfs Send/Receive
Nível de Operação	Arquivo (File-level)	Bloco/Sistema de Arquivos (Block-level)
Detecção de Mudança	Scan completo (lento em milhões de arquivos)	Instantâneo (via metadados transacionais)
Preservação	Permissões, datas (básico)	Tudo (UUIDs, atributos estendidos, links, clones)
Eficiência	Alta CPU/IOPS para scan	Baixa CPU, IOPS focado apenas na leitura do delta
Requisito	Funciona em qualquer FS	Requer Btrfs na origem e destino

O Ciclo de Vida do Backup Incremental Btrfs

Para operar backups incrementais eficientes, você precisa gerenciar a cadeia de "Parents" (pais). O btrfs send precisa de uma base comum que exista tanto na origem quanto no destino para calcular o diferencial.

Figura: Fluxo de Backup Incremental: O Btrfs calcula a diferença entre o snapshot pai e o atual instantaneamente.

O fluxo operacional robusto é:

1. Snapshot Read-Only: Você só pode enviar snapshots de leitura (read-only).

2. Envio Inicial: O primeiro envio é total.

3. Envio Incremental: O segundo envio usa o snapshot anterior como referência (-p).

Um exemplo prático de como isso se parece na linha de comando:

# 1. Criar snapshot read-only do estado atual
btrfs subvolume snapshot -r /home /home/.snapshots/backup-hoje

# 2. Enviar a diferença (assumindo que 'backup-ontem' já existe no destino)
btrfs send -p /home/.snapshots/backup-ontem /home/.snapshots/backup-hoje | \
ssh user@backupserver "btrfs receive /mnt/backup-pool/"

# 3. Rotação (Opcional, mas recomendado)
# Após sucesso, 'backup-hoje' vira a nova base para amanhã.
# Você pode remover 'backup-ontem' da origem se precisar de espaço.

Atenção aos UUIDs: O Btrfs usa UUIDs para saber quem é pai de quem. Se você reformatar o disco de destino ou deletar o snapshot pai no destino por engano, o fluxo incremental quebra e você precisará reenviar um backup completo.

A Armadilha do Espaço Livre: Qgroups e Fragmentação

Aqui está o pesadelo operacional do Btrfs se você não estiver atento. Você vê que o disco está cheio. Você deleta um arquivo de 50GB. Você verifica o espaço livre (df -h). O espaço livre não mudou.

Por que? Porque você tem um snapshot antigo que ainda referencia aqueles blocos de 50GB. Enquanto qualquer subvolume ou snapshot apontar para um bloco, o Btrfs não pode liberá-lo.

O Perigo dos Qgroups (Quota Groups)

Sysadmins adoram quotas, mas no Btrfs, habilitar Qgroups (btrfs quota enable) tem um custo de desempenho severo. O cálculo de "quem possui qual bloco" em um sistema com CoW e snapshots compartilhados é matematicamente complexo. Em sistemas com muitos snapshots e muita reescrita, o Qgroups pode travar o sistema ou causar lentidão extrema durante a limpeza de snapshots.

Recomendação Pragmática: Evite Qgroups a menos que seja estritamente necessário (ex: ambiente de hospedagem compartilhada). Para monitoramento, monitore o disco físico, não a quota do subvolume.

Fragmentação: Em cargas de trabalho como bancos de dados (PostgreSQL, VM images) que fazem muitas escritas aleatórias dentro de arquivos grandes, o CoW fragmenta o arquivo em milhares de pedaços. Isso mata a performance.

• Solução: Use o atributo chattr +C no diretório do banco de dados antes de criar os arquivos. Isso desativa o CoW (NoCoW) para aquela pasta específica.

Checklist de Recuperação: Restaurar vs Reverter

Quando o desastre acontece, a pressão sobe. Você precisa saber exatamente qual ferramenta usar. Não use uma bazuca para matar uma mosca.

1. Cenário: Usuário deletou um arquivo importante.

   • Ação: Não reverta o sistema. Monte o snapshot em um diretório temporário.
   • Comando: mount -o subvolid=256 /dev/sdX /mnt/restore
   • Procedimento: Copie o arquivo (cp) do snapshot montado de volta para a produção.

2. Cenário: Atualização do Sistema Operacional quebrou o boot.

   • Ação: Reverter o subvolume raiz.
   • Método Rápido: Mude o subvolume padrão para o ID do snapshot anterior.
   • Comando: btrfs subvolume set-default <ID_DO_SNAPSHOT> /
   • Resultado: No próximo reboot, o sistema sobe a versão antiga.

3. Cenário: Disco cheio (ENOSPC) e impossível deletar arquivos.

   • Ação: O Btrfs precisa de espaço livre para atualizar metadados para deletar dados. Se estiver 100% cheio, você trava.
   • Truque: Adicione temporariamente outro dispositivo (até um USB drive serve) ao pool (btrfs device add), balanceie os metadados, delete os snapshots antigos e depois remova o dispositivo extra.

Veredito Técnico

O Btrfs exige disciplina. Ele lhe dá poderes de "viagem no tempo" com snapshots e teletransporte de dados com send/receive, mas cobra o preço na gestão do espaço e na compreensão da estrutura de blocos.

Não confie no hype de que é "instalar e esquecer". Monitore seus snapshots, automatize a limpeza (ferramentas como Snapper ou scripts btrbk são essenciais, não opcionais) e entenda que, no fim do dia, seus dados são apenas ponteiros em uma Árvore B. Gerencie a árvore, e os dados estarão seguros.

---

Referências & Leitura Complementar

• Documentação Oficial do Kernel: Btrfs Wiki - Main Page & Guides (kernel.org). A fonte primária da verdade sobre status de features (ex: RAID5/6).

• Manpages: man 8 btrfs-send, man 8 btrfs-subvolume. Essencial para entender as flags de operação.

• Paper Acadêmico (Conceitual): Rodeh, O., Bacik, J., & Mason, C. (2013). BTRFS: The Linux B-Tree Filesystem. - Explica a estrutura interna das árvores e algoritmos de CoW.

• Ferramentas de Automação: Documentação do Snapper (openSUSE) e btrbk (digint).