La recuperación de datos en servidores es sustancialmente más compleja que en equipos de escritorio. El sistema de archivos, la configuración de almacenamiento (RAID, LVM, Storage Spaces), la virtualización y el estado del hardware determinan qué técnicas son aplicables y cuáles pueden agravar el daño. Esta guía técnica analiza los escenarios más frecuentes en Windows Server y Linux, las herramientas disponibles y los límites de cada enfoque.
Servidor físico vs. servidor virtual: implicaciones para la recuperación
Antes de aplicar cualquier técnica de recuperación, es imprescindible identificar el tipo de entorno:
Servidor físico (bare-metal): Los datos residen directamente en los discos físicos del equipo, ya sean HDD, SSD o NVMe. Los fallos pueden ser mecánicos (cabezales, motor, platinas), electrónicos (PCB, firmware) o lógicos (sistema de archivos corrompido, partición perdida). La recuperación requiere acceso físico al hardware.
Servidor virtual (VMware ESXi, Hyper-V, KVM, Proxmox): Los datos del guest residen en archivos de imagen de disco (VMDK, VHD/VHDX, qcow2) almacenados en el host o en un datastore SAN/NAS. Si la máquina virtual no arranca pero el host está operativo, la recuperación es frecuentemente posible mediante herramientas de análisis de imágenes. Si el datastore ha fallado físicamente, el escenario es equivalente a un servidor físico.
Contenedores (Docker, Kubernetes): Los datos persistentes residen en volúmenes montados, cuyo backend puede ser un directorio local, un volumen LVM o un sistema de almacenamiento distribuido. La recuperación de contenedores con estado requiere identificar correctamente el backend de almacenamiento.
Windows Server: NTFS, ReFS y Storage Spaces
NTFS: el sistema de archivos más recuperable
NTFS (New Technology File System) es el sistema de archivos estándar en Windows Server hasta Server 2019. Sus características lo hacen relativamente favorable para la recuperación:
- MFT (Master File Table): NTFS mantiene dos copias de la MFT en posiciones distintas del volumen. Si la copia primaria está dañada, las herramientas de recuperación pueden usar la copia de respaldo para reconstruir el árbol de directorios.
- Journal de transacciones (\$LogFile): NTFS registra todas las operaciones de metadatos. En caso de corrupción por corte de luz o caída inesperada, el journal permite deshacer o rehacer operaciones incompletas.
- VSS (Volume Shadow Copy): Si el servicio VSS estaba activo, pueden existir copias shadow en el propio volumen. Herramientas como ShadowExplorer permiten acceder a versiones anteriores de archivos sin necesidad de restaurar backup.
Para fallos lógicos en NTFS (partición perdida, MFT dañada, formateo accidental), las herramientas con mejor tasa de éxito son R-Studio, GetDataBack y TestDisk (open-source). Sin embargo, estas herramientas solo funcionan correctamente cuando el disco subyacente está físicamente en buen estado. Si el disco hace ruidos extraños o no es reconocido por la BIOS, cualquier intento de lectura software puede agravar el daño.
ReFS: el nuevo sistema de archivos y sus limitaciones
ReFS (Resilient File System) fue introducido en Windows Server 2012 y es el sistema de archivos recomendado por Microsoft para Storage Spaces y cargas de trabajo de alta disponibilidad. Sus características de resiliencia son notables, pero presentan un problema importante para la recuperación:
ReFS tampoco soporta chkdsk para reparación interactiva ni algunas características de VSS en configuraciones específicas. Su principal ventaja —la detección y corrección automática de corrupción mediante checksums— no ayuda cuando el daño es mecánico o cuando el propio sistema de metadatos está afectado.
Storage Spaces y Storage Spaces Direct
Storage Spaces es la capa de virtualización de almacenamiento de Windows Server, equivalente a un software RAID con características adicionales. Storage Spaces Direct (S2D) extiende esto a clústeres hiper-convergidos. Los escenarios de fallo en Storage Spaces son especialmente delicados:
- Fallo de un disco en pool simple (sin redundancia): pérdida total de los datos en ese stripe. Sin backup, la recuperación requiere técnicas de laboratorio.
- Fallo en pool con mirror (equivalente a RAID 1/10): si el fallo es en un solo disco y el pool no estaba en reconstrucción, la recuperación lógica es posible.
- Fallo en pool con parity (equivalente a RAID 5/6): mismos riesgos que RAID 5 ante fallo de múltiples discos durante reconstrucción.
Linux: ext4, XFS, Btrfs y LVM
ext4: el caballo de batalla de Linux
ext4 es el sistema de archivos por defecto en Ubuntu, Debian, CentOS 7 y la mayoría de distribuciones Linux hasta hace pocos años. Para recuperación de datos en ext4:
- extundelete: recupera archivos eliminados en ext3/ext4 usando el journal. Funciona bien si el borrado es reciente y el disco no ha sido muy escrito desde entonces.
- ext4magic: herramienta más avanzada que analiza el journal de ext4 para reconstruir el estado anterior del sistema de archivos.
- TestDisk: recupera tablas de particiones y superblocks dañados en ext4. Herramienta esencial para particiones perdidas o corrompidas.
- PhotoRec: recuperación por firmas de archivo cuando la estructura del sistema de archivos está muy dañada. No recupera nombres de archivo ni estructura de directorios.
XFS: el sistema de archivos de alto rendimiento
XFS es el sistema de archivos por defecto en RHEL/CentOS 7+, Rocky Linux y AlmaLinux. Es especialmente popular en servidores con grandes volúmenes de datos. Presenta algunas peculiaridades importantes para la recuperación:
- XFS tiene un journal de alta eficiencia, pero no mantiene copias adicionales del superblock en la misma medida que ext4. Un superblock corrompido puede ser más problemático.
- xfs_repair es la herramienta de reparación nativa. Debe ejecutarse siempre sobre una copia imagen del disco, nunca directamente sobre el disco original.
- La recuperación de archivos eliminados en XFS es significativamente más difícil que en ext4 porque XFS no mantiene el mismo tipo de journal de datos. PhotoRec es frecuentemente la única opción para archivos borrados en XFS.
Btrfs: snapshots integrados y recuperación avanzada
Btrfs (B-tree filesystem) es el sistema de archivos por defecto en openSUSE, Fedora y SUSE Linux Enterprise. Su arquitectura basada en copy-on-write ofrece ventajas únicas para la recuperación:
- Snapshots nativos: si los snapshots estaban habilitados, puedes montar una versión anterior del sistema de archivos directamente, sin herramientas adicionales.
- Checksums en bloques de datos: Btrfs detecta corrupción silenciosa y puede autocorregirla en configuraciones RAID.
- btrfs check --repair: la herramienta de reparación de Btrfs es potente pero debe usarse con extrema cautela; en versiones anteriores podía causar daños adicionales.
LVM: la capa que complica la recuperación
LVM (Logical Volume Manager) añade una capa de abstracción entre los discos físicos y los sistemas de archivos. En caso de fallo, el proceso de recuperación tiene una complejidad adicional:
- Los metadatos LVM (PV, VG, LV) se almacenan en múltiples ubicaciones. Si están dañados, el sistema operativo no puede montar los volúmenes lógicos.
- vgcfgrestore puede restaurar los metadatos de un VG si existe una copia de seguridad automática en
/etc/lvm/archive/. - En LVM sobre mdadm (software RAID), la secuencia correcta de recuperación es: primero reconstruir el array RAID, luego recuperar LVM, finalmente acceder al sistema de archivos.
RAID en servidores: escenarios de fallo y límites del DIY
Los arrays RAID en servidores de producción presentan escenarios de recuperación especialmente complejos. La regla general es: cuanto más críticos son los datos y más discos han fallado, más necesario es un laboratorio profesional.
| Configuración RAID | Discos que pueden fallar | DIY posible | Recomendación |
|---|---|---|---|
| RAID 0 (striping) | 0 (sin redundancia) | Solo fallo lógico | Laboratorio si hay fallo físico |
| RAID 1 (espejo) | 1 de 2 | Sí, con precaución | Imagen del disco bueno antes de actuar |
| RAID 5 (parity) | 1 de N | Solo si falla exactamente 1 disco | Laboratorio si hay 2+ fallos o reconstrucción fallida |
| RAID 6 (double parity) | 2 de N | Sí, con más margen | Laboratorio si hay 3+ fallos |
| RAID 10 | 1 por espejo | Sí, si falla 1 por par | Laboratorio si fallan 2 del mismo espejo |
Regla de oro ante un RAID en estado crítico: nunca inicies una reconstrucción sobre discos que presentan errores SMART, nunca formatees el array y nunca cambies el orden de los discos en el controlador antes de haber creado imágenes sector a sector de cada unidad.
Recuperación de datos en servidores NAS
Los NAS empresariales (Synology, QNAP, NetGear ReadyNAS, Western Digital My Cloud) presentan una capa adicional: su propio sistema operativo y configuración RAID propietaria. Los puntos clave:
- Los NAS Synology y QNAP usan Linux internamente con mdadm para el RAID y ext4 o Btrfs para el sistema de archivos. Los discos son estándar SATA y pueden recuperarse en un servidor Linux.
- No inicialices el NAS si ha perdido la configuración: esto borra los metadatos del RAID y puede ser irreversible.
- Si el NAS no arranca pero los discos están intactos, en muchos casos los datos se pueden recuperar montando los discos individualmente en Linux.
Para más información sobre la recuperación de datos en NAS empresariales, consulta nuestra página de recuperación de datos para empresas o consulta los precios de recuperación 2026 para conocer los rangos de coste según el tipo de escenario.
Cuándo el DIY es peligroso y el laboratorio es necesario
Las herramientas de recuperación DIY (TestDisk, R-Studio, extundelete, PhotoRec) funcionan correctamente en escenarios de fallo lógico sobre discos físicamente sanos. Sin embargo, son insuficientes o contraproducentes en:
- Discos con sectores defectuosos progresivos: cada intento de lectura puede deteriorar más el disco.
- Discos con cabezales dañados: incluso una sola revolución puede rayar los platos.
- SSDs con controlador NAND fallido: requieren acceso directo a los chips de memoria.
- RAID con múltiples discos dañados: la reconstrucción del array requiere conocer parámetros exactos (orden de discos, tamaño de chunk, paridad).
- Corrupción severa de metadatos en ReFS, Btrfs o LVM: estructuras de datos complejas que pocas herramientas comerciales entienden completamente.
Si tu servidor cae en alguno de estos casos, el paso correcto es apagar el sistema, no manipular los discos y contactar con un laboratorio especializado. Puedes usar nuestra calculadora de precios para estimar el coste según tu configuración.
Preguntas frecuentes sobre recuperación de datos en servidores
ddrescue o dd antes de ejecutar cualquier herramienta de reparación. xfs_repair, fsck y chkdsk modifican el sistema de archivos y pueden eliminar la posibilidad de recuperación si la reparación falla a mitad.
WhatsApp