Recuperación ext4 vs XFS en Ubuntu 24.04: qué herramienta ejecutar primero (y por qué)

diciembre 3, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 9

¿Te fue útil?

Reiniciaste. La máquina no arrancó. O arrancó, pero un montaje pasó a solo lectura, las aplicaciones empezaron a mostrar errores de E/S y tu reflejo de “arreglo rápido” está a punto de pulsar fsck como un dedo nervioso sobre un gran botón rojo.

Este es el momento en que el orden de las herramientas importa más que la elección de la herramienta. Con ext4 y XFS, el primer movimiento equivocado puede convertir un problema de metadatos recuperable en una excavación arqueológica. El primer movimiento correcto suele parecer aburrido: identificar, aislar, hacer imagen/snapshot y luego reparar con las herramientas nativas del sistema de archivos en el orden preferido por ese sistema.

La gran regla: tu primera herramienta es “dejar de modificar el disco”

Si solo recuerdas una cosa: las herramientas de reparación de sistemas de archivos no son “diagnósticos de solo lectura”. Son cirujanos y, a veces, amputan para salvar al paciente. Tu primera herramienta es un botón de pausa: remonta en solo lectura, detén servicios y captura evidencias antes de mutar el estado.

Qué significa “primero” en la vida real

Cuando alguien dice “ejecuta fsck” o “ejecuta xfs_repair”, normalmente quiere decir “arréglalo ahora”. En operaciones, “primero” debería significar:

Confirma qué sistema de archivos estás tocando. La gente adivina mal más de lo que admite.
Confirma el mapeo del dispositivo. LVM, mdraid, multipath, espacios de nombre NVMe: tu intuición de /dev/sdX no es una estrategia.
Confirma el dominio de la falla. ¿Es el sistema de archivos, el dispositivo de bloque, el controlador o una capa superior (como dm-crypt, mdraid o almacenamiento virtualizado)?
Haz que el disco deje de cambiar. Si puedes hacer un snapshot, hazlo. Si puedes crear una imagen, hazlo. Si al menos puedes remount en solo lectura, hazlo.

Sólo entonces eliges la primera herramienta específica del sistema de archivos. En ext4, eso suele ser fsck.ext4 (a través de e2fsck) pero no siempre en modo “reparar todo”. En XFS, suele ser xfs_repair, pero a menudo precedido por xfs_repair -n o por una decisión deliberada sobre el log (-L no es un abrazo cálido).

Una regla más: si ves errores de hardware (timeouts, errores de medio, CRC), trata a las utilidades de reparación como secundarias. Arregla la fontanería primero o estarás reparando corrupción que sigue acumulándose.

Broma 1: Ejecutar herramientas de reparación en un disco moribundo es como repintar una casa durante un terremoto: no es culpa de la pintura, pero no terminará bien.

Y una verdad operativa que vale la pena fijar en tu canal de incidentes:

«La esperanza no es una estrategia.» — General Gordon R. Sullivan

Hechos y contexto que cambian las decisiones

Esto no es trivia. Explican por qué ext4 y XFS se comportan diferente ante fallos y por qué difiere la “primera herramienta”.

ext4 proviene de la línea de journaling de ext3, diseñado para compatibilidad amplia en Linux y recuperación predecible. Su journal suele hacer que los montajes tras un crash sean más resistentes que en sistemas de archivos más antiguos.
XFS se originó en SGI para sistemas IRIX de alto rendimiento y más tarde pasó al kernel Linux; está construido alrededor de estructuras de metadatos agresivas y escalabilidad.
XFS registra metadatos (el log), no los datos de archivo por defecto. Eso significa que después de un fallo puedes ver contenidos “limpios” que son semánticamente incorrectos porque las últimas escrituras no se completaron—especialmente en aplicaciones sin disciplina de fsync.
El modo “ordered” de datos de ext4 (frecuente por defecto) intenta vaciar los datos de archivo antes de confirmar metadatos relacionados, reduciendo algunas clases de punteros basura tras un crash, a coste de rendimiento.
XFS usa grupos de asignación (AGs) para escalar operaciones de metadatos en paralelo. La corrupción puede localizarse a un AG, lo cual es bueno; la reparación aún suele necesitar un escaneo completo, que no es rápido en volúmenes enormes.
ext4 puede hacer “chequeos de metadatos en línea” de forma limitada, pero inconsistencias serias normalmente requieren desmontar y ejecutar e2fsck. La reparación de XFS también es offline (desmontada) para arreglos reales.
XFS tiene un mecanismo de replay del log al montar. Si el propio log está corrupto, el montaje puede fallar. La gente se tienta a usar xfs_repair -L, que descarta el log—a veces necesario, a veces desastroso.
ext4 tiene sumas de comprobación de metadatos y del journal en kernels modernos; eso ayuda a detectar corrupción temprano, pero también significa que entornos de rescate antiguos pueden fallar con flags de características nuevas.
Los entornos de rescate de Ubuntu 24.04 importan: un live ISO demasiado antiguo puede no entender tus características de ext4 o los metadatos XFS v5, llevándote a diagnosticar mal “corrupción” que en realidad es “herramientas antiguas”.

