fsck ext4 após Corrupção SSD: Diagnóstico e Recuperação Passo-a-Passo para Sysadmins

Linux · Storage · ext4 · fsck · SSD · Recuperação | ✎ Duarte Spínola | 11 de Julho de 2026

A corrupção de sistemas de ficheiros ext4 em SSDs é um problema que afecta sysadmins em servidores cloud, on-premise, e estações de trabalho Linux. Os sintomas variam — desde erros de leitura intermitentes até ao sistema recusar arrancar. O fsck (File System Consistency Check) é a ferramenta padrão para diagnóstico e reparação, mas pode demorar horas ou dias em discos grandes. Este guia cobre o diagnóstico sistemático de corrupção ext4, execução segura do fsck, estratégias para minimizar tempo de recuperação, e prevenção em SSDs.

Conteúdos

• 1. O que Está a Acontecer — Causas de Corrupção ext4 em SSD
• 2. Sintomas e Cenários Comuns
• 3. Diagnóstico — Verificar sem Correr fsck
• 4. Passo 1 — Preparação e Backup antes do fsck
• 5. Passo 2 — Executar fsck em Modo Seguro
• 6. Passo 3 — fsck com Respostas Automáticas (-y, -n, -p)
• 7. Passo 4 — Recuperação de Ficheiros Perdidos (lost+found)
• 8. Passo 5 — Verificar e ReMontar o Sistema de Ficheiros
• 9. Porque é que o fsck Demora Dias em SSDs Grandes
• 10. Prevenção — TRIM, journalling e Monitorização SMART
• 11. FAQ para Sysadmins
• 12. Erros Comuns e Resoluções

1. O que Está a Acontecer — Causas de Corrupção ext4 em SSD

O ext4 é o sistema de ficheiros padrão em praticamente todas as distribuições Linux modernas (Ubuntu, Debian, RHEL). É robusto, com journaling (registo de transações) que protege contra crashes súbitos. No entanto, a corrupção ainda ocorre por várias causas:

1. Falhas de hardware SSD — Cells NAND degradam-se com escritas. Quando um sector SSD falha definitivamente, o controlador deve remapear (wear leveling), mas se falhar subitamente, o ext4 regista erros de I/O. SMART warnings aparecem antes da falha total.

2. Corte de energia súbito — O journaling do ext4 protege metadados, mas não dados de ficheiros. Um corte súbito durante uma escrita pode corromper o ficheiro em uso. Em UPS ou servidor cloud, isto é raro, mas em Raspberry Pi ou servidor sem UPS é comum.

3. Controlador SSD com firmware buggy — Alguns SSDs NVMe têm bugs de firmware que causam corruption sob carga específica. Verificar sempre se há firmware updates do fabricante.

4. Cabo SATA/NVMe defeituoso — Cabos SATA soltos ou danificados causam erros de I/O intermitentes que o ext4 interpreta como corrupção. Em NVMe, o slot PCIe pode ter mau contacto.

5. Kernel panic durante escrita — Um crash do kernel durante uma operação de escrita pode deixar o sistema de ficheiros num estado inconsistente.

2. Sintomas e Cenários Comuns

3. Diagnóstico — Verificar sem Correr fsck

Antes de correr fsck (que pode demorar horas), verificar o estado do sistema de ficheiros sem modificar nada:

# 1. Verificar erros no kernel
sudo dmesg | grep -i "ext4\|i/o error\|ata\|nvme" | tail -30

# 2. Verificar estado SMART do disco
sudo smartctl -a /dev/sda | grep -i "reallocated\|pending\|uncorrectable\|health"
# Se "SMART overall-health self-assessment test result: FAILED" — hardware a falhar

# 3. Verificar se o FS está montado read-only
mount | grep sda
# Se "ro,errors=remount-ro" — o ext4 detectou erros e protegeu-se

# 4. Verificar erros de I/O recentes
sudo journalctl -k | grep -i "i/o error" | tail -20

# 5. Verificar contagem de mounts antes de fsck
sudo tune2fs -l /dev/sda1 | grep -i "mount count\|last checked\|check interval"
# Output:
# Mount count:              47
# Maximum mount count:      -1
# Last checked:             Sat Jul  5 10:23:01 2026
# Check interval:           0 (none)

4. Passo 1 — Preparação e Backup antes do fsck

# 1. Desmontar o sistema de ficheiros
sudo umount /dev/sda1

# Se não conseguir desmontar (em uso), parar serviços que o usam
sudo systemctl stop nginx postgresql docker
sudo umount /dev/sda1

# Se ainda não conseguir (root filesystem), fazer boot com live USB
# e correr fsck a partir do live

# 2. Fazer backup do superblock antes de tudo
sudo dumpe2fs /dev/sda1 | grep -i "superblock\|block size\|block count"
# Output:
# Primary superblock at 0
# Block size: 4096
# Block count: 122096646
# Backup superblocks at: 32768, 98304, 163840, 229376, ...

