Scrubbing - Verificando Seus Dados Antes que os Problemas Apareçam

Colaboração: Rubens Queiroz de Almeida

Data de Publicação: 7 de julho de 2026

No artigo anterior vimos que o Btrfs calcula automaticamente checksums para todos os blocos de dados armazenados. Sempre que um arquivo é lido, o sistema pode verificar se seu conteúdo continua exatamente igual ao que foi gravado originalmente. Essa característica permite detectar corrupção silenciosa de dados, um problema que normalmente passa despercebido em sistemas de arquivos tradicionais.

Entretanto, existe uma limitação importante nessa estratégia. Um arquivo que nunca é acessado também nunca tem seu checksum verificado. Imagine um backup criado há dois anos, armazenado em um disco que permanece praticamente o tempo todo desligado. Se algum bloco sofrer corrupção durante esse período, o problema somente será descoberto quando alguém tentar restaurar aquele backup. Em uma situação de emergência, essa talvez seja a pior hora possível para descobrir que o arquivo está danificado.

Foi justamente para resolver esse problema que o Btrfs incorporou o mecanismo conhecido como scrubbing.

Em português, a palavra "scrub" pode ser traduzida como "esfregar" ou "limpar". No contexto do armazenamento, porém, seu significado é um pouco diferente. O processo consiste em percorrer sistematicamente todos os blocos armazenados no sistema de arquivos, lendo cada um deles e recalculando seus respectivos checksums. Sempre que uma inconsistência é encontrada, o Btrfs toma as providências necessárias.

Em sistemas configurados com redundância, como RAID1 ou RAID10, o processo é ainda mais interessante. Se um bloco apresentar erro em um dos discos, o Btrfs lê a cópia existente no outro dispositivo, verifica qual delas está íntegra e utiliza essa informação para reconstruir automaticamente o bloco defeituoso. Ao final do processo, a redundância é restabelecida sem qualquer intervenção do administrador.

Essa é uma diferença importante em relação à simples leitura de arquivos. O scrubbing não depende da atividade dos usuários nem da execução de aplicações. Ele percorre deliberadamente todo o sistema de arquivos, procurando problemas antes que eles afetem alguém.

Executar uma verificação é bastante simples:

$ sudo btrfs scrub start /

Nesse exemplo, o caractere "/" representa o ponto de montagem do sistema de arquivos que será verificado. Em outro ambiente poderia ser `/dados`, `/backup` ou qualquer outro volume Btrfs.

O processo normalmente é executado em segundo plano. Enquanto isso, o sistema continua disponível para uso. Usuários podem acessar arquivos, serviços permanecem ativos e aplicações continuam funcionando normalmente. Em sistemas muito grandes, a operação pode levar horas, mas isso não significa que o computador precise ficar indisponível durante esse período.

Caso seja necessário acompanhar o progresso da verificação, pode-se utilizar:

$ sudo btrfs scrub status /

Esse comando informa quanto da verificação já foi concluído, quantos erros foram encontrados e se alguma correção foi realizada automaticamente.

Uma dúvida bastante comum diz respeito à frequência ideal para executar o scrubbing. Não existe uma resposta universal, a periodicidade depende principalmente da importância dos dados e do perfil de utilização do sistema.

Em um servidor que armazena documentos corporativos ou máquinas virtuais críticas, uma verificação mensal costuma ser uma prática bastante razoável. Em um servidor de backup, cuja principal função é preservar dados durante longos períodos, alguns administradores preferem executar o procedimento quinzenalmente. Já em um computador doméstico, uma verificação a cada dois ou três meses normalmente é suficiente.

O importante é compreender que o scrubbing não substitui backups nem monitora a saúde física dos discos. Seu objetivo é verificar a integridade lógica dos dados armazenados. Trata-se de uma camada adicional de proteção, voltada especificamente para identificar corrupção silenciosa antes que ela se transforme em perda definitiva de informações.

A automatização desse processo é bastante simples. Em sistemas que não utilizam serviços específicos do systemd, pode-se recorrer ao tradicional cron. Basta criar uma tarefa agendada para executar o scrubbing periodicamente.

Um exemplo seria adicionar a seguinte entrada ao arquivo de agendamento:

0 3 1 * * root btrfs scrub start /dados

Nesse caso, a verificação será iniciada às três horas da manhã do primeiro dia de cada mês. Como o processo é executado em segundo plano, não há necessidade de aguardar sua conclusão antes de liberar o cron para outras tarefas.

Distribuições mais recentes costumam oferecer uma alternativa ainda mais elegante através do systemd. Muitas delas já incluem serviços e temporizadores específicos para o Btrfs, permitindo que verificações periódicas sejam executadas automaticamente sem necessidade de editar arquivos do cron. Mesmo assim, conhecer a solução baseada em cron continua sendo útil, principalmente em servidores mais antigos ou em ambientes onde o administrador prefere manter controle total sobre o agendamento das tarefas.

À primeira vista, pode parecer estranho gastar tempo lendo arquivos que aparentemente estão funcionando perfeitamente. Entretanto, essa é exatamente a lógica da manutenção preventiva. Esperar que um erro apareça durante a restauração de um backup ou durante a leitura de um documento importante significa descobrir o problema tarde demais. O scrubbing inverte essa lógica. Em vez de reagir às falhas, ele procura encontrá-las enquanto ainda existe tempo para corrigi-las.

Esse tipo de preocupação ilustra bem a filosofia do Btrfs. O sistema de arquivos não se limita a armazenar informações. Ele acompanha continuamente sua integridade, verifica sua consistência e, quando possível, realiza automaticamente os reparos necessários. Poucos sistemas de arquivos oferecem um conjunto tão abrangente de mecanismos voltados para preservar dados ao longo dos anos.

No próximo artigo veremos como aproveitar snapshots para construir uma estratégia de backup extremamente eficiente utilizando os comandos btrfs send e btrfs receive. Em vez de copiar novamente todos os arquivos a cada execução, veremos como transferir apenas as diferenças entre snapshots sucessivos, reduzindo drasticamente o tempo necessário para proteger grandes volumes de dados.