Reparando corrupção de sistema de arquivos com fsck: Procedimento seguro

2026-06-06 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediário

O que você vai aprender

• Como executar fsck sem destruir dados
• Como verificar e reparar o sistema de arquivos raiz (/) montado
• Quando usar -n / -y / -f, e como ext4 difere do XFS

O que é fsck e quando usar?

Conclusão: fsck verifica e repara a integridade do sistema de arquivos. Use quando corrupção de metadados é provável - Input/output error, Read-only file system ou fsck falho na inicialização.

fsck (file system check) é um front-end que despacha para um verificador por sistema de arquivos (fsck.<tipo>, ex. e2fsck para a família ext). Ele verifica o superbloco, tabelas de inodes, estrutura de diretórios e bitmaps de blocos, depois repara inconsistências. XFS é uma exceção: fsck.xfs é um stub que não faz nada, então você verifica e repara XFS com xfs_repair diretamente.

Situações típicas onde você precisa dele:

• Operações de arquivo falham repetidamente com Input/output error
• O sistema de arquivos mudou repentinamente para Read-only file system (o kernel detectou corrupção e protegeu)
• A inicialização parou em "fsck failed" ou "Give root password for maintenance"
• Após um desligamento não limpo ou queda de energia, você quer verificar a integridade

Por que nunca executar fsck em um sistema de arquivos montado?

Conclusão: Um FS montado tem o kernel armazenando e atualizando metadados em cache. Se fsck escreve por um caminho separado, as duas visões divergem e o "reparo" corrompe estruturas ativas em vez de corrigi-las.

Em um sistema de arquivos ativo, o kernel atualiza inodes e bitmaps no buffer cache. fsck lê e escreve o dispositivo de bloco diretamente. Se fsck escreve uma "correção" enquanto a visão do kernel difere, ele destrói estruturas que ainda estavam em uso.

Por isso o fsck em modo de reparo se recusa a executar (ou avisa) quando o alvo está montado. Existem três caminhos seguros:

1. Desmontar, depois executar (para partições de dados)
2. Diagnosticar em somente leitura com -n (não escreve nada - mais seguro, mas não repara nada)
3. Para o FS raiz, usar modo de resgate / fsck na inicialização / USB live (abaixo)

# Primeiro, confirme que o alvo nao esta montado
$ findmnt /dev/sdb1
$ lsblk -f

Como verificar e reparar uma partição de dados com segurança?

Conclusão: Desmonte, diagnostique com -n, depois repare com -fy se necessário. Se falha de hardware é provável, crie imagem do dispositivo com ddrescue antes de reparar.

1. Desmonte

$ sudo umount /dev/sdb1

Se não desmontar com target is busy, encontre o que está segurando.

$ sudo fuser -vm /dev/sdb1
$ sudo lsof /dev/sdb1

2. Diagnostique em somente leitura primeiro (-n)

-n responde "não" a cada pergunta e não escreve nada. Use para avaliar o dano.

$ sudo fsck -n /dev/sdb1

3. Crie imagem do dispositivo se falha de hardware é suspeita

Quando uma falha física é provável (frequentes Input/output error, abaixo), resgate os setores com ddrescue antes que um reparo piore as coisas.

$ sudo ddrescue /dev/sdb1 /mnt/backup/sdb1.img /mnt/backup/sdb1.log

4. Forçar verificação e reparo automático (-fy)

$ sudo fsck -fy /dev/sdb1

• -f: forçar verificação completa mesmo se o FS está marcado como "limpo"
• -y: responder "sim" a cada prompt de reparo (executar sem interação até o fim)

Como verificar o sistema de arquivos raiz (/) montado?

Conclusão: Você não pode desmontar um / ativo. Use uma das opções: agendar um fsck automático na próxima inicialização, iniciar com fsck.mode=force ou verificar de um USB live.

O sistema de arquivos raiz está em uso, então normalmente não pode ser desmontado. Três soluções:

Opção A: Agendar um fsck forçado na próxima inicialização

Em sistemas systemd você pode solicitar uma verificação na inicialização com um arquivo de flag.

