Corrupción de filesystem en servidores críticos: cómo diagnosticar antes de salir reparando

Cuando un filesystem presenta error en un servidor de producción — especialmente en entornos con bases Oracle, ERPs o sistemas hospitalarios —, el instinto más común es ejecutar xfs_repair o fsck -y inmediatamente y esperar que el problema desaparezca. Ese es exactamente el tipo de decisión apresurada que transforma una corrupción puntual en una pérdida de datos irreversible.

En este artículo, mostramos el flujo de diagnóstico que aplicamos en Nyverra antes de cualquier reparo de filesystem: por qué el orden de las operaciones importa, cómo aislar si el problema es del disco físico o de una corrupción lógica, y los comandos que realmente separan un repair seguro de un desastre.

Por qué no ejecutar el repair de inmediato

xfs_repair y fsck son herramientas de último recurso — reconstruyen metadatos, mueven archivos huérfanos a lost+found y, en casos extremos, descartan transacciones del journal. Ejecutar estas herramientas sin entender la causa raíz del problema tiene dos riesgos:

1. Ejecutar en disco con falla física real. Si el problema es un sector defectuoso o un controlador degradándose, el repair puede reescribir metadatos sobre datos aún recuperables, o simplemente fallar a mitad del proceso, dejando el filesystem en peor estado del que estaba.

2. Ejecutar con el filesystem montado o en producción activa. Algunas flags del xfs_repair, como -d, existen justamente para permitir reparo en filesystem que el sistema operativo considera montado — y usarlas fuera de un escenario de rescue/live boot es una receta casi garantizada para agravar la corrupción, principalmente cuando el volumen en cuestión es la partición raíz del sistema.

Por eso, nuestro primer paso nunca es el reparo. Es la salud del disco.

Paso 1 — Descartar problema de hardware con SMART

Antes de tocar cualquier filesystem, validamos la salud física del disco:

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

Los atributos que más importan en esa verificación, principalmente en SSDs — cada vez más comunes en servidores de borde y entornos de virtualización —, son:

• Reallocated_Event_Count — sectores remapeados. Si es mayor que cero y creciendo, es señal de degradación de medios.

• Reported_Uncorrect — errores de lectura que el propio disco no pudo corregir.

• UDMA_CRC_Error_Count / SATA_CRC_Error_Count — generalmente apunta a problema de cable o conector, no del disco en sí.

• Media_Wearout_Indicator / SSD_Life_Left — desgaste de NAND acumulado.

• Unsafe_Shutdown_Count / Power-Off_Retract_Count — cuántas veces el disco sufrió un corte de energía sin apagado limpio. Ese número es el enlace más directo entre el historial del hardware y una corrupción de journal en XFS o ext4.

Si la lectura estática ya no es suficiente, ejecutamos un self-test activo:

smartctl -t short /dev/sda
# aguardar el tiempo estimado antes de consultar
smartctl -l selftest /dev/sda

El resultado que buscamos es Completed without error. Cualquier variación de eso — falla de lectura, timeout, abort — ya indica que el problema está en el disco, y en ese escenario el camino es sustitución del hardware antes de cualquier intento de reparo lógico, no lo contrario.

Paso 2 — Cruzar con el historial de shutdowns sucios

En entornos virtualizados o de pruebas, es común encontrar un Unsafe_Shutdown_Count alto incluso en discos saludables — el valor se acumula con cada reset de VM, caída de energía sin UPS, o kill de proceso de hypervisor sin pasar por un shutdown ACPI limpio.

Ese es el patrón clásico de corrupción XFS por journal incompleto: el disco está físicamente íntegro, pero el filesystem quedó en estado inconsistente porque la última operación de escritura no fue commiteada correctamente. Vale complementar con:

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

Si aparecen mensajes de metadata corruption o I/O error cerca del horario del incidente, y el SMART está limpio, la causa está prácticamente confirmada: apagado no limpio, no hardware.

Paso 3 — Diagnóstico del filesystem, siempre en modo dry-run

Solo después de descartar hardware entramos al filesystem propiamente dicho — y siempre comenzando por el modo que no altera nada:

xfs_repair -n /dev/mapper/vg_data-lv_data

El -n reporta todo lo que el xfs_repair encontraría y corregiría, sin escribir un solo cambio en el disco. Es esa salida la que decide el siguiente paso: si el problema es superficial (metadatos secundarios, contadores de bloques libres), el repair estándar lo resuelve sin drama. Si el log está realmente corrompido, el comportamiento cambia.

Paso 4 — El reparo, con el filesystem desmontado

Entorno ideal: filesystem desmontado, o sistema en boot de rescue/live cuando se trata de la partición raíz.

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

Si el xfs_repair se niega a ejecutar por causa de log sucio, el primer intento es dejar que el kernel haga el replay del journal normalmente:

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

Solo cuando eso no es posible — el log está corrompido hasta el punto de ni siquiera permitir el mount — consideramos zerar el log:

xfs_repair -L /dev/mapper/vg_data-lv_data

Esa flag descarta cualquier transacción no commiteada. Es una operación con potencial de pérdida de datos recientes y debe tratarse como último recurso, nunca como primera tentativa — e idealmente precedida por un snapshot LVM, cuando la infraestructura lo permite:

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

¿Y en filesystems ext2/ext3/ext4?

La lógica es la misma, con fsck o e2fsck:

fsck -n /dev/sdb1                 # diagnóstico, sin alterar nada
umount /dev/sdb1
fsck -f -y /dev/sdb1              # reparo forzado, aceptando las correcciones automáticamente

La diferencia estructural es que XFS no tiene un "modo fsck" tradicional — el xfs_repair es la propia herramienta de reparo, y el journaling recovery normalmente ocurre de forma automática en el mount. Ya en ext4, el fsck es interactivo por naturaleza, y el -y sirve justamente para automatizar las respuestas en ejecuciones no asistidas o en scripts de boot.

El checklist que aplicamos antes de cualquier reparo

1. Desmontar el filesystem, u operar vía boot de rescue/live cuando sea la partición raíz

2. Snapshot LVM, siempre que la infraestructura lo permita

3. Chequeo SMART completo del disco físico primero

4. Self-test activo si el historial o los atributos generan duda

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

6. Reparo estándar, escalando a -L (XFS) solo como último recurso

7. Comprobación del lost+found después del reparo

Por qué esto importa en entornos críticos

En infraestructura de salud e industria — los sectores en los que Nyverra actúa con mayor intensidad —, un filesystem corrompido no es solo un inconveniente técnico. Puede significar indisponibilidad de sistemas de prontuario electrónico, interrupción de línea de producción monitoreada por SCADA, o pérdida de datos regulatorios. La diferencia entre un incidente resuelto en minutos y una recuperación de desastre de varias horas casi siempre está en la disciplina del diagnóstico: entender la causa antes de aplicar la corrección.

Reparo de filesystem no es operación de "intentar y ver qué pasa" — es una secuencia de decisiones que depende de evidencia, no de prisa.

Nyverra es especialista en infraestructura crítica de TI, virtualización y continuidad de negocio para clientes B2B en los sectores de salud e industria. Conozca más en nyverra.com.br.