Esos hechos apuntan a una conclusión sobria: ext4 tiende a flujos de trabajo “reparar con fsck”, mientras que XFS tiende a flujos de trabajo “diagnosticar primero, luego reparar con cautela”, con respeto especial por el log.

Qué herramienta ejecutar primero (ext4 vs XFS): la tabla de decisión

Antes de las herramientas del sistema de archivos: los primeros movimientos universales

La primera “herramienta” debería ser un conjunto de acciones, no un comando:

Detén las escrituras: para servicios, desmonta si es posible o remonta en solo lectura.
Valida la ruta del dispositivo: confirma si estás sobre una partición, LV de LVM, mdraid o mapeo dm-crypt.
Busca errores de hardware: dmesg, logs SMART/NVMe, estado RAID.
Haz snapshot o imagen si los datos importan: snapshot LVM, snapshot de almacenamiento o ddrescue si el hardware falla.

Ahora la primera herramienta específica del sistema de archivos

Aquí está el conjunto de reglas opinadas que uso en producción.

ext4: la primera herramienta suele ser `e2fsck`, pero comienza con “mirar, no tocar”

Si el sistema de archivos no se puede montar o se monta en solo lectura por errores: primero ejecuta e2fsck -fn (sin cambios) para estimar el daño y el riesgo. Luego decide si snapshot/imaginar y ejecutar una pasada de reparación.
Si sospechas corrupción severa o problemas de hardware: primero ejecuta comprobaciones SMART/NVMe y considera hacer imagen; luego ejecuta e2fsck sobre la imagen o snapshot.
Si el journal está en duda: puede que necesites e2fsck -f y, en algunos casos, reconstrucción del journal con tune2fs—pero no comiences por ahí.

XFS: la primera herramienta es `xfs_repair -n` (simulación), no `xfs_repair`

Si el montaje falla con errores del log: primero ejecuta xfs_repair -n para ver lo que haría. Si te dice que el log está sucio/corrupto, decide cuidadosamente si montar con recovery o descartar el log.
Usa xfs_repair -L solo cuando aceptes perder transacciones de metadatos recientes. Puede devolver el sistema de archivos pero a costa de olvidar “historia reciente”. A veces eso significa perder archivos completos o entradas de directorio creadas justo antes del crash.
Si el hardware está inestable: imagen primero. La reparación XFS es intensiva en metadatos y estresará un disco que está fallando.

Broma 2: xfs_repair -L es como borrar tu historial del navegador: resuelve un problema, pero no siempre el que realmente tienes.

La respuesta corta: por qué el orden difiere

El flujo de reparación de ext4 se basa en fsck como el corrector autoritativo y a menudo puede reproducir o reconciliar journals de forma relativamente determinista. XFS espera que el replay del log en tiempo de montaje maneje la recuperación común por crash y, cuando eso falla, el log se convierte en un punto de decisión. Por eso xfs_repair -n es la primera herramienta correcta para XFS: te dice si estás a punto de tomar una motosierra sobre el log.

Guion de diagnóstico rápido (encuentra el cuello de botella rápido)

Cuando el tiempo apremia, el objetivo no es “ser exhaustivo”. El objetivo es “identificar qué capa te está engañando”. Aquí tienes un orden rápido que funciona en Ubuntu 24.04 en flotas reales.

Paso 1: ¿Es hardware o transporte?

Revisa los logs del kernel en busca de errores de E/S/tiempos de espera. Si los ves, trata los síntomas del sistema de archivos como secundarios.
Revisa rápidamente la salud SMART/NVMe. Sectores reasignados, errores de medio, errores CRC o flags “critical_warning” de NVMe lo cambian todo.
Si es RAID: confirma la salud del array antes de ejecutar herramientas de reparación. Reparar encima de un array degradado/en reconstrucción puede estar bien, pero reparar encima de uno silenciosamente inconsistente es cómo se crea arte.

Paso 2: ¿El mapeo de bloques es correcto?