# Ubuntu/Debian: forcar verificacao unica na proxima inicializacao
$ sudo touch /forcefsck
$ sudo reboot

systemd-fsck lê /forcefsck e executa a verificação no início da inicialização (enquanto root ainda está somente leitura), depois exclui o flag automaticamente.

Opção B: Passar um parâmetro de kernel pelo GRUB

No menu GRUB pressione e, depois adicione ao final da linha linux:

fsck.mode=force fsck.repair=yes

fsck.repair=yes é como -y (reparo sem interação). Para ser conservador, use fsck.repair=preen (como -p, apenas correções automáticas seguras).

Opção C: Verificar de um USB live / midia de resgate

Se o root está muito danificado para iniciar, inicie um USB live e verifique sem montar.

# No ambiente live (nunca monte o alvo)
$ sudo fsck -fy /dev/sda2

Como as principais opções do fsck diferem?

Conclusão: Diagnostique com -n, repare sem interação com -y ou -p, e force verificação completa com -f. Combine-as conforme a situação.

# Para ext, e2fsck e chamado diretamente. Para ser explicito:
$ sudo e2fsck -fy /dev/sdb1

# Se o superbloco esta danificado, use um superbloco de backup
$ sudo dumpe2fs /dev/sdb1 | grep -i superblock
$ sudo e2fsck -b 32768 /dev/sdb1

E os sistemas de arquivos não-ext4 (XFS / Btrfs)?

Conclusão: fsck.xfs não faz nada - XFS usa xfs_repair. Btrfs usa btrfs check. Escolha a ferramenta certa por sistema de arquivos ou você não está realmente reparando nada.

Verifique o tipo de sistema de arquivos com lsblk -f ou blkid.

$ lsblk -f /dev/sdb1
$ sudo blkid /dev/sdb1

Para XFS

XFS não tem fsck tradicional. /sbin/fsck.xfs existe mas não faz nada (um stub para que a inicialização não seja bloqueada). A ferramenta real de reparo é xfs_repair.

# Sempre desmonte primeiro
$ sudo umount /dev/sdb1
# Simulacao primeiro (-n nao altera nada)
$ sudo xfs_repair -n /dev/sdb1
# Reparo
$ sudo xfs_repair /dev/sdb1

Somente quando um log danificado faz xfs_repair se recusar a executar você deve usar -L (zerar o log) como último recurso. Isso arrisca perda de dados, então não use casualmente.

Para Btrfs

$ sudo umount /dev/sdb1
$ sudo btrfs check /dev/sdb1          # diagnosticar
$ sudo btrfs check --repair /dev/sdb1 # reparar (oficialmente um ultimo recurso)

O que verificar após um reparo?

Conclusão: Leia o código de saída, inspecione arquivos resgatados em lost+found, remonte e teste leitura/escrita. Se recorrer, suspeite do disco com smartctl.

1. Leia o código de saída

Os códigos de saída do fsck são um bitmask.

$ sudo fsck -fy /dev/sdb1; echo "exit=$?"

0 ou 1 significa finalização limpa. Se 4 ou maior permanece, reexecute ou crie imagem do dispositivo.

2. Inspecione lost+found

Inodes que perderam seu diretório pai são recuperados em lost+found/ na raiz do FS, nomeados pelo número de inode.

$ sudo mount /dev/sdb1 /mnt
$ sudo ls -l /mnt/lost+found/
$ sudo file /mnt/lost+found/*

3. Remonte e teste leitura/escrita

$ sudo mount /dev/sdb1 /mnt
$ touch /mnt/.write-test && rm /mnt/.write-test && echo "write OK"

4. Se recorrer, suspeite do hardware

$ sudo smartctl -a /dev/sdb | grep -iE 'reallocated|pending|uncorrect'
$ sudo dmesg | grep -iE 'I/O error|ata|medium error'

Se Reallocated_Sector_Ct ou Current_Pending_Sector está subindo, é uma falha física. Prefira substituir o disco e restaurar do backup em vez de mantê-lo vivo com fsck.

O que não fazer (checklist)

Conclusão: Reparar montado, confundir o tipo de FS, usar -y sem verificar e -L sem criar imagem são as formas clássicas de piorar a corrupção.