Recuperar Datos RAID con Controladora Hardware Fallida [2026]

Cuando la controladora RAID hardware falla, los discos físicos permanecen intactos —los datos siguen ahí, en los platos magnéticos o en las celdas NAND— pero ningún sistema puede leerlos. La configuración del array (stripe size, orden de discos, tipo de paridad, offset de datos) está codificada en formato propietario dentro de la memoria de esa controladora concreta. Cada fabricante —Adaptec, LSI/Broadcom MegaRAID, Areca, HPE Smart Array, Dell PERC— usa un esquema de metadatos diferente e incompatible con los demás. Cambiar simplemente la controladora por otra marca o incluso por otro modelo del mismo fabricante no funciona: los discos aparecen como foreign o como discos sin inicializar. La recuperación profesional requiere análisis forense de los metadatos propietarios de la controladora original para reconstruir el array de forma virtual.

1. Cómo funciona una controladora RAID hardware

Una controladora RAID hardware es, en esencia, un ordenador dentro de tu servidor. A diferencia del RAID por software (Windows Storage Spaces, mdadm en Linux), que delega todo el trabajo en la CPU del sistema, la controladora hardware dispone de su propio procesador dedicado (habitualmente un ARM o un MIPS de varios núcleos), su propia memoria caché de entre 512 MB y 8 GB, y un firmware autónomo que gestiona el array de forma completamente independiente del sistema operativo.

Esta arquitectura ofrece ventajas reales: la CPU del servidor queda liberada del cálculo de paridad XOR, la escritura se confirma al sistema operativo en cuanto llega a la caché de la controladora (no cuando llega a los discos), y la lógica de reconstrucción del array se ejecuta en segundo plano sin degradar el rendimiento del servidor. El procesador de la controladora también gestiona el monitoreo S.M.A.R.T. de cada disco, detecta fallos de disco de forma independiente y gestiona el hot spare automático.

La configuración del array: dónde se almacena

Aquí está el elemento clave para entender los problemas de recuperación: la configuración del array se almacena en dos lugares simultáneamente. Por un lado, en la NVRAM de la propia controladora (una pequeña memoria no volátil que mantiene los datos aunque se corte la alimentación). Por otro, en un área reservada al inicio o al final de cada disco del array, en forma de metadatos propietarios. Esto implica que, si la controladora falla pero los discos están bien, los metadatos del array siguen en los discos. El problema es que esos metadatos están en un formato binario propietario de cada fabricante y cada familia de productos.

El papel de la caché con BBU

Para acelerar las escrituras, la controladora usa una técnica llamada write-back caching: cuando el sistema operativo escribe un dato, la controladora lo guarda en su caché RAM y confirma la escritura inmediatamente, sin esperar a que el dato llegue físicamente a los discos. Esto mejora el rendimiento de forma dramática, pero introduce un riesgo: si la alimentación se corta antes de que los datos en caché se hayan volcado a los discos, esos datos se pierden. La BBU (Battery Backup Unit) existe precisamente para evitar este problema: mantiene la caché alimentada el tiempo suficiente para completar el volcado a disco cuando se restaura la corriente. Si la BBU falla, la controladora pasa automáticamente a modo write-through, que es más seguro pero significativamente más lento.

2. Principales marcas y sus formatos propietarios de metadatos

Cada fabricante de controladoras RAID hardware utiliza un esquema de metadatos diferente para almacenar la configuración del array en los discos. Esto tiene una consecuencia directa: los discos de un array Adaptec no pueden ser leídos por una controladora LSI, y viceversa. A continuación describimos las características más relevantes de cada plataforma desde el punto de vista de la recuperación forense:

Adaptec SmartRAID y Serie RAID (anteriormente Microsemi)

Las controladoras Adaptec (ahora bajo el paraguas de Microchip Technology tras la adquisición de Microsemi) son habituales en servidores de gama media en Europa. La serie SmartRAID 3100/3200 y las antiguas Series 6/7/8 almacenan los metadatos del array en un bloque de configuración propietario en los primeros sectores reservados de cada disco. Este bloque incluye el UUID del array, el stripe size, el orden de discos, el tipo de RAID, el estado de cada miembro y las marcas de tiempo de la última sincronización. La recuperación forense de arrays Adaptec requiere interpretar este bloque con herramientas específicas; PC-3000 RAID y ReclaiMe Pro tienen soporte parcial para los formatos más comunes, aunque algunos modelos más antiguos requieren análisis manual de los bloques binarios.

LSI/Broadcom MegaRAID