Confirma la identidad del dispositivo (UUID, WWN, serial). No confíes en /dev/sdX.
Confirma capas: ¿dm-crypt? ¿LVM? ¿mdraid? ¿multipath? ¿volumen en la nube?

Paso 3: ¿Qué sistema de archivos es y qué dice sobre sí mismo?

Identifica el tipo de FS y sus características sin montar (o monta en solo lectura si es seguro).
Para ext4: haz una pasada no destructiva de fsck para ver el alcance.
Para XFS: haz una reparación en modo dry-run para ver si el log es el problema.

Paso 4: Elige la vía de recuperación más segura

Los datos son irremplazables: imagen/snapshot primero, reparar después.
El servicio es irremplazable: haz failover primero, repara en paralelo.
Necesitas la máquina en 10 minutos: te tentarás a “solo ejecutar el corrector”. Haz al menos una pasada en solo lectura primero para saber qué arriesgas.

Tareas prácticas de recuperación (comandos, qué significa la salida y la decisión que tomas)

Estas son deliberadamente operativas: cada tarea incluye un comando, una salida de ejemplo, lo que significa y qué hacer a continuación. Ejecútalas desde una shell de rescate cuando sea posible (o al menos en modo usuario único). Sustituye los nombres de dispositivos con cuidado.

Tarea 1: Confirma qué está fallando (errores de montaje y estado actual)

cr0x@server:~$ findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS / /var /home
/ /dev/mapper/vg0-root ext4 rw,relatime,errors=remount-ro
/var /dev/nvme0n1p3 xfs ro,relatime
/home /dev/mapper/vg0-home ext4 rw,relatime

Significado: /var es XFS y ya está en solo lectura. Es una pista: o XFS detectó inconsistencia, o el kernel lo puso así por errores de E/S.

Decisión: Detén todo lo que escriba en /var. Si no puedes desmontar, mantenlo solo lectura y comienza con cheques de log/hardware antes de reparar.

Tarea 2: Identifica el tipo de sistema de archivos desde el dispositivo de bloque (sin adivinar)

cr0x@server:~$ lsblk -f /dev/nvme0n1
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1  vfat   FAT32       4C3A-1B2F                             510M     2% /boot/efi
├─nvme0n1p2
└─nvme0n1p3  xfs               3a2d0a3e-3f2e-4f2d-9d8a-0c2c8c9d6f11                /var

Significado: Es XFS en /dev/nvme0n1p3. Sin ambigüedad.

Decisión: Usa herramientas XFS (xfs_repair, xfs_metadump), no fsck (que no aplica a XFS de la misma manera).

Tarea 3: Revisa logs del kernel por errores de E/S antes de “reparar” corrupción

cr0x@server:~$ dmesg -T | egrep -i "I/O error|blk_update_request|nvme|ata|reset|xfs|ext4" | tail -n 25
[Mon Dec 29 09:41:11 2025] nvme nvme0: I/O 123 QID 6 timeout, aborting
[Mon Dec 29 09:41:12 2025] nvme nvme0: Abort status: 0x371
[Mon Dec 29 09:41:14 2025] XFS (nvme0n1p3): log I/O error -5
[Mon Dec 29 09:41:14 2025] XFS (nvme0n1p3): Log I/O Error Detected. Shutting down filesystem
[Mon Dec 29 09:41:14 2025] XFS (nvme0n1p3): Please unmount the filesystem and rectify the problem(s)

Significado: Esto no es “corrupción aleatoria del sistema de archivos”. El error de I/O del log es impulsado por timeouts del NVMe.

Decisión: Trata el dispositivo como sospechoso. Captura logs, considera problemas de controlador/firmware/PCIe y prioriza imagen/snapshot sobre reparaciones agresivas.

Tarea 4: Chequeo rápido SMART para discos SATA/SAS (si aplica)

cr0x@server:~$ sudo smartctl -H -A /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0-xx-generic] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x003e   199   199   000    Old_age   Always       -       12

Significado: Errores CRC sugieren problemas de cableado/controlador incluso cuando el disco “pasa”. Eso puede corromper escrituras y causar apagados del sistema de archivos.

Decisión: Arregla el transporte (cable/backplane/HBA) antes de reparar. Si es un servidor con bahías hot-swap, vuelve a asentar/reemplaza y vuelve a probar.

Tarea 5: Chequeo de salud NVMe (común en flotas Ubuntu 24.04)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 47 C
available_spare                     : 100%
percentage_used                     : 3%
media_errors                        : 0
num_err_log_entries                 : 18

Significado: Sin errores de medio, pero hay entradas en el log de errores. Combinado con timeouts en dmesg, huele a problemas de controlador/ruta más que a muerte de NAND.

