Recuperación de datos para empresas: servidores, RAID y NAS [2026]

La pérdida de datos en un entorno corporativo no es un incidente menor: cuando el servidor NAS que alberga los 20 TB del ERP cae, cuando un array RAID 5 pierde el segundo disco durante la reconstrucción o cuando el ransomware cifra la base de datos SQL Server de producción, cada hora sin datos tiene un coste medible. Esta guía técnica está dirigida a responsables de sistemas y directores de TI y cubre todos los escenarios de recuperación de datos empresarial: RAID, NAS, SAN, máquinas virtuales, bases de datos, ransomware y las garantías legales y de confidencialidad que exige el entorno corporativo.

Recuperación empresarial vs. consumidor: diferencias clave

Un disco duro doméstico y un servidor de producción comparten la misma tecnología de almacenamiento magnético o de estado sólido, pero las diferencias en el proceso de recuperación son sustanciales. Comprender estas diferencias es el primer paso para valorar la complejidad técnica y el coste de una recuperación corporativa.

Protocolos de interfaz distintos

Los discos de servidor utilizan mayoritariamente interfaces SAS (Serial Attached SCSI) o NL-SAS en lugar del SATA convencional de los equipos de escritorio. Los discos SAS funcionan a velocidades de rotación superiores (10.000 o 15.000 RPM), gestionan los errores de forma diferente —con tiempos de reintento más agresivos que pueden hacer que el disco se desconecte antes de que el sistema pueda completar la lectura— y presentan tamaños de sector de 512n, 512e o 4Kn que no son intercambiables entre sí. La recuperación exige hardware de lectura compatibles con el protocolo SAS y software capaz de gestionar la traducción de sectores.

Complejidad del entorno: capas sobre capas

En un entorno doméstico, los datos residen directamente en el sistema de ficheros del disco. En un servidor corporativo, los datos pueden estar distribuidos en un array RAID lógico, dentro de un volumen gestionado por un LVM, sobre un sistema de ficheros ext4, XFS o NTFS, dentro de un fichero de base de datos que a su vez organiza los datos en páginas y extensiones, y todo ello posiblemente dentro de un fichero de disco de máquina virtual montado sobre un datastore. Un fallo en cualquiera de estas capas puede impedir el acceso a los datos, y la recuperación requiere trabajar de dentro hacia afuera reconstruyendo cada capa.

El volumen de datos importa

Un servidor NAS con 20 TB de datos del ERP no puede tratarse como un disco externo de 2 TB. El proceso de clonado forense bit a bit de cada disco del array —paso imprescindible antes de cualquier intervención— puede requerir horas o días dependiendo del estado de los discos. Los sectores defectuosos obligan a reintentar múltiples lecturas, y en discos muy deteriorados cada sector puede consumir varios segundos. El dimensionamiento correcto del tiempo de proceso y la gestión de expectativas con el cliente son parte esencial del servicio corporativo.

Sin margen para el error

En un entorno doméstico, un intento de recuperación fallido puede suponer perder algunos archivos. En un entorno corporativo, un procedimiento incorrecto sobre un array RAID puede destruir permanentemente terabytes de datos que son la razón de ser del negocio. Esta es la diferencia fundamental entre un servicio de recuperación profesional para empresas y una herramienta de software genérica: el protocolo de clonado forense previo garantiza que siempre existe una imagen de los discos originales antes de cualquier manipulación.

Reconstrucción de RAID: RAID 5, RAID 6 y RAID 10

Los sistemas RAID son la columna vertebral del almacenamiento en la mayoría de servidores y NAS empresariales. Ofrecen redundancia frente a ciertos fallos, pero cuando las condiciones superan su tolerancia —o cuando el propio controlador falla— los datos quedan completamente inaccesibles. La recuperación requiere reconstruir el array virtual a partir de los discos físicos individuales.

RAID 5: el más común y el más vulnerable a la doble avería

El RAID 5 distribuye los datos y la información de paridad entre todos los discos del array, tolerando el fallo de un único disco. El escenario de pérdida más frecuente que atendemos en empresas es el siguiente: el sistema de monitorización avisa de que un disco ha fallado, el administrador de sistemas programa la sustitución para el fin de semana, y antes de que llegue ese momento falla un segundo disco —habitualmente del mismo lote, con el mismo desgaste acumulado— dejando el array en estado irrecuperable para el controlador.