# 3. Fazer imagem de backup (se houver espaço)
sudo dd if=/dev/sda1 of=/backup/sda1.img bs=64K status=progress
# OU pelo menos dos primeiros superblocks:
sudo dd if=/dev/sda1 of=/backup/sda1_superblock_backup bs=4096 count=1

5. Passo 2 — Executar fsck em Modo Seguro

# Modo interactivo (pergunta antes de cada reparação)
sudo fsck.ext4 /dev/sda1

# Output típico:
# e2fsck 1.47.0 (5-Feb-2024)
# /dev/sda1: clean, 123456/9999999 files, 987654/9999999 blocks

# Se houver erros:
# /dev/sda1 contains a file system with errors, check forced.
# Pass 1: Checking inodes, blocks, and sizes
# Pass 2: Checking directory structure
# Pass 3: Checking directory connectivity
# Pass 4: Checking reference counts
# Pass 5: Checking group summary information
# 
# Inode 12345, i_blocks is 8, should be 16. Fix? yes
# Free blocks count wrong (987654, counted=987600). Fix? yes

# Ver apenas sem modificar (dry-run)
sudo fsck.ext4 -n /dev/sda1

# Modo verbose para diagnóstico detalhado
sudo fsck.ext4 -v /dev/sda1

6. Passo 3 — fsck com Respostas Automáticas

Em discos com muitos erros, o fsck interactivo pode fazer centenas de perguntas. Para automatizar:

# -y: responder YES a todas as perguntas (reparar tudo)
sudo fsck.ext4 -y /dev/sda1
# Risco: pode apagar ficheiros irrecuperáveis. Usar apenas quando
# se tem backup ou quando o disco é irrecuperável sem reparação.

# -n: responder NO a todas (apenas verificar, não reparar)
sudo fsck.ext4 -n /dev/sda1

# -p: reparar automaticamente problemas seguros (não pergunta)
sudo fsck.ext4 -p /dev/sda1
# Se encontrar problemas graves, para e pede intervenção

# -f: forçar verificação mesmo se o FS está marcado como clean
sudo fsck.ext4 -f /dev/sda1

# Combinar: forçar + auto-reparar
sudo fsck.ext4 -fy /dev/sda1

# Para SSD grande (1TB+) com muitos erros, usar -y e ter paciência
# Pode demorar de horas a dias dependendo do número de erros

7. Passo 4 — Recuperação de Ficheiros Perdidos (lost+found)

O fsck coloca ficheiros recuperados (inodes sem nome de directório) na pasta lost+found na raiz do sistema de ficheiros:

# Após fsck, montar e verificar lost+found
sudo mount /dev/sda1 /mnt
sudo ls -la /mnt/lost+found/
# total 48
# drwx------  2 root root  32768 Jul 11 14:23 .
# drwxr-xr-x  root root  4096 Jul 11 14:00 ..
# -rw-r--r--  1 root root  1024 Jul 11 14:23 #12345
# -rw-------  1 root root  8192 Jul 11 14:23 #12346

# Os ficheiros têm nomes de números (inode numbers)
# Identificar tipo de ficheiro
sudo file /mnt/lost+found/#12345
# /mnt/lost+found/#12345: SQLite 3.x database

# Recuperar ficheiros identificados
sudo mv /mnt/lost+found/#12345 /mnt/recovered_database.db

# Verificar integridade de databases recuperados
sqlite3 /mnt/recovered_database.db "PRAGMA integrity_check;"