Decisión: Extrae el log de errores NVMe, revisa eventos PCIe AER, considera actualizaciones de firmware. Aun así, haz snapshot/imagen antes de reparar si los datos son críticos.

Tarea 6: Confirma el estado de mdraid antes de tocar sistemas de archivos encima

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      976630336 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Significado: RAID1 está sano ([UU]).

Decisión: Al menos es seguro proceder a diagnósticos a nivel de sistema de archivos. Si vieras [U_] o reconstrucción, te detendrías y estabilizarías primero.

Tarea 7: Confirma el layout de LVM y cuál LV vas a operar

cr0x@server:~$ sudo lvs -a -o lv_name,vg_name,lv_size,lv_attr,devices
  LV   VG  LSize   Attr       Devices
  root vg0 80.00g  -wi-ao----  /dev/nvme0n1p2(0)
  var  vg0 200.00g -wi-ao----  /dev/nvme0n1p2(20480)
  home vg0 500.00g -wi-ao----  /dev/nvme0n1p2(71680)

Significado: /var podría ser un LV, no una partición cruda (en este ejemplo está en nvme0n1p2, no p3). Aquí es donde la gente repara la cosa equivocada.

Decisión: Repara el dispositivo de bloque correcto (ruta LV como /dev/vg0/var) y deja de usar suposiciones de partición.

Tarea 8: Haz un snapshot antes de reparar (LVM)

cr0x@server:~$ sudo lvcreate -L 20G -s -n var-pre-repair /dev/vg0/var
  Logical volume "var-pre-repair" created.

Significado: Ahora tienes un snapshot copy-on-write. No es una copia completa, pero es un punto de reversión frente a errores de reparación.

Decisión: Realiza la reparación en el LV original solo después de verificar que el espacio del snapshot es suficiente para las escrituras previstas durante la reparación (los escaneos de metadatos pueden escribir mucho).

Tarea 9: Para ext4, comienza con una comprobación no destructiva

cr0x@server:~$ sudo e2fsck -fn /dev/vg0/home
e2fsck 1.47.0 (5-Feb-2023)
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
/home: ***** FILE SYSTEM WAS MODIFIED *****
/home: 219842/32768000 files (0.2% non-contiguous), 4123712/131072000 blocks

Significado: Incluso con -n (sin cambios), informa “would be modified”. Eso indica inconsistencias que e2fsck puede arreglar.

Decisión: Si el hardware parece estable y tienes snapshot/imagen, procede a una pasada de reparación (e2fsck -fy) durante una ventana de mantenimiento. Si el hardware es inestable, imagina primero.

Tarea 10: Para ext4, realiza una pasada de reparación (controlada y registrada)

cr0x@server:~$ sudo e2fsck -fy /dev/vg0/home
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Inode 924518 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
Entry 'cache' in /user/alex (924612) has deleted/unused inode 1032211.  Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/home: ***** FILE SYSTEM WAS MODIFIED *****
/home: 219840/32768000 files (0.2% non-contiguous), 4123690/131072000 blocks

Significado: Arregló inconsistencias reales de metadatos. Espera que algunos archivos se muevan a lost+found si las entradas de directorio estaban dañadas.

Decisión: Monta y valida la integridad a nivel de aplicación (bases de datos, colas de correo, etc.). La consistencia del sistema de archivos no garantiza la consistencia de la aplicación.

Tarea 11: Para XFS, primero una reparación en modo dry-run

cr0x@server:~$ sudo xfs_repair -n /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
would zero log
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

Significado: La herramienta te está diciendo que dejaría el log a cero. Esa es la gran señal de alarma: el log no se puede reproducir tal cual.

Decisión: Decide si puedes aceptar perder operaciones de metadatos recientes. Si es un volumen de base de datos, considera restaurar desde backups de aplicación en lugar de forzar el descarte del log.

Tarea 12: Para XFS, intenta un montaje solo lectura para copiar datos (cuando sea factible)

cr0x@server:~$ sudo mount -o ro,norecovery /dev/vg0/var /mnt/var_ro
mount: /mnt/var_ro: mount(2) system call failed: Structure needs cleaning.

Significado: Incluso en solo lectura sin recovery no puede montarse. Los metadatos probablemente estén dañados más allá de la tolerancia de montaje.

Decisión: Procede a planear xfs_repair—idealmente sobre un snapshot/imagen.

Tarea 13: Para XFS, ejecuta la reparación (sin -L a menos que lo quieras)

cr0x@server:~$ sudo xfs_repair /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - found corruption in filesystem
        - resetting log...
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify link counts...
done

