Verificação e reparo de sistemas de arquivos: fsck, xfs_repair e btrfs check em um sistema de arquivos desmontado

Objetivo

Verificar se um sistema de arquivos Linux está corrompido e repará-lo somente quando a ferramenta e o modo utilizados forem seguros para o estado em que ele se encontra.

Pré-requisitos

O sistema de arquivos de destino deve estar desmontado (se for o sistema de arquivos raiz, inicie antes no modo de resgate/emergência ou em um sistema live/de resgate); acesso root; backups recentes, caso se espere que o reparo seja destrutivo.

Passos

1. Confirme que o sistema de arquivos está desmontado antes de verificá-lo. O manual do e2fsck afirma de forma clara que ele não deve ser executado em sistemas de arquivos montados e que, mesmo nos casos em que -n torna a execução tecnicamente segura, os resultados exibidos enquanto o sistema de arquivos está montado não são válidos. O front-end genérico fsck chama o verificador específico de cada sistema de arquivos (fsck.ext4 etc.).
2. Para ext2/3/4: execute primeiro e2fsck -fn /dev/<device> (verificação completa forçada, sem alterações) e depois e2fsck -f /dev/<device> para reparar de forma interativa, ou -y para responder "yes" a todas as perguntas de forma não interativa — o que também aceita correções destrutivas.
3. Para XFS, o fsck genérico chama fsck.xfs, que normalmente apenas termina com código 0; use xfs_repair, que se recusa a atuar em um sistema de arquivos montado. Execute primeiro xfs_repair -n /dev/<device> — o "no modify mode" (modo sem modificação): ele informa o que seria reparado sem alterar nada e retorna 1 se detectar corrupção, ou 0 se não detectar. Sem -n, retorna 0 quando conclui, 1 em caso de erro de execução (execute-o novamente) e 2 quando não consegue prosseguir porque o log está sujo. Se o log estiver sujo, monte e desmonte o sistema de arquivos uma vez (em uma máquina com a mesma arquitetura de CPU) para que o kernel reproduza o log, e então execute novamente. xfs_repair -L, em vez disso, zera o log: todas as atualizações de metadados em andamento no momento da falha são perdidas, o que, segundo o manual, pode causar danos significativos — use apenas como último recurso e depois de fazer um backup em imagem.
4. Para Btrfs: btrfs check não modifica o dispositivo por padrão (--readonly apenas reafirma isso); btrfsck é um alias obsoleto. O manual aconselha não usar --repair "unless you are advised to do so by a developer or an experienced user" (a menos que um desenvolvedor ou um usuário experiente o recomende) e observa que nenhum verificador consegue corrigir todos os tipos de corrupção. Prefira restaurar a partir de um snapshot ou backup em vez de usar --repair, quando houver um; em um sistema de arquivos montado, btrfs scrub start <mountpoint> verifica os checksums online, o que não é uma verificação estrutural.
5. Para forçar a verificação do sistema de arquivos raiz em uma única inicialização, adicione fsck.mode=force no menu de boot (se mantido na configuração, força a verificação em toda inicialização; auto é o padrão e skip desativa as verificações); fsck.repair= (preen, yes, no) controla o grau de agressividade com que o systemd-fsck responde às perguntas de reparo durante essa verificação automática.
6. Interprete o código de saída do fsck genérico como uma soma bit a bit: 0 sem erros, 1 erros corrigidos, 2 o sistema deve ser reiniciado, 4 erros não corrigidos, com bits mais altos para falhas operacionais; os códigos de vários sistemas de arquivos verificados em uma mesma execução são combinados com OR, portanto verifique um sistema de arquivos por invocação quando um script precisar de um resultado preciso.

Resultado esperado

Uma verificação limpa não relata corrupção (saída 0, ou saída 0 de xfs_repair -n); uma passagem de reparo deixa o sistema de arquivos montável, e o próprio resumo da ferramenta indica o que foi corrigido.

Limites e base de verificação

XFS e Btrfs definem seus próprios códigos de saída e opções — não presuma que coincidam com os do fsck. btrfs check --repair ainda não funciona em conjunto com --mode=lowmem. Faça backup (ou snapshot) antes de qualquer reparo que não seja uma simulação; um verificador pode piorar um sistema de arquivos já danificado.