Recuperar datos de un servidor Linux: ext4, LVM y RAID software
La recuperación de datos en servidores Linux es significativamente más compleja que en sistemas Windows: los sistemas de archivos ext4, XFS o Btrfs, combinados con LVM y RAID software (md), crean capas de abstracción que dificultan la recuperación estándar. En RecuperaTusDatos contamos con técnicos especializados en entornos Linux empresariales, con experiencia en distribuciones Debian, Ubuntu Server, RHEL/CentOS, Rocky Linux y SUSE, capaces de recuperar desde una tabla de particiones corrompida hasta un RAID 5 md con múltiples fallos.
Recuperación servidor Linux — Datos clave
ext4, XFS, Btrfs, ZFS, ext3
LVM, RAID md, dm-crypt, LUKS
Desde 300€ (lógico Linux)
2-10 días laborables
- Escenarios de fallo más frecuentes en servidores Linux
- Protocolo de emergencia: qué hacer antes de todo
- Recuperación en ext4 y XFS: herramientas y proceso
- Recuperación de volúmenes LVM dañados
- RAID software (md): recuperación con múltiples discos dañados
- Btrfs y ZFS: casos especiales
- LUKS/dm-crypt: recuperación de volúmenes cifrados
- Cuándo necesitas un laboratorio profesional
- Preguntas frecuentes
Escenarios de fallo más frecuentes en servidores Linux
Los servidores Linux pueden perder datos por causas muy diversas. Estos son los casos que atendemos con mayor frecuencia en RecuperaTusDatos:
| Escenario | Causa habitual | Recuperabilidad |
|---|---|---|
| Superbloque ext4 corrupto | Apagón durante escritura, disco defectuoso | Alta (copias de superbloque) |
| rm -rf accidental | Error humano, script mal configurado | Media (depende de uso posterior) |
| LVM metadata corrupta | Operación pvmove/vgextend interrumpida | Alta (backup automático LVM) |
| RAID md degradado + fallo 2º disco | Disco ya degradado, 2º falla antes del rebuild | Media (según nivel RAID) |
| Partición borrada/mkfs accidental | fdisk/parted en disco equivocado | Alta (si sin sobreescritura) |
| Ransomware en servidor Linux | Intrusión SSH, exploit de servicio web | Media (shadow copies, si existen) |
| Corrupción Btrfs/ZFS | Checksum mismatch, RAID-Z fallo múltiple | Media-Alta (scrub + self-healing) |
Protocolo de emergencia: qué hacer antes de todo
- Nunca montes el sistema de archivos dañado en modo escritura (mount -o ro siempre)
- Nunca ejecutes fsck sin una imagen previa del disco. fsck puede destruir datos no recuperados
- Nunca hagas resize2fs ni lvresize en un volumen con problemas de metadatos
- No reinicies el servidor si el sistema de archivos está montado con errores: el journal puede aplicar operaciones pendientes destructivas
Pasos inmediatos correctos:
- Parar todos los servicios que escriban en el volumen afectado (
systemctl stop apache2 mysql postgresqletc.) - Crear una imagen bit a bit de cada disco afectado antes de cualquier operación:
ddrescue -d -r3 /dev/sda /mnt/backup/sda.img /mnt/backup/sda.log - Guardar el estado del RAID si hay md:
mdadm --detail /dev/md0 > /tmp/md_detail.txt - Exportar metadatos LVM:
vgcfgbackup -f /tmp/vg_backup.cfg nombreVG - Documentar: output de
lsblk,blkid,pvs,vgs,lvs,cat /proc/mdstat - Trabajar siempre sobre la imagen, nunca sobre el disco original
Recuperación en ext4 y XFS: herramientas y proceso
ext4: copias de superbloque y journal
ext4 distribuye múltiples copias del superbloque a lo largo del disco (en los grupos de bloques). Si el superbloque primario está corrupto, puede usarse uno de los de respaldo:
# Ver superbloques de respaldo disponibles:
mke2fs -n /dev/sdb1
# Usar superbloque de respaldo con e2fsck:
e2fsck -b 32768 /dev/sdb1
# O con la imagen (recomendado):
e2fsck -b 32768 /mnt/backup/sda.img
Para recuperar archivos eliminados en ext4, la herramienta más efectiva es extundelete:
extundelete /dev/sdb1 --restore-all --output-dir /mnt/recuperado/
Limitación importante: ext4 con dir_index habilitado (por defecto en kernels modernos) hace más difícil la recuperación de nombres de archivo. Los datos del archivo pueden existir pero el nombre puede haberse perdido.
XFS: journal y xfs_repair
XFS es más resistente a la corrupción gracias a su journal, pero más difícil de recuperar una vez dañado:
xfs_repair -n /dev/sdb1— modo diagnóstico sin modificarxfs_repair /dev/sdb1— reparación (¡solo tras imagen del disco!)- Si el log está corrupto:
xfs_repair -L /dev/sdb1(resetea el log, puede perder últimas transacciones) - Para recuperación de archivos borrados en XFS: xfs_undelete (limitado, XFS no tiene journal de datos)
Recuperación de volúmenes LVM dañados
LVM almacena sus metadatos (VG metadata) en el espacio de etiquetas de cada PV (Physical Volume) y también guarda copias de seguridad automáticas en /etc/lvm/backup/ y /etc/lvm/archive/. Esto hace que muchos casos de corrupción de metadatos LVM sean relativamente fáciles de resolver.
Restaurar VG metadata desde backup
# Ver backups disponibles:
ls -la /etc/lvm/archive/
# Restaurar desde backup:
vgcfgrestore -f /etc/lvm/archive/nombreVG_00001.vg nombreVG
# Activar el VG:
vgchange -ay nombreVG
# Montar en solo lectura:
mount -o ro /dev/nombreVG/nombreLV /mnt/recuperado
Reconstrucción manual de metadatos LVM
Si los archivos de backup también se han perdido (disco de sistema dañado), la reconstrucción manual de metadatos LVM requiere:
- Escanear los PVs para encontrar las etiquetas LVM:
pvck --dump headers /dev/sdb - Identificar el UUID de cada PV y reconstruir la estructura del VG
- Usar herramientas como lvm2 en modo forense o testdisk para identificar particiones LVM
- En casos complejos (thin pools, snapshot chains rotas), se requiere análisis manual de las estructuras de metadatos LVM
Cada hora que el servidor está reiniciándose o con fsck en modo automático puede reducir las posibilidades de recuperación. Contacta con RecuperaTusDatos: respuesta en menos de 2 horas, servicio urgente 24-48h para empresas.
Diagnóstico gratuito →RAID software (md): recuperación con múltiples discos dañados
El RAID software de Linux (md, administrado con mdadm) es muy resiliente, pero tiene puntos vulnerables específicos:
Situaciones frecuentes
| Situación | RAID 5 | RAID 6 | RAID 1 |
|---|---|---|---|
| 1 disco fallido | Degradado pero accesible | Degradado pero accesible | Accesible |
| 2 discos fallidos | Datos inaccesibles | Degradado pero accesible | Datos inaccesibles |
| Superbloque md corrupto | Recuperable con mdadm --examine | Recuperable | Recuperable |
| Chunk size/layout desconocidos | Requiere análisis forense | Requiere análisis forense | No aplica |
Reconstrucción manual de RAID 5 md
Si el RAID está caído pero los discos físicos funcionan, el proceso estándar es:
- Examinar cada disco:
mdadm --examine /dev/sdb /dev/sdc /dev/sdd - Remontar el array:
mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd - Si falla:
mdadm --assemble --force /dev/md0 /dev/sdb /dev/sdc /dev/sdd - Montar en solo lectura:
mount -o ro /dev/md0 /mnt/recuperado - Copiar datos antes de cualquier rebuild
Advertencia: No inicies nunca un rebuild (mdadm --manage --re-add) antes de tener los datos a salvo. Un rebuild fallido en el disco de paridad puede destruir datos en otros discos del array.
Btrfs y ZFS: casos especiales
Btrfs
Btrfs tiene capacidades de auto-reparación y snapshots nativos, pero también tiene puntos vulnerables únicos:
- btrfs check --repair puede empeorar la situación en algunos casos — úsalo solo como último recurso y con imagen previa
- btrfs restore puede extraer archivos de un sistema Btrfs dañado sin montar el volumen: es la herramienta preferida
- Los snapshots Btrfs pueden ser la forma más rápida de recuperarse de una operación destructiva accidental
- Corrupción del árbol de inodos (btree): puede requerir reconstrucción manual con herramientas forenses especializadas
ZFS
ZFS es el sistema de archivos más resistente a la corrupción gracias a checksums end-to-end, pero los fallos sí ocurren:
- zpool scrub detecta y autocorrige errores en RAID-Z1/Z2 automáticamente si hay discos buenos suficientes
- zpool import puede recuperar pools de pools dañados o discos movidos entre sistemas
- Eliminación accidental en ZFS sin snapshots: difícil. Con snapshots:
zfs rollbacko montar el snapshot - RAID-Z2 con 2 discos fallidos: el scrub puede reparar si los checksums permiten identificar los bloques correctos
LUKS/dm-crypt: recuperación de volúmenes cifrados
La recuperación de volúmenes LUKS cifrados tiene un requisito fundamental: la frase de paso o el archivo de clave. Sin ellos, la recuperación es técnicamente imposible (AES-256 XTS).
Escenarios recuperables con LUKS:
- Cabecera LUKS corrupta: Si tienes una copia de seguridad de la cabecera LUKS (
cryptsetup luksHeaderBackup), puedes restaurarla y desbloquear el volumen - Partición borrada que contiene LUKS: Si recuperas los sectores correctos y tienes la contraseña, puedes reensamblar el volumen
- LVM sobre LUKS: Primero abre LUKS (
cryptsetup open), luego reconstruye LVM
Consejo crítico: Haz siempre un backup de la cabecera LUKS (cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file luks_header.bin) y guárdalo en un lugar seguro separado del sistema. Sin él y sin la contraseña, los datos son irrecuperables.
Cuándo necesitas un laboratorio profesional
Los comandos y herramientas descritos funcionan cuando los discos físicos están sanos. Cuando hay daño físico o la situación es demasiado compleja, necesitas un laboratorio:
- Uno o más discos del RAID tienen daño físico (cabezales, sectores defectuosos masivos, PCB)
- El servidor tiene RAID 5 con 2 discos fallidos simultáneamente
- La recuperación de ext4/XFS mediante herramientas estándar no encuentra los archivos
- Hay LVM sobre RAID sobre LUKS y alguna capa está dañada
- El sistema tiene thin-provisioning LVM con pool dañado
- Se trata de un entorno VMware/KVM con VMDK/qcow2 dañado en el host
- El disco tiene sectores defectuosos que hacen que ddrescue tarde semanas en completar la imagen
En RecuperaTusDatos contamos con especialistas Linux certificados y con acceso a herramientas como R-Studio for Linux, PC-3000 Linux y kits personalizados de reconstrucción de RAID en entornos no estándar.
WhatsApp