Linux / Comando fsck: verificar sistemas de arquivos e planejar reparos

O comando fsck chama ferramentas específicas para verificar a consistência de um sistema de arquivos e, quando solicitado, repará-lo. Confirme primeiro o alvo, o tipo e se ele está em uso: reparar um sistema de arquivos montado pode corromper dados. Para ext2, ext3 e ext4, e2fsck -n permite uma verificação sem modificar o sistema de arquivos, nas condições descritas abaixo.

O que fsck verifica

O fsck é uma interface para verificadores como fsck.ext4; ele não implementa um reparo universal. A consistência envolve relações entre arquivos, diretórios e metadados. O programa chamado, as opções e o significado dos resultados dependem do tipo de sistema de arquivos.

Em XFS, o caminho habitual de fsck.xfs não executa uma verificação completa: normalmente termina com status zero sem fazer esse trabalho. Isso não comprova que o volume foi examinado ou reparado. Para XFS, consulte o manual de fsck.xfs e o procedimento específico de xfs_repair, que exige o alvo desmontado. Não aplique comandos de ext4 a um volume XFS.

Sintaxe e escolha do alvo

sudo fsck [opções] [sistema_de_arquivos]

Os colchetes descrevem argumentos opcionais e não devem ser digitados literalmente. O alvo pode ser um dispositivo ou outro identificador aceito pela implementação. Não execute a forma genérica sem confirmar o alvo e o modo de operação. No fsck do util-linux, omitir o alvo pode ampliar o trabalho para entradas de /etc/fstab; não significa apenas mostrar ajuda.

Verifique a implementação instalada com man fsck e leia o manual do verificador correspondente. Um nome como /dev/sdb1 é apenas um exemplo neste texto: ele pode apontar para dados importantes no seu computador. Confirme caminho, tipo e relações entre volumes; a partição física pode não ser a camada que contém o sistema de arquivos.

Consultar tipo e estado de montagem

Comece identificando o volume e seu tipo de sistema de arquivos com lsblk:

lsblk -f

Confira o tipo reconhecido e as montagens indicadas, sem tratar um campo vazio como autorização para reparar. Considere também swap, RAID, criptografia e o Gerenciador de Volumes Lógicos, conhecido como LVM. O verificador deve atuar sobre a camada que contém o sistema de arquivos, não sobre um membro de RAID ou recipiente criptografado por engano.

Para procurar montagens associadas ao dispositivo ilustrativo, use:

findmnt /dev/sdb1

O findmnt aceita dispositivo ou ponto de montagem; a opção --source permite explicitar uma busca por dispositivo. Leia todas as correspondências e as mensagens de erro. Ausência de linhas, falha da ferramenta ou visibilidade limitada ao ambiente atual não comprovam, isoladamente, que o volume está fora de uso.

Se houver uso ativo, planeje parar os serviços e liberar o volume antes da verificação. Consulte os procedimentos de desmontagem com umount. Uma desmontagem adiada não significa que todos os acessos terminaram; confirme a liberação efetiva. O sistema de arquivos raiz costuma exigir uma inicialização de recuperação ou um ambiente live que não monte o alvo automaticamente.

No Bash 5.3.9 do Git para Windows usado na verificação deste texto, fsck, e2fsck, os verificadores XFS, lsblk e findmnt não estavam disponíveis. As consultas de lsblk e findmnt falharam por comando inexistente. As linhas dos exemplos passaram apenas por análise de sintaxe do Bash; nenhum verificador foi executado sobre um sistema de arquivos. Isso não constitui um teste em Linux nativo.

Verificar ext sem modificar o sistema de arquivos

O exemplo abaixo se aplica a um alvo confirmado como ext2, ext3 ou ext4, desmontado e sem uso por outras camadas. -n abre o sistema de arquivos para leitura e responde “não” às propostas de alteração. Confira antes um backup recuperável e a disponibilidade da ferramenta; substitua o caminho somente pelo alvo correto.