La recuperación profesional de un RAID 5 con doble fallo requiere determinar, sin acceso a la configuración del controlador original, los siguientes parámetros: tamaño de bloque (stripe size), orden exacto de los discos en el array, offset de inicio de datos y dirección y algoritmo de rotación de paridad (left-symmetric, right-asymmetric, etc.). Un error en cualquiera de estos parámetros produce datos ilegibles o corrompidos. El proceso se realiza mediante análisis forense de los sectores y verificación cruzada de las secuencias de paridad.

RAID 6: doble paridad, pero no inmune

El RAID 6 añade una segunda banda de paridad independiente, tolerando el fallo simultáneo de dos discos. Es la configuración preferida para arrays de gran capacidad donde el tiempo de reconstrucción —que puede durar días en volúmenes de varios terabytes— expone al sistema a una segunda avería. Sin embargo, el RAID 6 falla con frecuencia por causas que van más allá de la tolerancia a fallos de disco: corrupción de los metadatos del array almacenados en la controladora, actualización de firmware que altera la interpretación de los parámetros del RAID, o errores lógicos que hacen que el volumen aparezca como no inicializado aunque los datos estén físicamente intactos.

RAID 10: alta disponibilidad, recuperación más sencilla

El RAID 10 combina mirroring y striping: los datos se distribuyen en bandas entre pares de discos espejo. Tolera múltiples fallos siempre que no sean los dos discos de un mismo par. Es la configuración más habitual en bases de datos de alto rendimiento y servidores de virtualización donde el rendimiento y la disponibilidad son prioritarios. La recuperación de un RAID 10 es generalmente más sencilla que la de un RAID 5 o 6, ya que basta con recuperar uno de los discos de cada par espejo para reconstruir el volumen completo. La tasa de éxito es correspondientemente alta.

Controladoras hardware vs. software RAID

Las controladoras RAID hardware (HPE Smart Array, Dell PERC, LSI MegaRAID, Adaptec) almacenan los metadatos del array en la propia controladora y en los discos. Cuando la controladora falla, los discos no son reconocidos por otra controladora del mismo modelo, y mucho menos por un PC estándar. La recuperación requiere replicar virtualmente el comportamiento de la controladora original. Los software RAID (mdadm en Linux, Espacios de almacenamiento en Windows Server, ZFS) son más transparentes en cuanto a metadatos, pero presentan sus propias complejidades cuando el sistema operativo falla o cuando la tabla de particiones se corrompe.

NAS (Synology, QNAP) y SAN/iSCSI: recuperación especializada

Los sistemas NAS y SAN son los pilares del almacenamiento centralizado en empresas de tamaño medio. Su recuperación combina las complejidades del RAID con las particularidades de los sistemas operativos y sistemas de ficheros propietarios que los fabricantes utilizan.

NAS Synology: DSM, Btrfs y SHR

Los NAS Synology funcionan con DSM (DiskStation Manager), un sistema operativo basado en Linux que utiliza mdadm para la gestión RAID y, en los modelos modernos, el sistema de ficheros Btrfs con soporte de snapshots. La configuración SHR (Synology Hybrid RAID) es especialmente habitual en PYMEs: permite mezclar discos de distinto tamaño optimizando la capacidad, pero genera una estructura RAID no estándar que las herramientas genéricas no reconocen. Cuando un NAS Synology falla —ya sea por corrupción del volumen, fallo múltiple de discos o una actualización de DSM que deja el sistema inaccesible— la recuperación requiere conocer los parámetros exactos del SHR configurado y reconstruir el volumen virtualmente antes de acceder a los datos.

El escenario más crítico que tratamos: el NAS Synology con 20 TB de datos del ERP de la empresa deja de arrancar tras un corte de luz. El panel de control muestra el array en estado "degradado" o directamente "no disponible". Si el NAS contiene los backups de la empresa además de los datos de producción —práctica habitual pero peligrosa—, no existe copia alternativa. Diagnóstico, clonado forense de todos los discos y reconstrucción virtual del volumen SHR son los pasos a seguir.

