Recuperación de datos de servidores Linux con filesystem ext4 y XFS

Los servidores Linux con sistemas de archivos ext4, XFS, Btrfs o ZFS son la columna vertebral de la infraestructura web y corporativa en todo el mundo. Su estabilidad es reconocida, pero no son invulnerables: un corte de corriente en el momento equivocado, un rm -rf ejecutado con la ruta incorrecta, un LVM redimensionado con error o un array mdadm con múltiples discos fallidos pueden dejar los datos completamente inaccesibles. En RecuperaTusDatos.es contamos con técnicos especializados en la arquitectura de almacenamiento Linux y las herramientas específicas para cada escenario.

Sistemas de archivos Linux: diferencias clave para la recuperación

ext4: el más recuperable

ext4 es el sistema de archivos predeterminado de la mayoría de distribuciones Linux (Debian, Ubuntu, CentOS/RHEL hasta la versión 7). Su estructura está muy bien documentada y existe una amplia gama de herramientas de recuperación:

• Journal recovery: ext4 mantiene un journal (registro de transacciones) que permite revertir escrituras incompletas tras un corte de corriente. Si el journal no está dañado, el fsck en el próximo arranque repara la mayoría de las inconsistencias automáticamente.
• Superbloque corrupto: ext4 almacena copias de seguridad del superbloque en múltiples grupos de bloques. Cuando el superbloque primario falla, se puede arrancar con e2fsck -b 32768 (o la ubicación correcta según mke2fs -n) para usar una copia de seguridad.
• Recuperación de inodos borrados: herramientas como extundelete y ext4magic analizan el journal y las tablas de inodos para localizar archivos borrados recientemente. La ventana de recuperación es corta: cada escritura posterior puede sobreescribir los bloques liberados.

XFS: potente pero exigente en recuperación

XFS es el sistema de archivos por defecto de RHEL/CentOS 7+ y Fedora. Diseñado para alto rendimiento con archivos grandes, su estructura interna es más compleja:

• xfs_repair: la herramienta oficial para reparar un XFS dañado. Requiere que el filesystem esté desmontado y puede tardar horas en volúmenes grandes. Un xfs_repair ejecutado sobre un volumen montado puede agravar el daño.
• Allocation Group corruption: XFS divide el volumen en Allocation Groups (AG) independientes. La corrupción de un AG puede aislar los datos de esa región sin afectar al resto del volumen. Nuestras herramientas permiten reconstruir los metadatos de un AG individual.
• Frozen filesystem: XFS puede quedar en estado "frozen" (congelado) tras un fallo de hardware, negándose a montarse sin reparación. En estos casos xfs_repair -L (limpiar el log) suele ser el primer paso.
• Limitación en recuperación de archivos borrados: XFS no mantiene información de inodos eliminados en el journal una vez que el espacio se marca como libre. La recuperación de archivos borrados en XFS es significativamente más difícil que en ext4 y depende de herramientas de carving por tipo de archivo.

LVM: una capa de abstracción que complica la recuperación

El Logical Volume Manager (LVM) añade una capa de abstracción entre los discos físicos y el sistema de archivos. Sus fallos específicos son:

• LV borrado accidentalmente: lvremove elimina los metadatos del LV pero los datos en los bloques físicos permanecen hasta ser sobreescritos. Si se actúa rápidamente y el VG no ha sido modificado, vgcfgrestore puede recuperar la configuración anterior.
• Corrupción de metadatos del VG: LVM almacena los metadatos del Volume Group en los primeros sectores de cada Physical Volume. Si estos se corrompen, el sistema no puede encontrar los LVs. Las copias de seguridad automáticas en /etc/lvm/archive/ son la primera línea de defensa.
• pvmove interrumpido: una migración de datos entre PVs interrumpida puede dejar bloques físicos en estado inconsistente, con datos parcialmente en el origen y parcialmente en el destino.

mdadm: RAID software de Linux

El software RAID del kernel Linux (mdadm) gestiona arrays RAID 0, 1, 5, 6 y 10. Los fallos más críticos son:

• Superbloque mdadm perdido o corrupto: cada disco del array almacena un superbloque mdadm con metadatos del array. Si el superbloque es incompatible o se corrompe (p.ej. tras un mdadm --zero-superblock accidental), el array no se puede ensamblar automáticamente.
• Array degradado con disco en fallo: un RAID 5 con un disco en estado failed sigue funcionando pero está en riesgo. Si un segundo disco falla antes de reconstruir el array, todos los datos se pierden.
• Reconstrucción forzada incorrecta: usar mdadm --create --assume-clean con los parámetros incorrectos (orden de discos, chunk size, nivel RAID) destruye los datos de paridad y hace irrecuperable el array por software.

ZFS en Linux: el más robusto y el más complejo de recuperar

ZFS (OpenZFS en Linux) ofrece la mayor integridad de datos de todos los sistemas mencionados, pero cuando falla lo hace de forma espectacular:

• Pool import failure: un pool ZFS que no puede importarse con zpool import suele indicar una corrupción de los uberblocks o un fallo en la cadena de metadatos Copy-on-Write.
• RAIDZ reconstruction: a diferencia de RAID 5, RAIDZ tiene un tamaño de stripe dinámico, lo que hace imposible su reconstrucción con herramientas RAID genéricas. Se necesita conocer la estructura interna de ZFS.
• zpool scrub con errores no corregibles: si el scrub detecta errores de checksum que no puede corregir (porque no hay suficientes copias de los datos), los bloques afectados quedan irrecuperables por las vías normales.

Causas más frecuentes de pérdida de datos en servidores Linux

¿Cuándo intentarlo uno mismo y cuándo llamar a un laboratorio?

Como regla general, puede intentar la recuperación por su cuenta si:

• El disco físico está en buen estado (sin ruidos, reconocido por el BIOS/UEFI)
• Es un fallo lógico simple (borrado accidental, superbloque dañado) en ext4
• Tiene experiencia con las herramientas e2fsck, extundelete o vgcfgrestore
• Ha hecho una imagen del disco antes de intentar nada (ddrescue)

Debe llamarnos si:

• El disco hace ruidos mecánicos (clics, arañazos)
• Es un array mdadm degradado con más de un disco comprometido
• Las herramientas de reparación han empeorado la situación
• El volumen LVM o ZFS no importa y no hay backup de metadatos
• Los datos son críticos y no puede permitirse un segundo fallo

Precios orientativos

Diagnóstico gratuito. Sin recuperación exitosa, sin coste.

Solicita tu diagnóstico gratuito

Te puede interesar

• › Recuperar datos de disco duro Linux: ext4, Btrfs y XFS
• › Recuperación de datos en Linux: ext4, Btrfs y XFS
• › ¿Qué es la Desfragmentación de Disco Duro y Cuándo Hacerla?
• › Recuperar datos con contraseña de BIOS o HDD password: guía técnica