Recuperación de Datos Tras Fallo de Controladora RAID Hardware
Cuando una controladora RAID hardware falla, el administrador de sistemas se enfrenta a una paradoja: los discos están físicamente intactos, pero el array es inaccesible. Sustituir la controladora por un modelo idéntico rara vez funciona sin conocer los metadatos del array almacenados en la NVRAM de la controladora original. La recuperación experta permite reconstruir esa configuración y acceder a los datos.
Cómo almacena la configuración una controladora RAID hardware
A diferencia del software RAID (md en Linux, Espacios de almacenamiento en Windows), una controladora RAID hardware gestiona el array de forma completamente autónoma. La configuración del array —qué discos lo componen, nivel RAID, tamaño de stripe, orden de los discos, política de caché— se almacena en dos lugares:
- NVRAM de la controladora: Memoria no volátil soldada en la PCB de la tarjeta. Contiene la base de datos de configuración completa, incluidos UUIDs de los virtual drives y las asociaciones entre los discos físicos y sus posiciones lógicas en el array.
- DDF (Disk Data Format) en los discos: Los sectores reservados al inicio y/o final de cada disco miembro contienen una copia redundante de la configuración según el estándar SNIA DDF. Sin embargo, este mecanismo de seguridad no siempre es suficiente cuando la implementación del fabricante es propietaria.
El problema surge porque los fabricantes extienden DDF con campos propietarios y no documentados. La controladora de reemplazo puede leer los campos DDF estándar pero ignora los campos propietarios, resultando en un array que no es reconocido o que se considera «foráneo».
Por qué la controladora de reemplazo idéntica no siempre funciona
Este es el error más común: comprar en eBay o en proveedor de hardware una controladora del mismo modelo exacto y asumir que reconocerá automáticamente los discos. Los motivos por los que esto frecuentemente falla:
- Firmware diferente: Una controladora LSI MegaRAID 9361-8i con firmware 4.680 puede tener estructura de metadatos incompatible con la versión 4.710. Los metadatos DDF propietarios varían entre versiones de firmware.
- NVRAM vacía: La controladora nueva llega con NVRAM en estado de fábrica. No importa que el modelo sea idéntico: sin los metadatos de configuración, no reconoce ningún array existente.
- Formato de metadatos propietario: Fabricantes como HP (Smart Array) y Dell (PERC) utilizan formatos de metadatos completamente propietarios que no siguen DDF. Una controladora HP P440 no puede importar un array creado en una HP P400, aunque ambas soporten RAID 5 con los mismos discos.
- Cambio de generación: La transición de controladoras MegaRAID de generación SAS2 a SAS3 introdujo cambios en el formato de metadatos que hacen incompatibles los arrays entre generaciones.
Formatos propietarios de los principales fabricantes
| Fabricante / Modelo | Formato metadatos | Particularidades de recuperación |
|---|---|---|
| LSI / Broadcom MegaRAID (9260, 9361, 9560) | DDF extendido + NVRAM propietaria | Los metadatos DDF en disco son parcialmente legibles. Herramienta MegaCLI puede exportar configuración si la controladora funciona parcialmente. |
| HP Smart Array (P410, P440, P840) | Completamente propietario (no DDF) | Los metadatos están en los primeros 1-8 MB de cada disco. Parcialmente reversibles con herramientas especializadas. Muy sensible a diferencias de firmware. |
| Dell PERC (H700, H730, H840) | DDF LSI extendido (OEM de LSI/Broadcom) | Los PERC son OEM de LSI. Con la herramienta correcta, a veces es posible migrar a una controladora LSI equivalente leyendo los metadatos DDF del disco. |
| IBM ServeRAID (M5110, M5210) | DDF LSI (IBM era OEM de LSI) | Igual que PERC. La generación M-Series es compatible a nivel DDF con MegaRAID equivalente en muchos casos. |
| Adaptec SmartRAID (3154, 7805) | Propietario Adaptec (no DDF) | Metadatos en zonas reservadas de los discos. Herramienta arcconf puede leer configuración si alguna controladora del mismo family funciona. |
El proceso de recuperación tras fallo de controladora hardware
Fase 1: Diagnóstico y preservación
Antes de intentar ninguna acción de recuperación, el laboratorio debe:
- Documentar el modelo exacto de la controladora, versión de firmware, número de serie y configuración del array (nivel RAID, número de discos, tamaño de stripe, política de escritura).
- Intentar extraer los metadatos DDF de cada disco con herramientas de solo lectura y bloqueadores de escritura hardware.
- Clonar todos los discos del array antes de cualquier intento de reconstrucción.
Fase 2: Reconstrucción de la configuración
Con los metadatos extraídos (o inferidos a partir de la estructura del array en disco), el técnico debe determinar:
- Orden exacto de los discos miembro en el array (el orden incorrecto produce datos completamente corruptos en RAID 5/6)
- Tamaño del stripe (habitualmente 64KB, 128KB o 256KB en RAID empresarial)
- Posición del bloque de paridad en RAID 5 (left/right symmetric, left/right asynchronous)
- Offset de inicio de datos en cada disco (muchas controladoras reservan los primeros 64MB para metadatos)
Fase 3: Reconstrucción en software RAID
Una vez conocidos todos los parámetros, el técnico reconstruye el array virtualmente usando software especializado sobre las imágenes clonadas de los discos, sin necesidad de la controladora hardware original. Este proceso permite acceder al sistema de archivos y extraer los datos.
Migración desde controladora fallida a software RAID
En muchos casos, la mejor solución a largo plazo tras recuperar los datos es no volver a usar una controladora RAID hardware propietaria, sino migrar a software RAID. Las ventajas son significativas:
- Los metadatos de Linux md RAID y ZFS están completamente documentados y son independientes del hardware.
- La sustitución de hardware no requiere ningún proceso especial de importación.
- ZFS además proporciona checksums de datos, detección de bit rot y snapshots nativos.
La migración implica: recuperación de los datos de la controladora fallida, formateo de los discos con nuevo esquema md/ZFS, y restauración. RecuperaTusDatos.es puede gestionar todo el proceso incluyendo la planificación de la nueva arquitectura de almacenamiento.
Cuándo es irrecuperable un array con controladora fallida
Existen escenarios donde la recuperación se complica significativamente o puede ser imposible:
- Fallo simultáneo de controladora y disco(s): Si el array ya estaba degradado antes del fallo de la controladora (RAID 5 con un disco perdido), la combinación puede ser irrecuperable si se pierde otro disco durante los intentos de recuperación.
- Controladora con daño físico severo: Si la NVRAM está dañada y no hay DDF en los discos (algunos arrays con cache-only configurados sin DDF on-disk), los parámetros del array pueden ser irrecuperables sin documentación previa.
- Array con cifrado hardware sin clave de recuperación: Las controladoras con Self-Encrypting Drive (SED) management almacenan las claves de cifrado en la controladora. Si esta falla sin backup de la clave, los datos están cifrados sin posibilidad de descifrado.
Por esto, documentar la configuración del array en el momento de su creación (nivel RAID, stripe size, orden de discos, versión firmware de la controladora) es una medida de prevención fundamental que puede marcar la diferencia entre una recuperación exitosa y la pérdida definitiva.
WhatsApp