NAS QNAP: QTS, ext4 y configuraciones RAID avanzadas

Los NAS QNAP funcionan con QTS (también Linux-based) y utilizan mayoritariamente ext4 como sistema de ficheros, aunque los modelos recientes soportan también ZFS. QNAP es frecuente en empresas que requieren iSCSI para proporcionar almacenamiento en bloque a servidores virtualizados: en este caso el NAS actúa como target iSCSI y el servidor accede a un LUN como si fuera un disco local. La recuperación de estos entornos requiere reconstruir tanto el array RAID del NAS como la estructura interna del LUN iSCSI.

SAN empresarial: Dell EMC, NetApp, HPE MSA

Las redes SAN (Storage Area Network) de gama empresarial —Dell EMC PowerStore, NetApp ONTAP, HPE MSA— añaden una capa adicional de abstracción sobre el RAID físico mediante LUNs virtuales, thin provisioning y sistemas de ficheros propietarios (WAFL en NetApp, VMFS en los datastores de VMware). La recuperación en estos entornos exige herramientas y conocimiento especializado de cada plataforma. El diagnóstico inicial debe determinar si el fallo es físico (discos), lógico (metadatos del array o del volumen) o de configuración (pérdida de la configuración del controlador), ya que el abordaje es diferente en cada caso.

Máquinas virtuales: VMware VMDK y Hyper-V VHD/VHDX

La virtualización es estándar en cualquier infraestructura corporativa moderna. VMware vSphere/ESXi y Microsoft Hyper-V albergan conjuntamente la mayoría de los servidores de producción de PYMEs y grandes empresas en España. La recuperación de datos de máquinas virtuales presenta desafíos únicos: el disco virtual es un fichero dentro de un sistema de ficheros, que a su vez está sobre un datastore que puede estar sobre un array RAID. Cada capa añade complejidad.

VMware: VMDK y datastores VMFS

En un entorno VMware, los discos de las máquinas virtuales se almacenan como ficheros .vmdk sobre datastores formateados con VMFS (VMware File System). Los escenarios de fallo más habituales son: corrupción del fichero VMDK que impide a ESXi montar la máquina virtual (el hipervisor rechaza registrar el disco y muestra errores en vCenter), snapshots acumulados durante meses que generan cadenas de ficheros delta cuya consolidación falla y corrompe el disco, y datastores que quedan inaccesibles por corrupción de los metadatos VMFS tras un fallo de alimentación o un crash del host ESXi.

La recuperación de un VMDK corrompido requiere reparar la estructura de descriptores del fichero de disco virtual antes de intentar montar su contenido. En muchos casos, aunque el VMDK sea irreparable como contenedor, es posible extraer directamente los datos del interior montando el fichero mediante herramientas forenses y accediendo al sistema de ficheros (NTFS o ext4) del sistema operativo virtual.

Hyper-V: VHD, VHDX y checkpoints

Microsoft Hyper-V utiliza los formatos VHD (hasta 2 TB) y VHDX (hasta 64 TB, con mejor resiliencia ante fallos de alimentación). Los VHDX incluyen metadatos de registro que les permiten recuperarse de interrupciones abruptas, pero esto no los hace inmunes a la corrupción: una actualización de Windows que falla a mitad de la escritura de un checkpoint, o un almacenamiento subyacente con sectores defectuosos, puede dejar el VHDX en un estado en que Hyper-V lo detecta como corrompido y se niega a iniciarlo.

Los checkpoints de Hyper-V (equivalentes a los snapshots de VMware) generan ficheros .avhd o .avhdx en cadena. Si se acumulan durante meses y el disco base o algún fichero intermedio de la cadena se corrompe, la máquina virtual completa queda inaccesible aunque los datos de las capas superiores estén intactos. La recuperación requiere reconstruir la cadena de diferenciación de forma manual.

Recuperación de bases de datos: SQL Server, Oracle y MySQL InnoDB

Las bases de datos son el activo más crítico de la mayoría de las empresas: contienen los datos del ERP, el CRM, el historial de transacciones, la contabilidad y en muchos casos la razón de ser completa del negocio. La recuperación de una base de datos corrupta es una especialidad dentro de la recuperación de datos que combina ingeniería de almacenamiento con conocimiento profundo de los formatos internos de cada motor de base de datos.