Las controladoras LSI MegaRAID (actualmente bajo Broadcom tras la adquisición de Avago Technologies) son posiblemente las más extendidas en servidores empresariales x86 a nivel mundial. La serie SAS 9271, 9361, 9460 y 9560 almacena la configuración del array tanto en la NVRAM de la controladora como en los metadatos al final de cada disco (en los últimos 512 MB del espacio de disco reservado por la controladora). Los metadatos MegaRAID incluyen el RAID level, el stripe size en bloques de 512 bytes, el orden lógico de los discos, las bandas de paridad y un campo de estado de consistencia. Una particularidad importante: cuando se reemplaza una controladora MegaRAID por otra del mismo fabricante pero de diferente generación (por ejemplo, de 9271 a 9460), es posible que los discos aparezcan como foreign pero que la nueva controladora pueda importar la configuración. Sin embargo, esto no siempre funciona y puede deteriorar los metadatos originales.

Areca Technology

Las controladoras Areca (series ARC-1200, ARC-1220, ARC-1680, ARC-1882) son populares en entornos de producción audiovisual y almacenamiento de alta capacidad, especialmente en Asia y Norteamérica. Areca almacena su configuración de forma diferente a Adaptec y LSI: además de los metadatos en cada disco, mantiene una copia completa de la configuración en una memoria flash integrada en la propia controladora. Cuando la controladora falla físicamente, los metadatos en los discos pueden seguir intactos, pero recuperarlos requiere conocer el formato específico de Areca para cada generación de firmware.

HPE Smart Array (ProLiant)

Las controladoras HPE Smart Array (P408i-a, P816i-a, P408e, E208i) son las que se encuentran en servidores HPE ProLiant DL360, DL380 y ML350. El formato de metadatos de HPE es particularmente complejo porque incorpora información de la configuración del servidor (UUID del sistema, número de serie) vinculada a los metadatos del array. Esto implica que, incluso con una controladora del mismo modelo, mover los discos a un servidor HPE diferente puede resultar en que los datos aparezcan como no accesibles sin el proceso de importación correcto. Las HPE Smart Array mantienen adicionalmente un array accelerator (la caché de escritura con batería o supercondensador) cuya configuración forma parte de los metadatos del array.

Dell PERC (PowerEdge RAID Controller)

Las controladoras Dell PERC (PERC H730, H730P, H740P, H750, H755) son prácticamente las mismas controladoras LSI/Broadcom MegaRAID vendidas bajo marca Dell con firmware personalizado. Sin embargo, el firmware Dell añade capas de configuración propietarias que hacen que los discos de un servidor Dell PERC no sean importables directamente en una controladora LSI genérica sin modificaciones del firmware. Dell llama a este sistema foreign configuration: los discos muestran un banner de configuración extranjera al conectarlos, y en muchos casos es posible importarla desde el BIOS de la controladora, pero el proceso puede fallar dependiendo del estado de los metadatos.

3. La batería de respaldo (BBU): el fallo silencioso más peligroso

La BBU (Battery Backup Unit) o, en controladoras más modernas, el supercondensador de respaldo (CacheVault en Dell PERC, capacitor pack en HPE) es uno de los componentes con mayor tasa de fallo en una controladora RAID hardware. Su vida útil típica es de 2 a 4 años, muy inferior a la del resto de la controladora. Cuando caduca, se producen dos consecuencias que muchos administradores no comprenden correctamente:

Consecuencia 1: El rendimiento cae drásticamente (y no se sabe por qué)

Sin BBU funcional, la controladora desactiva el modo write-back y pasa a write-through. En este modo, cada operación de escritura del sistema operativo no se confirma hasta que el dato ha llegado físicamente a los platos del disco. El resultado es una caída de rendimiento de escritura que puede ser del 200 al 500 % respecto al rendimiento con write-back activo. Muchos administradores atribuyen esta degradación a otros problemas del servidor y tardan semanas en identificar que es la BBU el culpable.

Consecuencia 2: Pérdida de datos en caché durante el fallo de alimentación

Si la BBU está caducada pero la controladora sigue usando write-back (porque la detección de estado de la batería no es perfecta, o porque el administrador no ha respondido a las alertas del sistema), cualquier corte de alimentación puede dejar datos críticos en la caché sin volcar a disco. El sistema de archivos queda en un estado inconsistente, la partición puede aparecer corrupta o directamente no montable. En RAID 5 o RAID 6, la corrupción del stripe de paridad durante un corte con caché pendiente puede generar inconsistencias que el controlador detecta en el siguiente arranque y que, si se fuerza la reconstrucción, pueden destruir datos.

