Btrfs e agentes de código: recuperar rápido não dispensa backup nem limites de espaço

Depois de um incidente com seu NAS e da verificação de 91 TB, Fabio Akita defende Btrfs para desktops e notebooks Linux e relata o crescimento de builds e caches em fluxos com agentes de programação.[17] O texto reúne snapshots, checksums, subvolumes, compressão e backup separado.[17] Minha leitura é que o problema começa antes da escolha do filesystem: é preciso distinguir o que pode ser recriado do que não pode ser perdido.

O que muda para quem desenvolve

Akita relata 920 GiB em diretórios de build Rust e mais de 1 TB de cache Docker.[17] Esses números descrevem o ambiente do autor, não uma previsão para qualquer máquina.[17] Ainda assim, justificam uma revisão prática: eu incluiria consumo de espaço no aceite de uma automação que cria artefatos repetidamente.

Snapshots preservam referências aos blocos de um momento, mas o snapshot de um subvolume pai não inclui recursivamente subvolumes filhos.[17] Essa distinção exige mapear o que está protegido antes de confiar no retorno. O artigo também ressalta que snapshots locais não substituem backup em outro destino.[17]

Minha recomendação é separar recuperação rápida, proteção contra perda do dispositivo e consistência dos dados da aplicação. Não usaria a presença de um snapshot como evidência suficiente para nenhuma dessas três perguntas ao mesmo tempo.

Como aplicar

Comece com um inventário somente de leitura de projetos, builds, caches, volumes e diretórios de dados. Para cada categoria, registre responsável, possibilidade de reconstrução e dependências. Não apague algo apenas porque é antigo ou não aparece na tarefa atual.

Defina uma política de retenção para snapshots e backup. O artigo explica que snapshots continuam referenciando blocos de arquivos apagados, impedindo a liberação imediata desse espaço.[17] Acompanhe o uso real depois da retenção, em vez de presumir que uma exclusão resolveu a pressão de armazenamento.

Para agentes, eu criaria uma lista explícita dos artefatos produzidos pela execução. A limpeza deve atingir somente essa lista ou um diretório de trabalho dedicado, preservando dados e volumes por padrão. Se a autoria de um arquivo não puder ser demonstrada, encaminhe para revisão.

Faça um teste de restauração em destino separado: recupere arquivos de um projeto, compare-os com uma referência e confirme que o ambiente necessário pode ser reconstruído. Para bancos, use um procedimento de cópia consistente com a aplicação. Akita realiza dump antes do backup, justamente por não considerar o snapshot de filesystem garantia de consistência durante escrita.[17]

Cuidados e limites

A análise ressalta que desabilitar CoW implica ausência de checksum de dados e desabilita compressão nesse caminho.[17] Portanto, eu avaliaria essa escolha como troca de propriedades, não como ajuste gratuito de desempenho.

O autor também discute fragmentação em workloads de escrita aleatória e detalhes de rollback, como configurações do sistema desfeitas e espaço na partição de boot.[17] Sua preferência por Btrfs não é uma justificativa para migrar uma instalação sem cópia validada. O resultado desejado é conseguir recuperar dados e continuar operando, não apenas marcar que o filesystem tem mais recursos.

Fonte

[17] Fonte: AkitaOnRails