Recuperación de datos en Linux: ext4, Btrfs y XFS

Los sistemas de archivos de Linux están diseñados para la robustez, pero ninguno es invulnerable. ext4 es el caballo de batalla de millones de servidores; Btrfs apuesta por checksums por bloque y snapshots atómicos; XFS destaca en entornos de alta concurrencia y ficheros grandes. Cuando fallan — por un corte eléctrico, un kernel panic, un disco degradado o un error humano — la recuperación exige conocer en profundidad cómo almacena cada sistema sus metadatos. Este artículo explica los mecanismos de fallo más frecuentes y las herramientas de recuperación disponibles.

ext4: journaling y recuperación de inodos

ext4 hereda el diseño de ext3 añadiendo extents, timestamps de nanosegundos y journal checksums. Su punto fuerte es el journaling en tres modos: journal (datos y metadatos), ordered (solo metadatos, por defecto) y writeback (metadatos sin orden). Cuando el sistema se apaga de forma abrupta, el journal permite reproducir las transacciones incompletas y dejar el sistema de archivos consistente en segundos.

fsck.ext4: cuándo usarlo y cuándo no

e2fsck -n /dev/sdX ejecuta un chequeo en solo lectura que muestra errores sin corregirlos; es el primer paso seguro. e2fsck -y /dev/sdX corrige automáticamente respondiendo sí a todo — peligroso en discos con sectores defectuosos porque puede borrar inodos válidos. Antes de cualquier fsck en un disco con problemas físicos se debe clonar byte a byte con ddrescue.

extundelete y debugfs

extundelete analiza el journal y los bloques de directorio para recuperar ficheros eliminados recientemente. debugfs permite acceso de bajo nivel: lsdel lista inodos eliminados, dump extrae el contenido de un inodo a un fichero. Ninguna herramienta garantiza recuperación si los bloques han sido sobreescritos; en ext4 con discard (TRIM en SSD), los bloques liberados pueden zeroearse inmediatamente.

Recuperación del superbloque

ext4 almacena copias de seguridad del superbloque en grupos de bloques alternos. Si el superbloque principal se corrompe: mke2fs -n /dev/sdX muestra dónde están los superbloques de respaldo, y e2fsck -b 32768 /dev/sdX arranca el chequeo desde uno de ellos.

Btrfs: snapshots, RAID y recuperación

Btrfs es el sistema de archivos copy-on-write (CoW) del kernel Linux. Su árbol de B-trees distribuye metadatos y datos con checksums SHA-256 por cada bloque, lo que permite detectar corrupción silenciosa (bitrot). Esta arquitectura hace la recuperación más compleja que en ext4.

Perfiles RAID en Btrfs

Advertencia crítica: los perfiles RAID5 y RAID6 de Btrfs tienen bugs de write hole conocidos desde hace años. En producción con datos críticos se recomienda usar mdadm para el RAID y Btrfs encima, o usar RAID1/RAID1c3 en su lugar.

Scrub y balance

btrfs scrub start /mountpoint lee todos los datos y metadatos verificando checksums; corrige errores si hay copia redundante disponible. btrfs balance start /mountpoint redistribuye bloques entre dispositivos; si se interrumpe con el sistema de archivos en estado inconsistente puede dejar chunks sin asignar. Ambas operaciones deben ejecutarse con la partición montada en modo lectura-escritura.

Cuándo los snapshots ayudan y cuándo no

Los snapshots de Btrfs son subvolúmenes de solo lectura que referencian bloques CoW. Ayudan ante borrado accidental o ransomware — siempre que el snapshot se haya creado antes del incidente y no esté en el mismo pool comprometido. No ayudan cuando el disco falla físicamente: si el disco muere, el snapshot muere con él. Tampoco protegen contra corrupción que ya existía antes de crear el snapshot.

btrfs-restore y btrfs check

btrfs check --readonly /dev/sdX analiza la coherencia sin modificar nada. btrfs restore /dev/sdX /destino extrae ficheros aunque el árbol de directorios esté parcialmente corrupto. btrfs check --repair debe usarse solo con copia de seguridad previa; puede destruir datos al intentar corregir errores.

XFS: metadatos en árbol B+ y xfs_repair