Significado: Reinició el log como parte de la reparación (algunas reparaciones implican manejo del log). En otras situaciones te verás forzado a elegir -L.

Decisión: Monta y valida. Si faltan archivos o los directorios se ven raros, planifica restaurar desde backups o reparar a nivel de aplicación.

Tarea 14: Para XFS cuando el log es irrecuperable: la decisión explícita -L

cr0x@server:~$ sudo xfs_repair -L /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
Phase 3 - for each AG...
Phase 4 - check for duplicate blocks...
Phase 5 - rebuild AG headers and trees...
Phase 6 - check inode connectivity...
Phase 7 - verify link counts...
done

Significado: Has descartado el log. Cualquier transacción de metadatos que estuviera solo en el log desaparece. Esto puede dejar archivos huérfanos o revertir cambios de directorio recientes.

Decisión: Haz esto solo si (a) tienes backups, (b) has aceptado la pérdida de cambios recientes y (c) la alternativa es “el sistema de archivos queda inaccesible”. Documenta la elección.

Tarea 15: Valida el montaje y revisa si vuelve a ponerse solo lectura después de reparar

cr0x@server:~$ sudo mount /dev/vg0/var /var
cr0x@server:~$ findmnt -no OPTIONS /var
rw,relatime,attr2,inode64,logbufs=8,logbsize=32k

Significado: Montado en lectura-escritura con opciones XFS normales. Buena señal.

Decisión: Vigila dmesg por nuevos errores de E/S. Si vuelve a pasar a solo lectura, estás persiguiendo inestabilidad de hardware, no un crash puntual.

Tarea 16: Revisa el journal y las características de ext4 (ayuda con problemas de “herramientas antiguas”)

cr0x@server:~$ sudo tune2fs -l /dev/vg0/home | egrep -i "Filesystem features|Filesystem state|Errors behavior|Journal"
Filesystem state:         clean
Errors behavior:          Continue
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit metadata_csum
Journal inode:            8

Significado: Características modernas de ext4 como metadata_csum requieren un e2fsck suficientemente nuevo. Ubuntu 24.04 está bien; medios de rescate antiguos podrían no estarlo.

Decisión: Si has arrancado en un entorno antiguo y se queja de características desconocidas, cambia a una imagen de rescate más moderna en lugar de “desactivar características” en pánico.

Tarea 17: Confirma la versión de metadatos de XFS (v5 vs anterior)

cr0x@server:~$ sudo xfs_info /dev/vg0/var
meta-data=/dev/vg0/var          isize=512    agcount=64, agsize=819200 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
data     =                       bsize=4096  blocks=52428800, imaxpct=25
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal               bsize=4096   blocks=25600, version=2
realtime =none                   extsz=4096   blocks=0, rtextents=0

Significado: crc=1 indica sumas de verificación de metadatos (características XFS v5). De nuevo: herramientas antiguas pueden comportarse mal.

Decisión: Asegura que tu entorno de rescate sea contemporáneo (Ubuntu 24.04 o similar) antes de interpretar errores como “corrupción”.

Tarea 18: Cuando el disco está muriendo, imagínalo con ddrescue (no con dd)

cr0x@server:~$ sudo ddrescue -f -n /dev/nvme0n1 /mnt/recovery/nvme0n1.img /mnt/recovery/nvme0n1.map
GNU ddrescue 1.28
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued:      0 B,  errsize:      0 B,  current rate:       0 B/s
ipos:         0 B,   errors:       0,    average rate:       0 B/s
opos:         0 B, run time:         0s,  remaining time:         0s
Finished

Significado: En ejecuciones reales verás bytes rescatados, tamaño de errores y conteo de errores. El archivo map permite reanudar y hacer reintentos más inteligentes después.

Decisión: Realiza las reparaciones del sistema de archivos sobre la imagen (loopback) o en un disco clonado. No estreses la fuente fallida con escaneos repetidos de metadatos.

Tres microhistorias corporativas desde las trincheras de reparación

1) El incidente causado por una suposición errónea

Tenían una flota de VMs Ubuntu, la mayoría ext4, porque eso era lo que su imagen base traía años atrás. Un día un nodo crítico de analítica dejó de montar /data. El on-call vio “Structure needs cleaning”, se encogió de hombros y tecleó fsck -y /dev/sdb porque la memoria muscular es imbatible.

El comando no “arregló” nada. Tampoco falló de manera que desatara pánico. Eso es parte de la trampa: fsck genérico puede seleccionar helpers, pero cuando el tipo de FS está mal identificado o el dispositivo es el equivocado, puedes no hacer nada útil o—peor—dañar un sistema de archivos adyacente porque apuntaste a la capa equivocada (partición vs LV vs disco completo).