sudo e2fsck -n /dev/sdb1

O manual de e2fsck explica que resultados obtidos sobre um sistema de arquivos montado não são válidos, mesmo na exceção de uso de -n sem -c, -l ou -L. Por isso, não use esse modo como substituto da preparação do alvo. Não combine opções copiadas de outro procedimento sem conferir seus efeitos.

A saída real pode incluir o estado do sistema de arquivos, etapas de verificação e erros não corrigidos. O conteúdo varia conforme os metadados e a versão; não há uma contagem de erros ou uma lista de etapas garantida para todo alvo. Guarde o relatório completo para escolher a próxima ação, sem interpretar a recusa de alterações como reparo concluído.

Verificação, reparo automático e código de saída

As duas linhas abaixo ilustram a consulta seguida de uma chamada pela interface genérica. Não cole o bloco como uma sequência automática. Entre as linhas, confirme tipo, caminho, desmontagem e manual do verificador. A primeira consulta não libera o volume nem garante a segurança da segunda operação.

lsblk -f
sudo fsck -n /dev/sdb1

O significado de -n depende do programa chamado por fsck; não o trate como um modo universal de simulação. Em ext, ele solicita a verificação sem aprovar correções. -N maiúsculo é diferente: no fsck do util-linux, apenas exibe o que seria executado, sem chamar o verificador. Mostrar o comando não examina a integridade do volume.

Erros encontrados não são motivo para trocar imediatamente para fsck -y. Essa forma pode aprovar alterações automaticamente no verificador correspondente. Confirme backups, condições do armazenamento e o procedimento do formato antes de autorizar um reparo que modifica dados. A verificação de consistência também não substitui um diagnóstico de falha física do disco.

O status de saída merece leitura própria. No fsck do util-linux, os valores podem combinar condições: 1 indica erros corrigidos, 2 pede reinicialização, 4 indica erros não corrigidos e 8 indica erro operacional. Um valor diferente de zero não significa sempre a mesma falha. Em um shell, consulte echo $? imediatamente após o comando pertinente, antes de executar outra consulta que substitua esse status. Confira a tabela completa da implementação antes de automatizar decisões.

Depois de um reparo autorizado, siga as recomendações do verificador antes de voltar a montar e valide também os arquivos e a aplicação que usa o volume. Reparar metadados não garante recuperar todo o conteúdo anterior; não existe uma reversão simples garantida.

Opções principais de fsck

O manual de fsck do util-linux descreve a seleção de verificadores e os códigos de saída. As opções específicas não são padronizadas entre formatos: leia também o manual da ferramenta que será chamada.

Preparar uma verificação ou recuperação

1. Confirme o volume correto. Identifique o sistema de arquivos e a camada que o contém. Em RAID, LVM e volumes criptografados, examine as dependências antes de escolher o dispositivo.
2. Proteja os dados necessários. Verifique um backup recuperável fora do alvo e os meios de recuperação. Se houver sinais de falha de hardware ou erros de leitura, interrompa tentativas repetidas e planeje a preservação dos dados antes de reparar.
3. Elimine o uso ativo pelo procedimento adequado. Pare serviços, desmonte e confirme a liberação. Para a raiz, prepare um ambiente de recuperação em que o volume não esteja sendo usado; estar em modo de recuperação não garante isso por si só.
4. Separe diagnóstico de autorização para reparar. Comece pelo modo de verificação documentado para o formato, avalie relatório e status e só então decida o reparo. Depois, confira montagem, arquivos e aplicação antes de retomar o uso normal.

Pergunta frequente

Posso executar fsck em um sistema de arquivos montado?

Uma verificação que modifica um sistema de arquivos montado pode corromper dados. Em geral, prepare o alvo desmontado e sem uso ou utilize um ambiente de recuperação adequado. No e2fsck, até a exceção com -n e sem -c, -l ou -L produz resultados inválidos se o sistema de arquivos estiver montado; não use essa exceção para declarar que o volume está íntegro.