XFS es el sistema de archivos por defecto en RHEL, CentOS y Amazon Linux. Diseñado para alto rendimiento con ficheros grandes, usa un log interno para journaling de metadatos. Su punto débil histórico: no soporta reducción de tamaño (shrink) y el log corrupto puede impedir el montaje.

xfs_repair: la herramienta principal

xfs_repair -n /dev/sdX modo dry-run. Si el log está sucio (shutdown incorrecto), xfs_repair se niega a actuar por seguridad; xfs_repair -L /dev/sdX fuerza el zeroing del log — puede causar pérdida de transacciones no confirmadas, pero habitualmente es necesario cuando el sistema no monta.

xfs_metadump y xfs_db

xfs_metadump /dev/sdX metadump.img captura todos los metadatos (sin datos de usuario) para análisis forense sin tocar el disco original. xfs_db es el debugger interactivo que permite inspeccionar superbloques, inodos y árboles B+ directamente.

Journal replay y recuperación de inodos

A diferencia de ext4, XFS no tiene herramientas maduras de recuperación de ficheros eliminados como extundelete. La recuperación de ficheros borrados en XFS requiere carving binario (PhotoRec, Scalpel) o análisis manual con xfs_db. La tasa de éxito depende de cuánto ha sido sobreescrito el espacio libre.

LVM: volúmenes lógicos y recuperación

LVM añade una capa de abstracción entre el hardware y el sistema de archivos. Un Physical Volume (PV) corrupto puede dejar inaccesible un Volume Group (VG) completo aunque los demás discos estén intactos.

• vgcfgrestore: restaura los metadatos del VG desde el backup automático en /etc/lvm/backup/. LVM hace backup de configuración en cada cambio.
• pvck y vgck: verifican la consistencia de PVs y VGs respectivamente.
• LVM snapshots: como los de Btrfs, no protegen contra fallo del disco subyacente; sí permiten rollback ante corrupción lógica.
• thin provisioning: si el pool thin se corrompe, todos los thin volumes del pool quedan afectados simultáneamente. Mayor riesgo que LVM clásico.

mdadm: RAID por software en Linux

mdadm gestiona arrays RAID0, RAID1, RAID5, RAID6 y RAID10 por software. Los fallos más comunes son: disco marcado como faulty durante un rebuild, array degradado por corte eléctrico, superbloque md corrupto.

mdadm --examine /dev/sdX muestra el superbloque md del disco. mdadm --assemble --force /dev/md0 /dev/sda /dev/sdb /dev/sdc fuerza el ensamblado aunque algún disco tenga el evento count desincronizado. Con RAID5/6, si dos discos fallan simultáneamente el array es irrecuperable sin laboratorio.

Precios de recuperación en Linux

Pasos antes de intentar la recuperación

1. No montar el sistema de archivos dañado en modo lectura-escritura. Cada escritura sobreescribe potenciales datos recuperables.
2. Clonar con ddrescue: ddrescue -d -r3 /dev/sdX /ruta/imagen.img /ruta/imagen.log. Trabajar siempre sobre la imagen, nunca sobre el disco original.
3. Documentar el estado: smartctl -a /dev/sdX, dmesg | grep -i error, registros de kernel.
4. Evaluar daño físico: ruidos mecánicos o sectores defectuosos extendidos indican daño físico; deriva al laboratorio.

Cuándo acudir a un laboratorio profesional

Las herramientas por software tienen sus límites. Si el disco emite clics (clic de la muerte), si smartctl reporta reallocated sectors en crecimiento, si ddrescue no puede leer más del 20% del disco o si se trata de un SSD con controladora NVMe dañada, las herramientas descritas no serán suficientes. En esos casos, solicitar diagnóstico gratuito — la evaluación inicial no tiene coste y permite conocer las posibilidades reales antes de comprometerse económicamente.

Te puede interesar

• › Recuperar datos de disco duro Linux: ext4, Btrfs y XFS
• › Recuperación de datos de servidores Linux con filesystem ext4 y XFS
• › HDD vs SSD: diferencias, durabilidad y cul se recupera mejor
• › Recuperación de Datos de Discos Cifrados con LUKS en Linux