El verdadero problema: /data era XFS sobre un LV de LVM, y el dispositivo que repararon era la partición PV subyacente. Así que ejecutaron una herramienta inapropiada, sobre un objetivo que no era el sistema de archivos, mientras el LV real seguía fallando.

Cuando se unió un ingeniero senior, hizo los pasos poco glamorosos: lsblk -f, lvs y findmnt. Luego xfs_repair -n mostró que el log estaba corrupto. La solución acabó siendo xfs_repair -L—aceptaron la pérdida de los últimos minutos de actualizaciones de directorio—seguido de restaurar un pequeño conjunto de salidas de aplicación desde upstream.

La lección real no fue “XFS da miedo”. Fue que la recuperación del sistema de archivos es ante todo un problema de mapeo. Si no sabes qué dispositivo de bloque respalda el montaje, estás jugando la lotería con el fin de semana de otra persona.

2) La optimización que salió mal

Un equipo de almacenamiento quería ingestión más rápida. Movieron una carga de trabajo de alto churn a XFS y afinó para rendimiento: buffers de log más grandes, paralelismo agresivo y escrituras de aplicación que confiaban en “el sistema de archivos lo manejará”. El rendimiento mejoró. Todos se felicitaron en la forma en que lo hacen las empresas: silenciosamente, y sólo después de que el panel se ponga en verde.

Entonces un evento de energía afectó un rack con una transferencia de UPS inestable. Los servidores sobrevivieron, en su mayoría. Pero varios nodos volvieron con XFS quejándose de recovery del log. El primer instinto del equipo fue estandarizar un paso de recuperación automatizado: si el montaje falla, ejecutar xfs_repair -L y reiniciar. Funcionó en pruebas. Funcionó en staging. Funcionó exactamente como funciona un cuchillo afilado.

En producción, devolvió los montajes, pero los datos de la aplicación eran inconsistentes. Algunos directorios perdieron archivos creados recientemente. Algunos archivos aparecieron con longitud cero. Lo peor: el servicio estaba “arriba”, así que sistemas downstream consumieron salidas dañadas antes de que alguien lo notara. Eso costó más que una hora extra de downtime habría costado.

El problema no fue XFS. Fue la suposición de que “sistema de archivos disponible” equivale a “aplicación correcta”, y que descartar el log es un valor por defecto seguro. El descarte del log en XFS es el último recurso. No es una línea de script para reinicios.

Después, impusieron dos políticas: (1) nunca ejecutar automáticamente el descarte del log; requiere aprobación humana, y (2) para datasets críticos, hacer failover y restaurar desde checkpoints conocidos en lugar de forzar que el sistema de archivos vuelva cojeando.

3) La práctica aburrida pero correcta que salvó el día

Una compañía de servicios financieros tenía una regla que molestaba a todos: antes de ejecutar cualquier herramienta de reparación, toma un snapshot o clona. Sin excepciones. Los ingenieros bromeaban que la política existía para protegerlos de sí mismos. La broma no estaba equivocada.

Un cierre de trimestre, una VM que ejecutaba procesamiento por lotes sufrió un fallo del almacenamiento a nivel de host. El kernel del huésped empezó a loguear errores de E/S y luego remontó volúmenes ext4 en solo lectura. Eso por sí solo fue buen comportamiento: ext4 intentando prevenir más daño. La presión era enorme porque los retrasos de fin de trimestre tienen una especial capacidad de escalar en la cadena gerencial.

El on-call siguió el playbook: detuvo escrituras, confirmó la estabilidad de hardware desde el lado del hipervisor, tomó un snapshot LVM en la capa de almacenamiento y luego ejecutó e2fsck -fn para acotar el daño. El informe mostró inodos y directorios dañados, reparables. Ejecutaron e2fsck -fy sobre el clon snapshot primero, validaron cheques a nivel de aplicación y luego repararon el volumen real.

Durante la reparación, e2fsck tomó una decisión que habría sido incómoda sin un rollback: limpió algunas entradas de directorio que apuntaban a inodos inválidos. El volumen volvió limpio, pero un árbol de directorio quedó parcialmente en lost+found. Porque tenían el snapshot, pudieron recuperar archivos específicos por inodo desde el estado previo a la reparación en lugar de restaurar todo.

No pasó nada heroico. Ese es el punto. La política aburrida—snapshot primero—convirtió un incidente estresante en una tarea de mantenimiento acotada.

Errores comunes: síntomas → causa raíz → solución