# Limpar lost+found após recuperar o que interessa
sudo rm -rf /mnt/lost+found/*

8. Passo 5 — Verificar e ReMontar o Sistema de Ficheiros

# 1. Desmontar após verificação
sudo umount /dev/sda1

# 2. Verificar que não há erros remanescentes
sudo fsck.ext4 -n /dev/sda1
# Output deve ser: "/dev/sda1: clean, ..."

# 3. Montar normalmente
sudo mount /dev/sda1 /mnt

# 4. Verificar que está montado read-write
mount | grep sda1
# Deve mostrar "rw" e não "ro"

# 5. Verificar integridade
sudo touch /mnt/test_write && sudo rm /mnt/test_write
# Se funcionar, o FS está funcional

# 6. Atualizar contagem de mounts
sudo tune2fs -C 0 /dev/sda1
# Reset do mount counter para não forçar fsck no próximo boot

# 7. Verificar dmesg após montar
sudo dmesg | grep "ext4" | tail -5
# Não deve haver novos erros

9. Porque é que o fsck Demora Dias em SSDs Grandes

O fsck executa 5 passos sobre todo o sistema de ficheiros:

Num SSD de 1TB com muitos erros, o Passo 1 pode demorar 24+ horas porque lê e verifica cada inode. Estratégias para reduzir o tempo:

# 1. Usar -y para auto-responder (não espera input humano)
sudo fsck.ext4 -y /dev/sda1

# 2. Desactivar verificação de bad blocks (já feito pelo SSD controller)
sudo fsck.ext4 -y -c /dev/sda1  # NÃO usar -c — é redundante em SSD e demora muito
# Em vez disso:
sudo fsck.ext4 -y /dev/sda1

# 3. Se o superblock primário está corrompido, usar backup
# Backup superblocks estão em: 32768, 98304, 163840, 229376, 294912...
sudo fsck.ext4 -b 32768 -y /dev/sda1

# 4. Verificar apenas metadata (não verificar data blocks)
sudo fsck.ext4 -y /dev/sda1
# O fsck por defeito não verifica data blocks, apenas metadata
# Adicionar -D para optimizar directórios (opcional):
sudo fsck.ext4 -yD /dev/sda1

# 5. Se estiver em cloud, usar snapshot para não bloquear o servidor
# Cloud providers: criar snapshot do disco, anexar a outra VM, correr fsck lá

10. Prevenção — TRIM, journalling e Monitorização SMART

Activar TRIM (essencial em SSD)

# Verificar se TRIM está activo
sudo fstrim -v /
# Output: /: 999.9 GiB trimmed

# Activar TRIM periódico (serviço systemd)
sudo systemctl enable fstrim.timer
sudo systemctl start fstrim.timer

# Verificar suporte TRIM do disco
sudo hdparm -I /dev/sda | grep TRIM
# Deve mostrar: *    Data Set Management TRIM supported

Verificar journaling do ext4

# Verificar se journaling está activo
sudo dumpe2fs /dev/sda1 | grep -i journal
# Deve mostrar:
# Has journal: yes
# Journal inode: 8
# Journal backup: inode blocks

# Se não tem journal (raro), activar:
sudo tune2fs -O has_journal /dev/sda1

Monitorizar SMART

# Instalar smartmontools
sudo apt install smartmontools

# Verificar saúde geral
sudo smartctl -H /dev/sda
# SMART overall-health self-assessment test result: PASSED

# Verificar atributos críticos
sudo smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|Power_On|Temperature"
# Reallocated_Sector_Ct   0x0033   100   100   010    Old_age   Always       -       0
# Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
# Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0

# Activar monitorização automática
sudo systemctl enable smartd
sudo systemctl start smartd

# Teste rápido SMART (2 minutos)
sudo smartctl -t short /dev/sda
# Aguardar 2 minutos
sudo smartctl -a /dev/sda | grep "test result"

11. FAQ para Sysadmins

1. Quando devo correr fsck?

Quando há erros de ext4 no dmesg, quando o sistema remonta read-only sozinho, quando o servidor não arranca, ou quando smartctl mostra setores realocados. Se o sistema está estável sem erros, NÃO precisa de correr fsck preventivamente — o journaling do ext4 cuida da consistência.

2. fsck ou e2fsck?

São o mesmo. fsck.ext4, e2fsck, e fsck -t ext4 chamam todos o mesmo binário. Use a forma que preferir.

3. Posso correr fsck com o sistema em produção?

Não. O FS tem de estar desmontado ou remontado read-only. Correr fsck num FS montado read-write causa corrupção adicional. Excepção: o fsck pode ser corrido durante o boot (antes de montar RW) se configurado em /etc/fstab com fsck option.

4. O que fazer se o superblock primário está corrompido?

Usar um superblock de backup. Descobrir a localização com dumpe2fs (antes da corrupção) ou usar as posições padrão (32768, 98304, 163840): sudo fsck.ext4 -b 32768 -y /dev/sda1.

5. Quanto tempo demora o fsck num SSD de 1TB?

Se o FS está limpo: 2-5 minutos. Se há corrupção: horas. Se há muitos erros (milhares de inodes corrompidos): pode demorar 24+ horas. O Passo 1 (verificação de inodes) é o mais lento.

6. Como evitar fsck no boot?

O fsck no boot é controlado pelo mount count e check interval. Desactivar com: sudo tune2fs -c 0 -i 0 /dev/sda1. Mas NÃO é recomendado — o fsck periódico previne corrupção silenciosa.

7. Devo usar -y ou modo interactivo?

Se tem backup: -y (mais rápido). Se não tem backup e os dados são críticos: modo interactivo, avaliar cada erro. Se há milhares de erros e o disco vai ser substituído: -y e recuperar o que for possível do lost+found.

8. O que é lost+found?

Directório na raiz do FS onde o fsck coloca ficheiros órfãos (inodes que tinham conteúdo mas não estavam ligados a nenhum directório). Os ficheiros têm nomes numéricos (inode number). Use file para identificar o tipo e recuperar.

12. Erros Comuns e Resoluções

Artigos Relacionados

• Diagnóstico de Kernel Logs Linux
• Diagnóstico de Desempenho em VMs Linux
• Ferramentas Avançadas de Diagnóstico Linux
• Diagnóstico de Memória Linux
• Diagnóstico de CPU Linux
• Ransomware 2026: Backup 3-2-1 Imutável
• iSCSI: Configurar Storage em Rede para PMEs

← Voltar ao Índice