Recomendación: Sustituye la BBU cada 2-3 años de forma preventiva, independientemente de los avisos del sistema. El coste de una BBU de repuesto (50-200 € según modelo) es insignificante comparado con el coste de una recuperación de datos o, peor, con la pérdida definitiva de información crítica.

4. Escenarios de fallo más habituales en controladoras RAID hardware

En nuestro laboratorio atendemos casos de fallo de controladora RAID hardware con frecuencia semanal. Estos son los escenarios que se repiten con mayor frecuencia:

Escenario A: La controladora deja de funcionar (los discos están bien)

El fallo eléctrico o electrónico de la controladora es el escenario más frecuente. Un pico de tensión, un condensador defectuoso en la PCB de la controladora, o simplemente el fin de su vida útil hacen que la tarjeta deje de inicializarse. El servidor no arranca o arranca pero no ve el array de almacenamiento. Los discos físicos están perfectamente: si los conectas a un PC directamente aparecen como discos no inicializados (porque el sistema operativo no puede interpretar los metadatos propietarios de la controladora). En este escenario la tasa de recuperación es muy alta porque los datos en los discos están intactos.

Escenario B: Fallo de la BBU con pérdida de caché

Durante un corte de alimentación con la BBU degradada, los datos que estaban en la caché de escritura no se volcaron a disco. El sistema de archivos queda inconsistente. Al reiniciar, el servidor puede montar el volumen con errores, o el volumen puede aparecer directamente como inaccesible. En NTFS, esto puede significar un MFT corrupto. En ext4, el journaling puede o no haber registrado la transacción incompleta. La recuperación en este caso combina el análisis del estado de la controladora con la reconstrucción del sistema de archivos.

Escenario C: Corrupción del firmware de la controladora

Una actualización de firmware de la controladora que se interrumpe a mitad del proceso (corte de corriente, error de red durante la actualización OOB) puede corromper el firmware de la tarjeta. La controladora arranca pero no inicializa el array, o arranca en modo de emergencia que solo permite operaciones de diagnóstico. En algunos casos, la NVRAM con la configuración del array se borra durante el proceso de actualización fallido, aunque los metadatos en los discos permanecen intactos.

Escenario D: Fallo del slot PCIe

Aunque menos frecuente, un fallo en el slot PCIe del servidor (o en el riser card que aloja la controladora) puede impedir que el sistema detecte la tarjeta. En este escenario la controladora está físicamente intacta; el problema es la conexión entre la controladora y el bus del servidor. Mover la controladora a otro slot PCIe compatible puede resolver el problema sin ninguna intervención en los datos, aunque si el movimiento no funciona y se sustituye la controladora por otra diferente, volvemos al problema de la incompatibilidad de metadatos.

5. El problema crítico: por qué no puedes simplemente cambiar la controladora

Este es el punto que más frecuentemente genera decisiones equivocadas. Cuando la controladora RAID falla, la reacción instintiva de cualquier administrador es: "compro otra controladora del mismo tipo y conecto los discos". Esta solución funciona solo bajo condiciones muy específicas y falla en la mayoría de los casos reales. Vamos a explicar por qué.

Por qué la misma marca/modelo puede no funcionar

Incluso sustituyendo la controladora por exactamente el mismo modelo (mismo número de parte), pueden surgir problemas. Las controladoras Adaptec y LSI almacenan parte de la configuración del array en la NVRAM interna de la tarjeta original, no solo en los discos. Si esa NVRAM contenía información que no está replicada completamente en los metadatos de los discos (por ejemplo, el estado de consistencia del array, los logs de transacciones pendientes, o la clave de cifrado si el array estaba cifrado), la nueva controladora arrancará con una configuración parcialmente vacía. Dependiendo del estado de los metadatos en los discos, el array puede importarse correctamente, importarse con advertencias, o directamente no reconocerse.

El peligro de "limpiar" o "inicializar" en la nueva controladora

Si la nueva controladora no reconoce el array y muestra los discos como unconfigured good o foreign, el firmware ofrece opciones que parecen soluciones pero que en realidad destruyen los datos: "Clear configuration", "Initialize", "Create new array". Cualquiera de estas opciones sobrescribe los metadatos propietarios que quedan en los discos, que son la única fuente de información disponible sobre la estructura del array. Después de ejecutar cualquiera de estas opciones, la recuperación se vuelve órdenes de magnitud más compleja, cara y con menor tasa de éxito.

La incompatibilidad entre versiones de firmware

