Recuperación de Datos de Sistemas de Archivos ext4 en Linux
El sistema de archivos ext4 es el estándar en la mayoría de distribuciones Linux, pero cuando el superbloque se corrompe, el journal falla o la tabla de inodos sufre daños, el sistema puede volverse inaccesible por completo. Recuperar los datos requiere herramientas especializadas, imagen previa del disco y conocimiento profundo de las estructuras internas de ext4.
Arquitectura interna de ext4: lo que un técnico necesita entender
Antes de abordar la recuperación, conviene entender cómo ext4 organiza los datos en disco. El sistema divide la partición en grupos de bloques (block groups), cada uno con su propia copia de metadatos críticos. Esta redundancia es precisamente la que permite la recuperación cuando las estructuras principales fallan.
Cada grupo de bloques contiene:
- Superbloque: estructura maestra con tamaño del sistema de archivos, número de inodos, tamaño de bloque, estado del montaje y número de revisión. Ext4 guarda copias de superbloque en los grupos 0, 1, 3, 5, 7, 9… (potencias de 3, 5 y 7 en modo sparse_super).
- Descriptor de grupo (group descriptor): punteros a los bitmaps de bloques e inodos, y a la tabla de inodos del grupo.
- Bitmap de bloques: marca qué bloques de datos están en uso.
- Bitmap de inodos: indica qué inodos están asignados.
- Tabla de inodos: contiene todos los inodos del grupo. Cada inodo almacena permisos, timestamps, tamaño de archivo y punteros a bloques de datos.
En ext4 con extents (sustituto de los bloques indirectos de ext2/ext3), un inodo puede describir rangos contiguos de bloques en lugar de punteros individuales, lo que mejora el rendimiento pero cambia el análisis forense.
El journal de ext4: protección y punto de fallo
Ext4 usa un journal (registro por diario) para garantizar la coherencia ante caídas de corriente o reinicios forzados. Antes de escribir cambios en el sistema de archivos, los registra en el journal. Si el sistema cae, la siguiente vez que se monta, el kernel reproduce el journal para completar o deshacer operaciones pendientes.
El journal en ext4 puede operar en tres modos:
- journal: registra datos y metadatos. El más seguro, el más lento.
- ordered (predeterminado): solo registra metadatos, pero garantiza que los datos se escriben antes que los metadatos.
- writeback: solo metadatos, sin garantías de orden. El más rápido, el menos seguro.
Cuando el journal se corrompe, el kernel no puede reproducirlo y marca el sistema de archivos como inconsistente. El resultado habitual: el sistema no arranca o la partición aparece como no montable. Ejecutar fsck de forma incorrecta sobre un journal dañado puede sobrescribir datos recuperables, un error frecuente que convierte situaciones recuperables en pérdidas definitivas.
Corrupción del superbloque: diagnóstico y alternativas
El síntoma más común de corrupción del superbloque en ext4 es el mensaje:
EXT4-fs error: bad magic number in super-block
mount: wrong fs type, bad option, bad superblock on /dev/sda1La solución estándar es usar un superbloque de respaldo. El comando mke2fs -n /dev/sda1 lista las ubicaciones de superbloques de respaldo sin modificar el disco. Luego se puede intentar e2fsck -b 32768 /dev/sda1 para usar el superbloque del bloque 32768.
Sin embargo, esto solo funciona si el superbloque alternativo está intacto. En casos de daño físico severo (sectores defectuosos en múltiples zonas del disco), todos los superbloques pueden estar dañados. En ese escenario, los laboratorios especializados reconstruyen manualmente el superbloque calculando los valores correctos a partir del tamaño de partición, el tamaño de bloque predeterminado (normalmente 4096 bytes) y el UUID del sistema de archivos si se puede obtener de otra fuente (como el archivo /etc/fstab de un backup antiguo).
Daño en la tabla de inodos y el descriptor de grupo
Si el superbloque es accesible pero los archivos aparecen vacíos, con tamaño 0 o simplemente no existen, el problema suele estar en la tabla de inodos o en el descriptor de grupo.
La herramienta debugfs permite inspeccionar inodos individuales sin montar el sistema de archivos:
debugfs /dev/sda1
debugfs: stat /ruta/al/archivo
debugfs: dump /ruta/al/archivo /tmp/recuperadoPero cuando los descriptores de grupo están corruptos, debugfs tampoco puede acceder a los datos. En ese caso, la recuperación se basa en escaneo de firmas de archivo (file carving): buscar en el flujo de bloques del disco los encabezados conocidos de formatos de archivo (PDF, JPEG, ZIP, DOCX, etc.) independientemente de las estructuras del sistema de archivos.
El problema del carving en ext4 es la fragmentación: aunque ext4 intenta minimizarla mediante la asignación por extents, los archivos grandes fragmentados no se recuperan completos con carving simple. Los laboratorios combinan carving con análisis parcial de inodos para reconstruir la tabla de extents.
Limitaciones y riesgos de e2fsck
La herramienta oficial de reparación de ext4 es e2fsck. Aunque es potente, tiene limitaciones importantes en contextos de recuperación:
- e2fsck modifica el disco: cada vez que se ejecuta, puede sobrescribir inodos que marca como huérfanos, alterar bitmaps y truncar archivos con errores. Nunca debe ejecutarse directamente sobre el disco original.
- El directorio lost+found: e2fsck mueve inodos sin directorio padre a
lost+found. Los archivos recuperados así pierden su nombre original y estructura de directorios. - No recupera datos, repara metadatos: si los bloques de datos de un archivo han sido sobrescritos por otro, e2fsck no puede devolverlos.
- Falla ante daño físico: si el disco tiene sectores defectuosos en zonas críticas, e2fsck puede entrar en bucles o colgarse indefinidamente.
El protocolo correcto en un laboratorio es: imagen forense primero (con ddrescue o hardware especializado), y solo entonces trabajar sobre la imagen, nunca sobre el disco original.
LVM sobre ext4: una capa adicional de complejidad
En servidores Linux es habitual encontrar ext4 sobre LVM (Logical Volume Manager). LVM añade una capa de abstracción entre el disco físico y el sistema de archivos, lo que complica la recuperación de varias formas:
- Metadatos LVM dañados: el LVM guarda su configuración (Physical Volumes, Volume Groups, Logical Volumes) en los primeros sectores de cada PV. Si estos metadatos se corrompen, el sistema no puede ensamblar el VG y ext4 ni siquiera es visible.
- Striping y mirroring LVM: si el administrador configuró un LV en stripe (similar a RAID 0) sobre múltiples discos y uno falla, la recuperación requiere reconstruir el stripe manualmente.
- Snapshots LVM inconsistentes: los snapshots LVM que no se eliminaron correctamente pueden interferir con la montabilidad del LV original.
La recuperación en entornos LVM+ext4 pasa por reconstruir los metadatos LVM primero (usando vgcfgrestore si hay backup, o análisis manual del disco), ensamblar el VG manualmente y solo entonces abordar la recuperación ext4.
dm-crypt/LUKS: cuando el cifrado complica la recuperación
Muchos sistemas Linux modernos usan cifrado de disco completo con dm-crypt/LUKS sobre las particiones (o sobre los LV). LUKS almacena el encabezado de cifrado en los primeros 2 MB de la partición. Si ese encabezado se daña o se sobrescribe, los datos son irrecuperables por diseño criptográfico, incluso con el passphrase correcto.
En cambio, si el encabezado LUKS está intacto pero el sistema de archivos ext4 dentro del contenedor cifrado está dañado, la recuperación sigue los mismos pasos que para ext4 no cifrado: se abre el contenedor LUKS, se obtiene el dispositivo mapeado (por ejemplo /dev/mapper/datos) y se trabaja sobre él.
El punto crítico: nunca intentar herramientas de recuperación directamente sobre la partición LUKS sin abrirla primero. Las herramientas de carving no pueden atravesar el cifrado; leerían ruido aleatorio.
Causas frecuentes de corrupción en ext4
| Causa | Estructuras afectadas habitualmente | Recuperabilidad típica |
|---|---|---|
| Corte de corriente durante escritura | Journal, superbloque, inodos recientes | Alta (con imagen previa) |
| Desmontaje forzado / reset | Journal, bitmaps | Alta |
| Sectores defectuosos en zona de metadatos | Superbloque, tabla de inodos | Media-Alta |
| Fallo de cabezal en zona de metadatos | Todo el grupo de bloques afectado | Media (depende de extensión) |
| Borrado accidental de partición | Tabla de particiones (ext4 intacto) | Muy Alta |
| mkfs accidental sobre partición | Superbloque, tabla de inodos | Media (datos en bloques aún presentes) |
| LUKS header dañado | Encabezado de cifrado | Nula sin backup del header |
Cómo recuperamos datos ext4 sin superbloque funcional
El proceso en nuestro laboratorio sigue un protocolo estricto:
- Imagen forense completa: usamos hardware de duplicación (PC-3000, DeepSpar) que gestiona sectores defectuosos sin colgarse, creando una imagen byte a byte del disco.
- Análisis de estructuras ext4: examinamos los superbloques alternativos, descriptores de grupo y tabla de inodos en la imagen.
- Reconstrucción de metadatos: si todos los superbloques están dañados, recalculamos los valores del superbloque original y reconstruimos el descriptor de grupo 0.
- Extracción de inodos: escaneamos la imagen en busca de inodos válidos, aunque estén en bloques aparentemente no asignados por el bitmap.
- Reconstrucción de árbol de directorios: a partir de los inodos de directorio recuperados, reconstruimos la jerarquía de archivos y sus nombres originales.
- Verificación y entrega: verificamos la integridad de los archivos recuperados antes de la entrega.
En casos donde las estructuras ext4 están demasiado dañadas, recurrimos al carving combinado con análisis de extents para maximizar la recuperación de ficheros completos.
WhatsApp