SQL Server: ficheros MDF y LDF

Microsoft SQL Server almacena los datos en ficheros .mdf (datos principales) y .ldf (registro de transacciones), con posibles ficheros .ndf adicionales para grupos de ficheros secundarios. La estructura interna del .mdf organiza los datos en páginas de 8 KB distribuidas en extensiones de 64 KB. Una página de sistema corrompida (PFS, GAM, SGAM o IAM) puede hacer inaccesibles tablas enteras aunque el resto del fichero esté intacto.

Los escenarios más frecuentes de corrupción de SQL Server que atendemos: una actualización del sistema operativo que interrumpe SQL Server en mitad de una operación de escritura dejando el fichero de datos en estado inconsistente; el disco subyacente desarrolla sectores defectuosos en sectores que contienen páginas de datos críticas; o un ataque de ransomware cifra parcialmente el fichero .mdf dejando el encabezado intacto pero las páginas de datos ilegibles. En todos estos casos, la recuperación trabaja a nivel de páginas individuales, extrayendo los registros de cada tabla directamente de las páginas legibles sin necesidad de que el motor de base de datos pueda abrir el fichero.

Oracle: datafiles, tablespaces y redo logs

Oracle organiza los datos en tablespaces compuestos por datafiles (.dbf). La pérdida o corrupción de un datafile del tablespace SYSTEM hace que la instancia no pueda iniciarse y que todos los datos de la base de datos queden inaccesibles. La recuperación requiere reconstruir las estructuras del diccionario de datos para poder interpretar el contenido de los datafiles de los tablespaces de usuario. Los redo logs son especialmente valiosos en la recuperación: contienen un registro secuencial de todas las transacciones realizadas y pueden usarse para reconstruir el estado de los datos en un punto en el tiempo.

MySQL InnoDB: tablespace compartido e independiente

MySQL con el motor InnoDB puede almacenar todos los datos en un tablespace compartido (ibdata1) o en ficheros .ibd individuales por tabla (innodb_file_per_table). La corrupción del ibdata1 en la configuración de tablespace compartido puede afectar a todas las tablas simultáneamente. La corrupción del diccionario de datos (también almacenado en ibdata1) impide acceder a las tablas aunque sus ficheros .ibd individuales estén intactos. La recuperación en MySQL suele requerir extraer los datos directamente de las páginas InnoDB sin pasar por el motor, lo que permite recuperar registros incluso de tablas cuya definición ha sido parcialmente destruida.

Ransomware en entornos empresariales: actuación y recuperación

El ransomware dirigido a empresas —grupos como LockBit, BlackCat/ALPHV, Akira o Cl0p— no es la misma amenaza que el ransomware de consumo. Los operadores de ransomware-as-a-service (RaaS) corporativo pasan semanas o meses dentro de la red de la víctima antes de lanzar el cifrado, tiempo durante el cual identifican y destruyen o cifran los sistemas de backup y exfiltran datos para la doble extorsión. Cuando el ataque se ejecuta, lo hace simultáneamente en todos los endpoints y servidores accesibles desde la red.

Las primeras horas son críticas

En el momento en que se detecta un ataque de ransomware activo, la prioridad es detener el cifrado antes de que alcance más sistemas. Desconectar los segmentos de red afectados del resto de la infraestructura —idealmente a nivel de switch, no solo desconectando cables en los servidores— es más efectivo que apagar equipos individuales. No apague los equipos afectados si el cifrado puede estar en curso: la memoria RAM puede contener material de clave que un laboratorio especializado puede extraer para intentar el descifrado.

Posibilidades técnicas de recuperación sin pagar el rescate

Pagar el rescate no garantiza la recuperación de los datos y financia la continuación de las operaciones criminales. Las alternativas técnicas de recuperación dependen del ransomware específico y del estado del entorno:

