Corrupção de filesystem em servidores críticos: como diagnosticar antes de sair reparando

Quando um filesystem apresenta erro em um servidor de produção — especialmente em ambientes com bancos Oracle, ERPs ou sistemas hospitalares —, o instinto mais comum é rodar xfs_repair ou fsck -y imediatamente e torcer para o problema sumir. Esse é exatamente o tipo de decisão apressada que transforma uma corrupção pontual em uma perda de dados irreversível.

Neste artigo, mostramos o fluxo de diagnóstico que aplicamos na Nyverra antes de qualquer reparo de filesystem: por que a ordem das operações importa, como isolar se o problema é do disco físico ou de uma corrupção lógica, e os comandos que realmente separam um repair seguro de um desastre.

Por que não rodar o repair de cara

xfs_repair e fsck são ferramentas de última linha — elas reconstroem metadados, movem arquivos órfãos para lost+found e, em casos extremos, descartam transações do journal. Rodar essas ferramentas sem entender a causa raiz do problema tem dois riscos:

1. Rodar em disco com falha física real. Se o problema é um setor defeituoso ou controlador degradando, o repair pode reescrever metadados sobre dados ainda recuperáveis, ou simplesmente falhar no meio do processo, deixando o filesystem em estado pior do que estava.

2. Rodar com o filesystem montado ou em produção ativa. Algumas flags do xfs_repair, como -d, existem justamente para permitir reparo em filesystem que o sistema operacional considera montado — e usá-las fora de um cenário de rescue/live boot é uma receita quase garantida para agravar a corrupção, principalmente quando o volume em questão é a partição raiz do sistema.

Por isso, nosso primeiro passo nunca é o reparo. É a saúde do disco.

Passo 1 — Descartar problema de hardware com SMART

Antes de tocar em qualquer filesystem, validamos a saúde física do disco:

smartctl -s on /dev/sda
smartctl -H /dev/sda
smartctl -a /dev/sda

Os atributos que mais importam nessa checagem, principalmente em SSDs — cada vez mais comuns em servidores de borda e ambientes de virtualização —, são:

• Reallocated_Event_Count — setores remapeados. Se maior que zero e crescendo, é sinal de degradação de mídia.

• Reported_Uncorrect — erros de leitura que o próprio disco não conseguiu corrigir.

• UDMA_CRC_Error_Count / SATA_CRC_Error_Count — geralmente aponta problema de cabo ou conector, não do disco em si.

• Media_Wearout_Indicator / SSD_Life_Left — desgaste de NAND acumulado.

• Unsafe_Shutdown_Count / Power-Off_Retract_Count — quantas vezes o disco sofreu um corte de energia sem desligamento limpo. Esse número é o elo mais direto entre o histórico do hardware e uma corrupção de journal em XFS ou ext4.

Se a leitura estática já não é suficiente, rodamos um self-test ativo:

smartctl -t short /dev/sda
# aguardar o tempo estimado antes de consultar
smartctl -l selftest /dev/sda

O resultado que buscamos é Completed without error. Qualquer variação disso — falha de leitura, timeout, abort — já indica que o problema está no disco, e nesse cenário o caminho é substituição do hardware antes de qualquer tentativa de reparo lógico, não o contrário.

Passo 2 — Cruzar com o histórico de shutdowns sujos

Em ambientes virtualizados ou de testes, é comum encontrar um Unsafe_Shutdown_Count alto mesmo em discos saudáveis — o valor se acumula a cada reset de VM, queda de energia sem UPS, ou kill de processo de hypervisor sem passar por um shutdown ACPI limpo.

Esse é o padrão clássico de corrupção XFS por journal incompleto: o disco está fisicamente íntegro, mas o filesystem ficou em estado inconsistente porque a última operação de escrita não foi commitada corretamente. Vale complementar com:

dmesg | grep -i xfs
dmesg | grep -i -E "ata|error"

