Reparando corrupcao de sistema de arquivos com fsck: Procedimento seguro

2026-06-06 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediario

O que voce 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 e fsck e quando usar?

Conclusao: fsck verifica e repara a integridade do sistema de arquivos. Use quando corrupcao de metadados e provavel - Input/output error, Read-only file system ou fsck falho na inicializacao.

fsck (file system check) e um front-end que despacha para um verificador por sistema de arquivos (fsck.<tipo>, ex. e2fsck para a familia ext). Ele verifica o superbloco, tabelas de inodes, estrutura de diretorios e bitmaps de blocos, depois repara inconsistencias. XFS e uma excecao: fsck.xfs e um stub que nao faz nada, entao voce verifica e repara XFS com xfs_repair diretamente.

Situacoes tipicas onde voce precisa dele:

• Operacoes de arquivo falham repetidamente com Input/output error
• O sistema de arquivos mudou repentinamente para Read-only file system (o kernel detectou corrupcao e protegeu)
• A inicializacao parou em "fsck failed" ou "Give root password for maintenance"
• Apos um desligamento nao limpo ou queda de energia, voce quer verificar a integridade

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

Conclusao: Um FS montado tem o kernel armazenando e atualizando metadados em cache. Se fsck escreve por um caminho separado, as duas visoes 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 le e escreve o dispositivo de bloco diretamente. Se fsck escreve uma "correcao" enquanto a visao do kernel difere, ele destroi estruturas que ainda estavam em uso.

Por isso o fsck em modo de reparo se recusa a executar (ou avisa) quando o alvo esta montado. Existem tres caminhos seguros:

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

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

Como verificar e reparar uma particao de dados com seguranca?

Conclusao: Desmonte, diagnostique com -n, depois repare com -fy se necessario. Se falha de hardware e provavel, crie imagem do dispositivo com ddrescue antes de reparar.

1. Desmonte

$ sudo umount /dev/sdb1

Se nao desmontar com target is busy, encontre o que esta segurando.

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

2. Diagnostique em somente leitura primeiro (-n)

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

$ sudo fsck -n /dev/sdb1

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

Quando uma falha fisica e provavel (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. Forcar verificacao e reparo automatico (-fy)

$ sudo fsck -fy /dev/sdb1

• -f: forcar verificacao completa mesmo se o FS esta marcado como "limpo"
• -y: responder "sim" a cada prompt de reparo (executar sem interacao ate o fim)

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

Conclusao: Voce nao pode desmontar um / ativo. Use uma das opcoes: agendar um fsck automatico na proxima inicializacao, iniciar com fsck.mode=force ou verificar de um USB live.

O sistema de arquivos raiz esta em uso, entao normalmente nao pode ser desmontado. Tres solucoes:

Opcao A: Agendar um fsck forcado na proxima inicializacao

Em sistemas systemd voce pode solicitar uma verificacao na inicializacao com um arquivo de flag.

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

systemd-fsck le /forcefsck e executa a verificacao no inicio da inicializacao (enquanto root ainda esta somente leitura), depois exclui o flag automaticamente.

Opcao B: Passar um parametro 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 e como -y (reparo sem interacao). Para ser conservador, use fsck.repair=preen (como -p, apenas correcoes automaticas seguras).

Opcao C: Verificar de um USB live / midia de resgate

Se o root esta 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 opcoes do fsck diferem?

Conclusao: Diagnostique com -n, repare sem interacao com -y ou -p, e force verificacao completa com -f. Combine-as conforme a situacao.

# 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 nao-ext4 (XFS / Btrfs)?

Conclusao: fsck.xfs nao faz nada - XFS usa xfs_repair. Btrfs usa btrfs check. Escolha a ferramenta certa por sistema de arquivos ou voce nao esta 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 nao tem fsck tradicional. /sbin/fsck.xfs existe mas nao faz nada (um stub para que a inicializacao nao seja bloqueada). A ferramenta real de reparo e 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 voce deve usar -L (zerar o log) como ultimo recurso. Isso arrisca perda de dados, entao nao 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 apos um reparo?

Conclusao: Leia o codigo de saida, inspecione arquivos resgatados em lost+found, remonte e teste leitura/escrita. Se recorrer, suspeite do disco com smartctl.

1. Leia o codigo de saida

Os codigos de saida do fsck sao um bitmask.

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

0 ou 1 significa finalizacao limpa. Se 4 ou maior permanece, reexecute ou crie imagem do dispositivo.

2. Inspecione lost+found

Inodes que perderam seu diretorio pai sao recuperados em lost+found/ na raiz do FS, nomeados pelo numero 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 esta subindo, e uma falha fisica. Prefira substituir o disco e restaurar do backup em vez de mante-lo vivo com fsck.

O que nao fazer (checklist)

Conclusao: Reparar montado, confundir o tipo de FS, usar -y sem verificar e -L sem criar imagem sao as formas classicas de piorar a corrupcao.