1) “Ejecuté fsck y no ayudó”

Síntomas: Ejecutaste fsck, el problema persiste o se quejó de “bad magic number”.

Causa raíz: Tipo de sistema de archivos incorrecto o dispositivo objetivo equivocado (partición/PV en lugar de LV, dispositivo md vs disco miembro).

Solución: Reidentifica con lsblk -f y findmnt. Usa e2fsck solo para ext* y xfs_repair para XFS. Repara la capa correcta (por ejemplo, /dev/vg0/var, no /dev/nvme0n1p2).

2) XFS no monta y de inmediato usaste `xfs_repair -L`

Síntomas: El montaje funciona después de reparar, pero faltan archivos “recientes” o los directorios parecen revertidos.

Causa raíz: El descarte del log pierde transacciones de metadatos que no se habían comprometido en las estructuras principales.

Solución: Prefiere xfs_repair -n primero; si debes usar -L, documenta y valida la integridad de la aplicación. Restaura salidas faltantes desde backups/checkpoints. Para bases de datos, prioriza herramientas de recuperación de DB y backups sobre heroicidades del sistema de archivos.

3) ext4 sigue remontándose en solo lectura después de que fsck “lo arregló”

Síntomas: ext4 se monta y luego pasa a ro; los logs del kernel muestran errores de E/S.

Causa raíz: Errores subyacentes en disco/controlador o ruta inestable, no metadatos no resueltos.

Solución: Revisa dmesg y logs SMART/NVMe. Reemplaza hardware, arregla cableado/backplane o migra datos fuera del dispositivo. Las herramientas de reparación no pueden hacer fiable un bus defectuoso.

4) Las reparaciones tardan una eternidad y asumes que la herramienta está colgada

Síntomas: e2fsck o xfs_repair corre por horas en volúmenes multi-TB.

Causa raíz: Los escaneos completos de metadatos son costosos; además, un disco con reintentos lentos hace que todo parezca bloqueado.

Solución: Confirma que el disco no está lanzando reintentos/timeouts en dmesg. Usa iostat para ver si hay progreso de I/O. Si el hardware está enfermo, imagina primero con ddrescue.

5) “Structure needs cleaning” en XFS y intentas montar en lectura-escritura de todos modos

Síntomas: El montaje falla; pruebas opciones de montaje; finalmente obtienes un montaje pero la corrupción empeora.

Causa raíz: Forzar montajes o replay sobre metadatos dañados puede amplificar el daño, especialmente con escrituras continuas.

Solución: Detén las escrituras. Usa xfs_repair -n y decide: copia en RO si es posible, o repara offline sobre un snapshot.

6) Reparaste el sistema de archivos pero la aplicación sigue rota

Síntomas: PostgreSQL no arranca, MySQL da errores o una cola tiene segmentos corruptos, aunque fsck/repair esté limpio.

Causa raíz: La integridad del sistema de archivos no es la integridad transaccional de la aplicación. Los crashes y los descartes de log pueden romper invariantes de más alto nivel.

Solución: Ejecuta recuperación a nivel de aplicación (recuperación DB, replay de WAL, reconstrucción de índices) o restaura desde backups conocidos. Trata la reparación del FS como “hacerlo montable”, no como “hacerlo correcto”.

Listas de verificación / plan paso a paso

Lista A: Los primeros 10 minutos (cualquier sistema de archivos)

Detén las escrituras: detén servicios, deshabilita cron/timers si hace falta.
Captura evidencia: guarda la salida de dmesg y logs relevantes.
Confirma el mapeo: findmnt, lsblk -f, lvs, /proc/mdstat.
Revisa indicadores de hardware: logs SMART/NVMe, estado RAID, logs de controlador.
Decide sobre snapshot/imagen: si el valor de los datos es alto, snapshot/imagen ahora, no después.

Lista B: Orden de recuperación ext4 (seguro primero)

Desmonta el sistema de archivos (preferido) o arranca en modo rescate.
Ejecuta una comprobación no destructiva: e2fsck -fn /dev/...
Si existen errores y el hardware es estable: ejecuta e2fsck -fy /dev/...
Montar en solo lectura primero si estás nervioso, luego en lectura-escritura.
Revisa dmesg por nuevos errores; si está limpio, procede con la validación a nivel de aplicación.

Lista C: Orden de recuperación XFS (diagnosticar, luego reparar deliberadamente)