• Shadow Volume Copies (VSS): Muchas variantes modernas de ransomware eliminan los shadow copies antes del cifrado, pero si el ataque fue interrumpido o en sistemas bien protegidos, los VSS anteriores al cifrado pueden permitir recuperar versiones previas de los ficheros.
• Backups no alcanzados por el cifrado: Copias air-gapped, cintas LTO offline o backups en cloud con Object Lock activado son inmunes al cifrado. Si existen, la recuperación consiste en restaurar desde el backup y analizar las pérdidas del período sin cubrir.
• Herramientas de descifrado públicas: Para algunas familias de ransomware desmanteladas (como Babuk, REvil o Hive), existen herramientas de descifrado gratuitas publicadas por las autoridades o por investigadores de seguridad. Verificar en nomoreransom.org antes de cualquier otra acción.
• Análisis forense del cifrado: En casos excepcionales, cuando el ransomware ha utilizado generadores de números aleatorios defectuosos o ha reutilizado material de clave, el análisis del patrón de cifrado puede permitir la recuperación parcial o total de los datos.

Cadena de custodia, NDA y cumplimiento normativo

Para las empresas, confiar los dispositivos de almacenamiento a un laboratorio externo implica ceder temporalmente el control de información potencialmente muy sensible: datos de clientes, contratos, información financiera, propiedad intelectual, datos de empleados. El marco legal y procedimental que rodea esta cesión no es accesorio: es parte esencial del servicio.

Acuerdo de Confidencialidad (NDA)

Para todos los clientes empresariales firmamos un acuerdo de confidencialidad (NDA) antes de iniciar cualquier trabajo sobre los dispositivos. El NDA puede ser el modelo estándar de RecuperaTusDatos o adaptarse a los requerimientos legales específicos de su empresa —incluyendo cláusulas de sector regulado como sanidad, finanzas o defensa. La firma del NDA es gratuita y no añade demora al inicio del proceso técnico.

Cadena de custodia documentada

Cada dispositivo recibido queda registrado en nuestra cadena de custodia con los siguientes elementos: fotografías del estado físico inicial, número de serie de cada unidad, fecha y hora de recepción, nombre del técnico receptor, y registro cronológico de todas las intervenciones técnicas realizadas indicando el técnico responsable y los resultados obtenidos. Al cierre del caso se entrega al cliente el documento completo de cadena de custodia, válido como evidencia en procedimientos legales o en auditorías de cumplimiento.

Certificado de destrucción

Una vez finalizado el proceso de recuperación y entregados los datos, podemos emitir un certificado de destrucción segura del dispositivo original si la política interna de la empresa o la normativa sectorial así lo requieren. La destrucción se realiza conforme a los estándares NIST 800-88 (para dispositivos de estado sólido) o mediante desmagnetización y destrucción física, con número de serie documentado.

Alineación con ISO 9001 e ISO 27001

El laboratorio cuenta con certificación ISO 9001:2015, lo que garantiza que los procesos de gestión de la calidad están definidos, documentados y auditados de forma continua: desde la recepción del dispositivo hasta la entrega de los datos y el cierre del caso. Los procedimientos de gestión de la información se alinean con los principios del estándar ISO/IEC 27001 para la seguridad de la información, incluyendo control de acceso físico al laboratorio, cifrado de los datos recuperados en el soporte de entrega y política de retención y destrucción de copias de trabajo una vez cerrado el caso.

Para departamentos de cumplimiento, oficinas del DPO o responsables de auditoría interna: podemos proporcionar documentación adicional sobre nuestros controles de seguridad bajo solicitud y acuerdo de confidencialidad previo.

SLA, servicio urgente y modalidades de intervención

Una recuperación de datos corporativa no puede manejarse con los mismos plazos que un servicio de consumo. El coste de inactividad de un servidor de producción —medido en productividad perdida, incumplimiento de contratos, penalizaciones por SLA con clientes y coste reputacional— supera con frecuencia en uno o dos órdenes de magnitud el coste de la recuperación. Por eso el servicio corporativo incluye plazos garantizados y modalidades de intervención adaptadas a la urgencia real.

Artículos relacionados de interés para responsables de TI: guía de emergencia para RAID fallido en empresa, recuperación de datos en NAS Synology, recuperación de datos en NAS QNAP y guía completa de backup empresarial.

Preguntas frecuentes — recuperación de datos para empresas