Recuperar datos de RAID software Linux (md-RAID, mdadm) [2026]
El RAID software de Linux —conocido como md-RAID y gestionado mediante la herramienta mdadm— es la solución de redundancia más extendida en servidores Linux, NAS basados en OpenMediaVault y antiguos sistemas FreeNAS. A diferencia del RAID hardware, no depende de una controladora propietaria: la lógica del array reside en el kernel y los metadatos del RAID se almacenan en cada disco individual (superbloque). Cuando el array falla —por corrupción del superbloque, una reconstrucción abortada, un disco extraído por error o la pérdida del fichero mdadm.conf— recuperar los datos requiere comprender en detalle la estructura interna de md-RAID. Intervenir sin ese conocimiento, especialmente ejecutando comandos como mdadm --zero-superblock o forzando un ensamblaje degradado sin imagen previa, puede destruir irremediablemente la posibilidad de recuperación.
Datos clave — RAID software Linux (md-RAID)
800 € – 4.000 € + IVA
5 – 15 días laborables
75 – 92 %
Gratuito y sin compromiso
1. Qué es md-RAID y cómo funciona
md-RAID (Multiple Devices RAID) es el subsistema de RAID integrado en el kernel de Linux. A diferencia del RAID hardware —donde la controladora es un componente físico con su propio procesador y RAM de caché, y donde los metadatos del array se almacenan en la controladora o en una zona reservada al inicio de cada disco— en md-RAID toda la lógica de RAID la ejecuta el kernel y los metadatos (el superbloque) se escriben directamente en cada disco miembro del array.
La herramienta de espacio de usuario que crea, gestiona, monitoriza y repara los arrays md-RAID es mdadm (Multiple Disk Administrator). Prácticamente toda la administración del RAID software en Linux pasa por este comando: crear el array, añadir discos, marcar un disco como fallido, iniciar una reconstrucción, obtener información del array, o ensamblar un array a partir de sus discos miembro cuando se ha perdido el fichero de configuración (/etc/mdadm/mdadm.conf).
El dispositivo lógico: /dev/md0, /dev/md1…
Una vez ensamblado, el array md-RAID aparece en el sistema como un dispositivo de bloque estándar (/dev/md0, /dev/md1, etc.). Sobre ese dispositivo se formatea el sistema de ficheros (ext4, XFS, Btrfs) y se monta como si fuera un disco físico convencional. Las aplicaciones, el sistema operativo y los usuarios interactúan con el sistema de ficheros sin ser conscientes de que debajo hay varios discos físicos con lógica de paridad o espejado gestionada por el kernel.
El estado del array en tiempo real puede consultarse en /proc/mdstat: muestra qué arrays están activos, cuántos discos los componen, cuáles están activos y cuáles degradados o ausentes, y el progreso de cualquier reconstrucción o verificación de paridad en curso.
Uso típico: servidores, NAS y home servers
md-RAID se encuentra principalmente en:
- Servidores Linux de producción con distribuciones como Ubuntu Server, Debian, CentOS o RHEL, donde md-RAID RAID 1 o RAID 5/6 protege los datos sin necesidad de controladora hardware.
- NAS con OpenMediaVault (OMV): la distribución NAS open source más popular basada en Debian utiliza md-RAID para todos sus pools de almacenamiento, gestionado desde su interfaz web.
- Sistemas FreeNAS / TrueNAS CORE antiguos instalados sobre Linux (aunque TrueNAS CORE moderno usa ZFS sobre FreeBSD, las versiones anteriores con base Linux usaban md-RAID).
- Home servers y media centers basados en Ubuntu o Raspbian con varios discos duros, donde md-RAID RAID 1 protege la biblioteca multimedia o los backups domésticos.
- VPS y servidores cloud donde el proveedor utiliza md-RAID como capa de redundancia adicional al almacenamiento de red.
2. Niveles RAID soportados por mdadm (0, 1, 4, 5, 6, 10)
mdadm soporta todos los niveles RAID habituales. Cada uno tiene implicaciones muy distintas tanto en rendimiento y tolerancia a fallos como en la complejidad de la recuperación cuando el array cae.
| Nivel RAID | Discos mínimos | Tolerancia a fallos | Capacidad útil | Uso típico |
|---|---|---|---|---|
| RAID 0 | 2 | Ninguna (0 discos) | 100 % (N discos) | Rendimiento puro, sin redundancia |
| RAID 1 | 2 | 1 disco por pareja | 50 % (N/2) | Sistema operativo, datos críticos con 2 discos |
| RAID 4 | 3 | 1 disco | (N−1)/N | Raro — disco de paridad dedicado, cuello de botella |
| RAID 5 | 3 | 1 disco | (N−1)/N | NAS doméstico, servidores de ficheros con 3–8 discos |
| RAID 6 | 4 | 2 discos | (N−2)/N | NAS empresarial, arrays grandes con discos de alta capacidad |
| RAID 10 | 4 | 1 por pareja espejo | 50 % (N/2) | Servidores de bases de datos, alto rendimiento + redundancia |
En el contexto de la recuperación de datos, los arrays md-RAID más habituales que llegan al laboratorio son RAID 5 (NAS doméstico y de pymes) y RAID 1 (servidores con el sistema operativo). RAID 6 aparece en entornos más exigentes, y RAID 10 en servidores de bases de datos Linux. RAID 0 sin redundancia llega cuando hay un fallo físico en alguno de los discos del stripe.
3. Versiones del superbloque: 0.9, 1.0, 1.1 y 1.2
El superbloque es la estructura de metadatos que md-RAID escribe en cada disco miembro del array. Contiene toda la información necesaria para identificar y reconstruir el array: UUID del array, nivel RAID, número de discos, tamaño del chunk (stripe), posición del disco en el array y estado de la última sincronización. Cuando el sistema arranca, el kernel lee los superbloques de todos los discos detectados y ensambla automáticamente los arrays que reconoce.
La versión del superbloque determina dónde se escribe en el disco, lo cual tiene consecuencias directas para la recuperación y para el riesgo de corrupción:
Versión 0.9 (legacy)
El superbloque se escribe en los últimos 64 KB del disco, justo antes del final. Esta ubicación al final del disco tiene una ventaja importante: si se formatea el disco miembro como si fuera un disco independiente (un error humano habitual), el sistema de ficheros nuevo no sobrescribe el superbloque md-RAID porque los sistemas de ficheros empiezan desde el principio del disco. Es la versión más antigua, compatible con kernels de Linux muy anteriores, pero ya no se usa por defecto desde hace años.
Versión 1.0
El superbloque se escribe también al final del espacio del dispositivo, de forma similar a la versión 0.9 pero con un formato actualizado. Es la versión predeterminada que usa mdadm cuando el array se va a usar como dispositivo de arranque (boot device) en sistemas con BIOS legacy, porque el superbloque al final del disco no interfiere con el sector de arranque ni con la tabla de particiones del inicio del disco.
Versión 1.1
El superbloque se escribe en los primeros 8 KB del disco, al comienzo del dispositivo. Es adecuada para particiones que no arrancará el sistema, pero tiene un riesgo: si alguien particiona el disco o escribe una tabla de particiones nueva en el dispositivo miembro (otro error humano frecuente), puede sobrescribir o corromper el superbloque.
Versión 1.2 (predeterminada moderna)
El superbloque se escribe a 4 KB desde el inicio del disco. Es la versión predeterminada en la mayoría de distribuciones Linux modernas (Ubuntu 20.04+, Debian 11+, RHEL 8+). Ofrece el mejor equilibrio entre compatibilidad y seguridad de la ubicación de metadatos. La posición exacta (offset) varía ligeramente según la alineación del array, pero siempre está en los primeros sectores del disco.
Conocer la versión del superbloque de tu array permite al laboratorio saber exactamente dónde buscar los metadatos de md-RAID en cada disco. Si el superbloque está corrupto, los metadatos de otro disco del mismo array pueden usarse para reconstruirlo. Si no se conoce la versión, el laboratorio la determina analizando los patrones de bytes en las ubicaciones posibles de cada versión.
4. Filesystems sobre md-RAID: ext4, XFS, Btrfs
md-RAID es una capa de abstracción de bloques: no impone ningún sistema de ficheros. El administrador elige el filesystem que se formatea sobre el dispositivo /dev/md0, y esa elección tiene consecuencias importantes tanto en el rendimiento cotidiano como en la recuperación de datos cuando el array falla.
ext4: el más común y mejor soportado para recuperación
ext4 es el sistema de ficheros predeterminado en la mayoría de distribuciones Linux (Ubuntu, Debian, Fedora) y el más frecuente sobre md-RAID. Tiene décadas de madurez, herramientas de recuperación ampliamente probadas (e2fsck, debugfs, extundelete) y un diseño de metadatos que facilita la recuperación forense. Las estructuras clave (superbloque ext4, tablas de grupos de bloques, tablas de inodos) tienen copias de seguridad distribuidas por el volumen. En el laboratorio, ext4 sobre md-RAID es el escenario más favorable para la recuperación.
XFS: alto rendimiento, más exigente en recuperación
XFS es el sistema de ficheros predeterminado en RHEL/CentOS/Rocky Linux y es muy popular en servidores con grandes volúmenes de datos. Ofrece excelente rendimiento con ficheros grandes y alta concurrencia. Su diseño de metadata, sin embargo, es más centralizado que ext4: el superbloque XFS es único (sin copias distribuidas como en ext4), y la corrupción del árbol de allocation group puede ser más difícil de reparar. Las herramientas de recuperación de XFS (xfs_repair, xfs_db) son potentes pero requieren que el array md-RAID subyacente esté correctamente ensamblado antes de operar sobre el filesystem.
Btrfs: complejo, recuperación especializada
Btrfs es el filesystem más moderno y complejo disponible en Linux. Ofrece snapshots nativos, compresión transparente, checksums de datos y metadata, y tiene su propia capa de gestión de volúmenes que puede reemplazar a md-RAID. Cuando Btrfs se usa sobre md-RAID (en lugar de usar las funciones RAID nativas de Btrfs), la recuperación se complica porque hay dos capas de metadata superpuestas. Si el árbol B+ de Btrfs está corrupto, la herramienta btrfs check --repair puede agravar el daño. La recuperación de Btrfs requiere especialización y se recomienda siempre hacer imagen del dispositivo antes de cualquier intento de reparación.
5. Escenarios de fallo más comunes en md-RAID
Los fallos de md-RAID pueden ser físicos (un disco deja de funcionar mecánicamente) o lógicos (los datos físicos son legibles pero los metadatos del array o el filesystem están corruptos). Los escenarios lógicos son los más frecuentes y los que más confunden a los administradores, porque los discos parecen estar bien pero el array no arranca.
Corrupción del superbloque md-RAID
Si el superbloque de uno o varios discos del array resulta dañado —por un corte de corriente durante una escritura de metadatos, un sector defectuoso en la zona donde reside el superbloque, o un error de firmware del disco— mdadm no puede identificar correctamente los miembros del array al arrancar. El síntoma más habitual es que el array no se ensambla automáticamente y aparece como "inactive" en /proc/mdstat. Si el superbloque de un único disco está corrupto y el array tiene paridad o espejado, el laboratorio puede reconstruir el superbloque dañado usando los metadatos de los discos sanos.
Disco extraído incorrectamente (wrong drive removed)
En un RAID 5 con un disco en fallo, el administrador identifica el disco a reemplazar consultando los logs o las alertas del sistema. Si extrae el disco activo (el espejo superviviente en RAID 1, o uno de los discos de datos en RAID 5 ya degradado) en lugar del disco fallido, el array pierde su segunda fuente de datos: en RAID 5 ya degradado, la extracción del disco activo equivale a un segundo fallo simultáneo, y el array cae. Este es uno de los errores más devastadores y más frecuentes: en un servidor sin etiquetas físicas en los slots, la confusión entre el disco "/dev/sdb" y "/dev/sdc" puede ser fatal.
Reconstrucción fallida o abortada
Cuando mdadm inicia la reconstrucción de un array RAID 5 con un disco fallido y el disco destino de la reconstrucción (o uno de los discos supervivientes de datos) tiene Uncorrectable Read Errors (UREs), la reconstrucción se aborta. El array queda en un estado inconsistente: la paridad no ha sido regenerada completamente, y el array puede estar marcado como "dirty" o "degraded" con una reconstrucción en porcentaje incompleto. En ese estado, intentar montar el array puede resultar en un filesystem con bloques de datos corruptos.
Disco del SO falla pero el RAID de datos está intacto
En muchos servidores Linux, el sistema operativo está en un disco SATA o SSD independiente, y los datos (bases de datos, ficheros compartidos, backups) están en un array md-RAID separado. Si el disco del SO falla completamente, el servidor no arranca pero el array de datos está físicamente intacto. El desafío es ensamblar el array sin el sistema operativo original, lo cual requiere conocer la configuración del array (nivel, chunk size, discos miembro) que estaba en el fichero /etc/mdadm/mdadm.conf del sistema caído. Si ese fichero no está disponible, mdadm puede intentar reconstruir el array mediante escaneo (mdadm --assemble --scan), pero con superbloques corruptos o inconsistentes esto falla.
Pérdida del fichero mdadm.conf y UUID conflicts
El fichero /etc/mdadm/mdadm.conf contiene la configuración de todos los arrays md-RAID del sistema: UUID de cada array, dispositivos miembro, nivel y opciones. Si este fichero se pierde (disco del SO fallido, reinstalación del SO sin preservar la configuración, migración a otro servidor), mdadm tiene que reconstruir el array por escaneo de superbloques. Si alguno de los discos ha sido reemplazado por un disco de repuesto con un superbloque de una versión anterior del array (conflicto de UUID), mdadm puede rechazar ensamblar el array o ensamblarlo con la configuración incorrecta.
Conflictos de UUID tras reemplazo de disco
Cuando se reemplaza un disco de un array md-RAID y se añade el disco nuevo con mdadm --add, mdadm escribe el superbloque del array en el disco nuevo con el mismo UUID del array. Si en algún momento el disco antiguo (el que se suponía fallido) vuelve a conectarse al sistema —por ejemplo, porque el "fallo" era en realidad un conector SATA flojo— el kernel verá dos discos con el mismo UUID de array pero con el superbloque en estados distintos: uno con los datos más recientes y otro con los datos anteriores. mdadm puede rechazar ensamblar el array hasta que el conflicto se resuelve manualmente, y resolver este conflicto incorrectamente puede resultar en datos sobrescritos.
6. Qué NO hacer cuando el md-RAID falla
Errores que destruyen las posibilidades de recuperación
- Ejecutar
mdadm --zero-superblock /dev/sdX: Este comando borra el superbloque md-RAID del disco especificado. Es irreversible: si borras el superbloque del disco equivocado, o del disco correcto antes de haber hecho una imagen, eliminas los metadatos del array en ese disco. Sin el superbloque, el laboratorio tiene que reconstruir la geometría del array desde cero, analizando los patrones de datos en bruto. No ejecutes este comando bajo ninguna circunstancia mientras estés en modo de emergencia. - Forzar el ensamblaje degradado sin imagen previa (
mdadm --assemble --force): Si intentas forzar el ensamblaje de un array RAID 5 con un disco faltante para poder montar el volumen y copiar los datos, el kernel calculará la paridad "faltante" a partir de los discos disponibles y marcará el array como "dirty". Si el estado de paridad en los discos no es coherente (por una reconstrucción incompleta anterior, por ejemplo), el montaje del filesystem puede resultar en escrituras de reparación que sobrescriben bloques de datos válidos. Siempre haz imagen de todos los discos antes de cualquier intento de ensamblaje forzado. - Ejecutar
fsckoe2fsckdirectamente sobre el dispositivo md degradado: Las herramientas de reparación de filesystem escriben en el volumen para corregir inconsistencias. Si el array subyacente está en estado inconsistente, estas escrituras pueden ampliar el daño. fsck sobre un filesystem cuya paridad no ha sido reconstruida puede generar una cascada de reasignaciones de bloques que hace irrecuperables archivos que de otro modo habrían sido accesibles. - Reinstalar el sistema operativo sobre los discos del array: Si el disco del SO ha fallado y la tentación es reinstalar Linux sobre uno de los discos del array de datos para "tener un sistema operativo funcional cuanto antes", el formateado del disco miembro destruye su superbloque y sus datos. Aunque solo se afecte a un disco del array, en un RAID 5 ya degradado eso equivale a un segundo fallo irrecuperable.
- Dejar el array montado con errores de I/O: Si el sistema reporta errores de lectura/escritura pero el array sigue montado, cada operación de escritura que realiza el sistema operativo (logs, caché de bases de datos, ficheros temporales) puede sobrescribir datos recuperables. Ante errores de I/O persistentes en el array, desmonta el volumen de forma segura (
umount) y detén el array (mdadm --stop /dev/md0) antes de apagar el sistema. - Cambiar el orden de los discos en los slots sin documentar: En un servidor con varios discos, el nombre del dispositivo Linux (
/dev/sda,/dev/sdb…) puede cambiar entre reinicios si cambia el orden de detección del hardware. Etiqueta físicamente cada disco con su posición (Slot 0, Slot 1, Disco 1 de 4…) antes de extraer ninguno.
El principio fundamental ante cualquier fallo de md-RAID es: apaga el sistema de forma ordenada, etiqueta cada disco con su posición y llama al laboratorio antes de ejecutar ningún comando de mdadm. Si el array sigue operativo en modo degradado, haz backup inmediato de los datos críticos mientras decides el siguiente paso.
7. Proceso de recuperación profesional en laboratorio
La recuperación de un md-RAID fallido en laboratorio sigue un proceso forense estructurado que protege los datos originales en todo momento. El punto de partida es siempre el diagnóstico gratuito: evaluamos el estado de cada disco y el array antes de emitir ningún presupuesto.
Fase 1: Diagnóstico individual de cada disco
Evaluamos el estado SMART y la legibilidad de cada disco miembro del array por separado, usando herramientas especializadas (PC-3000 UDMA, DeepSpar Disk Imager). Un disco marcado como "failed" por mdadm puede tener solo un sector defectuoso en la zona del superbloque, siendo físicamente recuperable en su totalidad. El diagnóstico distingue entre fallos físicos (cabezales, platos, PCB, motor) y fallos lógicos (superbloque, paridad inconsistente, filesystem corrupto), lo cual determina la estrategia y el presupuesto.
Fase 2: Imagen forense de todos los discos
Antes de cualquier operación sobre el array, creamos imágenes sector a sector de todos los discos miembro, incluidos los marcados como fallidos. Las imágenes se crean con herramientas que gestionan los errores de lectura de forma no destructiva: reintentan sectores problemáticos con parámetros optimizados, documentan los bloques ilegibles y continúan la imagen aunque haya sectores irrecuperables. Si algún disco requiere reparación física previa (sustitución de cabezales en sala limpia ISO Clase 5, recuperación de PCB quemada, desbloqueado de firmware), se realiza antes de intentar la imagen. A partir de este punto, todo el trabajo se realiza sobre las imágenes; los discos originales se depositan en almacén seguro.
Fase 3: Análisis y reconstrucción del superbloque
Con las imágenes disponibles, analizamos los superbloques de todos los discos. Si el superbloque de uno o varios discos está corrupto, podemos reconstruirlo a partir de los superbloques de los discos sanos: todos los discos de un array md-RAID comparten el mismo UUID de array, el mismo nivel RAID, el mismo chunk size y la misma geometría. La única información específica de cada disco en el superbloque es su posición en el array (el rol del disco: data disk 0, data disk 1, spare…) y el evento count (contador de las últimas operaciones de escritura del array, usado para determinar cuál es la copia más reciente en caso de inconsistencia).
Determinamos la versión del superbloque (0.9, 1.0, 1.1 o 1.2) y localizamos los metadatos en cada imagen en la ubicación correspondiente. Si los superbloques están ausentes o irrecuperables en todos los discos, pasamos a determinar la geometría del array por análisis de patrones de datos.
Fase 4: Determinación de la geometría del array
Si el array no puede ensamblarse por información del superbloque, determinamos la geometría analizando los patrones de datos en las imágenes. Los parámetros clave son el chunk size (tamaño del bloque de stripe, habitualmente 512 KB en mdadm moderno, aunque puede ser 64 KB, 128 KB o 256 KB en configuraciones antiguas), el orden de los discos en el stripe (qué disco aporta qué parte del stripe), el algoritmo de rotación de paridad en RAID 5 (left-symmetric, right-symmetric, left-asymmetric, right-asymmetric — mdadm usa left-symmetric por defecto) y el offset de datos (desplazamiento desde el inicio del disco hasta donde comienzan los datos del array, que en las versiones 1.x del superbloque es de 2 MiB por defecto para alineación óptima).
Utilizamos el módulo RAID del PC-3000 RAID (ACE Laboratory), que aplica heurísticas de detección automática del chunk size y el layout buscando estructuras reconocibles del filesystem (superbloque ext4 en los grupos de bloques esperados, árbol B+ XFS en las posiciones de allocation group, cabeceras de partición GPT) en el array virtual reconstruido con distintas configuraciones. La validación se confirma cuando el array virtual produce un filesystem coherente y montable.
Fase 5: Ensamblaje virtual y extracción de datos
Con la geometría confirmada, ensamblamos el array virtual en el software de recuperación y montamos el filesystem. Si el filesystem está íntegro, la extracción de datos es completa y estructurada: se conservan la jerarquía de directorios, los nombres de fichero, las fechas de modificación y los permisos. Si el filesystem presenta corrupción (tablas de inodos dañadas, diario del filesystem en estado inconsistente), aplicamos herramientas de reparación forense sobre el array virtual o realizamos file carving estructurado para recuperar el máximo de ficheros aunque la estructura de directorios no sea completamente recuperable.
Fase 6: Verificación y entrega
Los datos recuperados se verifican antes de la entrega: comprobamos integridad con hashes MD5/SHA256 en los ficheros críticos y abrimos una muestra representativa de documentos, bases de datos y archivos de mayor tamaño. La entrega se realiza en disco duro externo nuevo o mediante descarga cifrada SFTP. Se incluye un informe técnico detallado con la geometría del array reconstruido, la versión del superbloque, el filesystem identificado, el porcentaje de cobertura de bloques y la relación de ficheros no recuperables.
8. Precios orientativos
El precio de la recuperación depende del número de discos del array, del tipo de fallo (lógico o físico) y de si algún disco requiere intervención en sala limpia. El diagnóstico es siempre gratuito: evaluamos el array antes de emitir presupuesto, y si no conseguimos recuperar los datos, no se cobra nada.
| Configuración md-RAID | Tipo de fallo | Precio estimado (+ IVA) | Plazo habitual |
|---|---|---|---|
| RAID 1 (2 discos), 1 disco fallido — fallo lógico | Superbloque corrupto, mdadm.conf perdido | 800 – 1.400 € | 4 – 7 días |
| RAID 1 (2 discos), 1 disco fallido — fallo físico | PCB, cabezales, motor en 1 disco | 1.200 – 2.200 € | 7 – 12 días |
| RAID 5 (3–4 discos), fallo lógico | Paridad inconsistente, superbloque, disco extraído por error | 1.200 – 2.000 € | 6 – 10 días |
| RAID 5 (3–6 discos), fallo físico en 1 disco | Sala limpia en 1 disco + reconstrucción de array | 1.800 – 3.000 € | 10 – 15 días |
| RAID 6 (4–8 discos), fallo lógico / reconstrucción abortada | Paridad doble inconsistente, superbloques dañados | 1.800 – 3.200 € | 8 – 14 días |
| RAID 5/6 con daño físico en 2+ discos | Sala limpia múltiple + reconstrucción de array | 2.500 – 4.000 € | 12 – 18 días |
Disponemos de servicio urgente con prioridad máxima para empresas y servidores de producción que necesitan recuperar el acceso a sus datos en el menor tiempo posible. Consulta disponibilidad al contactar.
Diagnóstico gratuito en 4 horas. Sin recuperación, sin coste. Recogida urgente en toda España.
Solicitar diagnóstico gratuitoO llámanos: 900 899 002
9. Preguntas frecuentes sobre md-RAID y recuperación de datos
mdadm --assemble --scan o reconstruir manualmente la línea de configuración. Sin embargo, si hay algún superbloque corrupto, discrepancia de event count entre discos, o el array quedó "dirty" tras un corte de corriente, el intento manual de ensamblaje puede agravar el daño. La recomendación segura es hacer primero imágenes de todos los discos con ddrescue o similar, y trabajar siempre sobre las imágenes. Si no tienes experiencia con mdadm y la recuperación de los datos es crítica, contacta al laboratorio antes de ejecutar ningún comando.
/proc/mdstat y los logs del sistema. Si el array aparece como "degraded" con un disco ausente, verifica si el disco simplemente se desconectó (cable SATA, alimentación) y puede añadirse de nuevo. Si el array aparece como "inactive" o da errores al montar, no intentes forzar el montaje ni ejecutar fsck: apaga el NAS y contacta con el laboratorio para diagnóstico gratuito.
mdadm --examine /dev/sdX en cualquier Linux (aunque el array no esté ensamblado). El campo "Version" en la salida indica la versión del superbloque.
WhatsApp