Se aparecerem mensagens de metadata corruption ou I/O error próximas ao horário do incidente, e o SMART estiver limpo, a causa é praticamente confirmada: desligamento não-limpo, não hardware.

Passo 3 — Diagnóstico do filesystem, sempre em modo dry-run

Só depois de descartar hardware é que entramos no filesystem propriamente dito — e sempre começando pelo modo que não altera nada:

xfs_repair -n /dev/mapper/vg_data-lv_data

O -n reporta tudo o que o xfs_repair encontraria e corrigiria, sem escrever uma única mudança no disco. É essa saída que decide o próximo passo: se o problema é superficial (metadados secundários, contadores de blocos livres), o repair padrão resolve sem drama. Se o log estiver realmente corrompido, o comportamento muda.

Passo 4 — O reparo, com o filesystem desmontado

Ambiente ideal: filesystem desmontado, ou sistema em boot de rescue/live quando se trata da partição raiz.

umount /dev/mapper/vg_data-lv_data
xfs_repair /dev/mapper/vg_data-lv_data

Se o xfs_repair recusar rodar por causa de log sujo, a primeira tentativa é deixar o kernel fazer o replay do journal normalmente:

mount -t xfs /dev/mapper/vg_data-lv_data /mnt/tmp
umount /mnt/tmp
xfs_repair /dev/mapper/vg_data-lv_data

Só quando isso não é possível — o log está corrompido a ponto de nem permitir o mount — é que consideramos zerar o log:

xfs_repair -L /dev/mapper/vg_data-lv_data

Essa flag descarta qualquer transação não commitada. É uma operação com potencial de perda de dados recentes e deve ser tratada como último recurso, nunca como primeira tentativa — e idealmente precedida por um snapshot LVM, quando a infraestrutura permite:

lvcreate -s -L 10G -n snap_before_repair /dev/vg_data/lv_data

E em filesystems ext2/ext3/ext4?

A lógica é a mesma, com fsck ou e2fsck:

fsck -n /dev/sdb1                 # diagnóstico, sem alterar nada
umount /dev/sdb1
fsck -f -y /dev/sdb1              # reparo forçado, aceitando as correções automaticamente

A diferença estrutural é que XFS não tem um "modo fsck" tradicional — o xfs_repair é a própria ferramenta de reparo, e o journaling recovery normalmente acontece de forma automática no mount. Já em ext4, o fsck é interativo por natureza, e o -y serve justamente para automatizar as respostas em execuções não assistidas ou em scripts de boot.

O checklist que aplicamos antes de qualquer reparo

1. Desmontar o filesystem, ou operar via boot de rescue/live quando for a partição raiz

2. Snapshot LVM, sempre que a infraestrutura permitir

3. Checagem SMART completa do disco físico primeiro

4. Self-test ativo se o histórico ou os atributos gerarem dúvida

5. Diagnóstico em modo dry-run (-n) do filesystem antes do reparo real

6. Reparo padrão, escalando para -L (XFS) apenas como último recurso

7. Conferência do lost+found após o reparo

Por que isso importa em ambientes críticos

Em infraestrutura de saúde e indústria — os setores em que a Nyverra atua com maior intensidade —, um filesystem corrompido não é só um inconveniente técnico. Pode significar indisponibilidade de sistemas de prontuário eletrônico, interrupção de linha de produção monitorada por SCADA, ou perda de dados regulatórios. A diferença entre um incidente resolvido em minutos e uma recuperação de desastre de várias horas quase sempre está na disciplina do diagnóstico: entender a causa antes de aplicar a correção.

Reparo de filesystem não é operação de "tentar e ver o que acontece" — é uma sequência de decisões que depende de evidência, não de pressa.

A Nyverra é especializada em infraestrutura crítica de TI, virtualização e continuidade de negócio para clientes B2B nos setores de saúde e indústria. Conheça mais em nyverra.com.br.