En muchos entornos corporativos, las controladoras RAID llevan años instaladas con una versión de firmware estable y probada. Si la controladora de repuesto tiene una versión de firmware significativamente más nueva (o más antigua), el formato de los metadatos puede haber cambiado entre versiones. Las controladoras LSI MegaRAID, por ejemplo, han cambiado el formato de sus metadatos varias veces entre generaciones de firmware, lo que hace que una controladora 9460 con firmware 5.x pueda no interpretar correctamente los metadatos generados por una 9271 con firmware 3.x.

6. Qué NO debes hacer cuando falla la controladora RAID

7. Proceso de recuperación profesional en laboratorio

La recuperación de datos de un RAID con controladora hardware fallida es uno de los casos más especializados que existen en el ámbito de la recuperación de datos. Requiere conocimiento profundo de los formatos propietarios de cada fabricante, herramientas específicas de análisis forense y experiencia práctica con los comportamientos específicos de cada modelo de controladora. Este es el protocolo que seguimos en nuestro laboratorio:

1. Evaluación inicial de la controladora. El primer paso es determinar si la controladora puede rehabilitarse o si su NVRAM puede extraerse para leer directamente la configuración del array. Nuestros técnicos de electrónica inspeccionan la PCB de la controladora bajo microscopio, identifican componentes dañados (condensadores, MOSFETs, reguladores de tensión) y evalúan la posibilidad de reparación o extracción de la memoria de configuración. Este análisis puede tomar entre 2 y 8 horas según el estado de la tarjeta.
2. Diagnóstico individual de cada disco del array. Simultáneamente, evaluamos el estado físico y lógico de cada disco mediante PC-3000 UDMA. Leemos los registros S.M.A.R.T. extendidos, detectamos sectores defectuosos, evaluamos el estado de los cabezales y verificamos que la electrónica de cada disco sea funcional. Si algún disco tiene fallo mecánico, lo atendemos en sala limpia antes de continuar. El diagnóstico es gratuito.
3. Imagen forense de cada disco (sin modificar los originales). Creamos copias bit a bit de cada disco usando hardware de clonado forense (DeepSpar Disk Imager, PC-3000 Portable). Las imágenes se almacenan en medios propios del laboratorio. Los discos originales no se vuelven a conectar. Para discos con sectores defectuosos, el hardware de clonado reintenta cada sector problemático con algoritmos de recuperación específicos antes de marcar el bloque como ilegible.
4. Análisis forense de los metadatos de la controladora. Con las imágenes disponibles, nuestro equipo analiza las áreas reservadas de cada disco donde la controladora ha escrito sus metadatos. Según el fabricante, esto puede estar en los primeros o últimos sectores del disco, en una partición reservada, o distribuido en múltiples ubicaciones. Extraemos y decodificamos el stripe size, el orden lógico de los discos en el array, el tipo de RAID, el offset de inicio de datos, el tipo de paridad y cualquier información de estado (consistencia, miembros degradados, sectores remapeados conocidos por la controladora).
5. Reconstrucción virtual del array sobre las imágenes. Con los parámetros identificados, el software especializado (PC-3000 RAID, ReclaiMe Pro, soluciones de desarrollo interno para formatos propietarios específicos) ensambla las imágenes en un array virtual que reproduce fielmente el funcionamiento de la controladora original. Verificamos si el sistema de archivos del volumen resultante es consistente y si el volumen puede montarse. Si hay inconsistencias, las analizamos y determinamos si son reparables sin pérdida de datos adicional.
6. Extracción, verificación y entrega de los datos. Una vez el volumen virtual es accesible, extraemos los archivos a un soporte nuevo (disco duro externo o NAS de laboratorio). Verificamos la integridad de los archivos prioritarios indicados por el cliente. El cliente puede revisar un listado completo de archivos recuperados antes de aprobar la entrega. Solo cuando el cliente confirma que los datos necesarios han sido recuperados se emite la factura. Si no hay recuperación satisfactoria, no hay coste.

8. Precios y plazos orientativos

El coste de recuperación de un RAID con controladora hardware fallida depende de la complejidad de los metadatos propietarios, del número de discos del array, de si existe daño físico en alguno de los discos, y de si el array estaba cifrado. La siguiente tabla recoge los rangos habituales en nuestro laboratorio:

Los precios indicados son orientativos e incluyen el proceso completo hasta la entrega de los datos en soporte nuevo. El diagnóstico es siempre gratuito y el presupuesto definitivo se facilita antes de iniciar cualquier trabajo de recuperación. Aplicamos una política estricta de no recuperación, sin coste: si no obtenemos los datos que el cliente necesita, no cobramos nada.

9. Preguntas frecuentes