Desmonta el sistema de archivos (requerido para reparación real).
Intenta montar en solo lectura con riesgo mínimo (opcional): mount -o ro,norecovery si funciona, copia datos.
Ejecuta xfs_repair -n para ver lo que haría la reparación.
Si el log está implicado, decide si el descarte del log es aceptable; prefiere restaurar antes que -L para cargas transaccionales críticas.
Ejecuta xfs_repair (y solo entonces, si es necesario, xfs_repair -L).
Monta y valida; ejecuta cheques a nivel de aplicación.

Lista D: Cuando el hardware es sospechoso

Detén todas las escrituras inmediatamente.
Imagina con ddrescue o clona mediante tu plataforma de almacenamiento.
Ejecuta reparaciones sobre el clon/imagen.
Planifica reemplazo/migración; no “reparar y rezar” sobre hardware inestable.

Preguntas frecuentes

1) ¿Puedo ejecutar `fsck` sobre XFS?

No en el sentido que piensas. XFS usa xfs_repair. fsck genérico no hará lo correcto para reparar metadatos XFS y puede desperdiciar tiempo valioso—o peor, apuntar al dispositivo equivocado.

2) ¿Siempre debo desmontar antes de ejecutar herramientas de reparación?

Sí para reparaciones reales. ext4 e2fsck y XFS xfs_repair están pensados para reparaciones offline. Ejecutarlas sobre un sistema de archivos montado es una buena manera de obtener “corrupción arreglada” más nueva corrupción.

3) ¿Por qué `xfs_repair -n` es tan importante?

Porque el manejo del log en XFS es un punto de decisión. -n muestra lo que la herramienta quiere hacer—especialmente si quiere zerear el log—antes de que te comprometas a perder transacciones de metadatos recientes.

4) ¿Cuándo está justificado `xfs_repair -L`?

Cuando el sistema de archivos está abajo, el replay del log no puede tener éxito y aceptas perder cambios recientes de metadatos. Úsalo como último recurso, preferiblemente después de snapshot/imagen y de considerar restauraciones para cargas transaccionales.

5) ext4 dice “clean” pero mi aplicación aún tiene datos faltantes. ¿Cómo?

La consistencia del sistema de archivos trata sobre estructuras de metadatos, no sobre la semántica transaccional de tu aplicación. Un crash puede dejar una app con escrituras parciales o fsyncs faltantes incluso cuando el sistema de archivos está perfectamente consistente.

6) ¿Qué pasa si el entorno de rescate es más antiguo que las características del sistema de archivos?

Puedes obtener informes falsos de “corrupción” o negación a operar. En ext4 y XFS de la era Ubuntu 24.04 (con sumas de metadatos), usa un sistema de rescate contemporáneo. No intentes desactivar características como atajo.

7) ¿Debo reparar en el disco original o en un clon?

Si los datos importan y puedes permitirlo, repara en un clon/snapshot/imagen. Te protege de errores y de degradación de hardware durante la reparación. Si no puedes, al menos haz un snapshot si estás en LVM o la plataforma de almacenamiento lo soporta.

8) ¿Cómo sé si la “corrupción” es en realidad hardware?

Los logs del kernel que muestran timeouts, resets, errores de I/O, errores CRC o abortos NVMe son tu señal más fuerte. Los logs SMART/NVMe y el estado del controlador RAID confirman el patrón. Si existen, estabiliza el hardware primero.

9) ¿Es ext4 “más fácil” de recuperar que XFS?

En muchos casos rutinarios, la recuperación de ext4 se siente más lineal porque e2fsck es la vía estándar. XFS es extremadamente robusto, pero la decisión sobre el log y el comportamiento de reparación exigen un poco más de precaución.

10) Después de reparar, ¿qué debo validar?

Opciones de montaje (rw vs ro), logs del kernel, recuentos de espacio libre/inodos y—lo más importante—chequeos de integridad a nivel de aplicación (chequeos DB, rebuild de colas, reindexados, checksums si los tienes).

Siguientes pasos que realmente puedes tomar

Si estás frente a un montaje roto en Ubuntu 24.04, no empieces con un corrector. Empieza con control: detén las escrituras, confirma el mapeo del dispositivo y determina si el hardware te está traicionando. Luego elige tu “primera herramienta del sistema de archivos” basada en el modelo de fallo del sistema:

ext4: comienza con e2fsck -fn para acotar, luego e2fsck -fy cuando estés listo para comprometer cambios.
XFS: comienza con xfs_repair -n. Trata el descarte del log (-L) como un intercambio deliberado, no como un reflejo.

Haz una cosa más que tu yo futuro apreciará: escribe lo que viste en dmesg, qué dispositivo operaste, qué flags usaste y por qué. A los retros de incidentes les encantan los hechos. A los sistemas de archivos también.