Dos unidades han fallado en su matriz Synology SHR-1. DSM informa de que el grupo de almacenamiento se ha bloqueado y que los datos no pueden recuperarse. La recuperación de datos en SHR-1 tras una doble avería de disco es el tema de este artículo, y la situación es más matizada de lo que sugiere el mensaje de DSM. La posibilidad de recuperar los datos no depende únicamente del número de discos averiados, sino de cómo se produjo el fallo y del estado en que se encuentran las unidades que siguen operativas.

Identifique primero su situación
Antes de continuar, utilice esta tabla para localizar su caso concreto y vaya directamente a la sección correspondiente:
| Lo que observa | Situación probable | Posibilidades de recuperación | Ir a |
|---|---|---|---|
| Ambos discos aparecen en el sistema operativo y los superbloques son legibles | Fallo lógico: los discos están físicamente intactos | Posible | Nivel 1 → Nivel 2 |
| Un disco es legible y el otro no se detecta | Un fallo lógico + un fallo físico | Parcial | Nivel 2 → Nivel 3 |
| El segundo disco falló durante la reconstrucción después del primero | Fallo doble clásico: es probable una pérdida parcial de datos | Parcial | Nivel 2 |
| Uno o ambos discos emiten clics o chirridos y no se detectan | Fallo físico: cabezales o platos | Requiere laboratorio | Nivel 3 |
Por qué dos fallos rompen matemáticamente SHR-1
SHR-1 utiliza un único conjunto de paridad, conceptualmente equivalente a RAID 5 en términos de tolerancia a fallos. En cada franja (stripe) del array, una unidad almacena la paridad XOR del resto. Cuando falla una unidad, cualquier bloque de datos perdido puede recalcularse: basta con tomar el bloque de paridad y aplicar XOR con todos los bloques de datos restantes para recuperar el valor faltante. Esto funciona porque hay una incógnita y una ecuación.
Con dos unidades averiadas, hay dos incógnitas por franja y sigue existiendo solo una ecuación de paridad. Matemáticamente, el problema no tiene solución. Ningún software, independientemente de cómo se comercialice, puede reconstruir dos valores desconocidos e independientes a partir de una sola relación XOR. No se trata de una limitación de una herramienta concreta, sino de una propiedad intrínseca del esquema de paridad.
Lo que el software sí puede hacer es recuperar datos de franjas en las que solo participaba una de las dos unidades fallidas. Si sus archivos están almacenados en franjas que no incluyen simultáneamente ambas unidades averiadas, podrán recuperarse. Los archivos que abarcan franjas en las que intervienen las dos unidades afectadas no serán recuperables. La proporción de datos recuperables depende del tamaño y la distribución de las unidades fallidas dentro del array RAID, motivo por el cual a menudo es posible una recuperación parcial incluso cuando no es viable una recuperación completa.
SHR-2 almacena dos conjuntos de paridad independientes por franja, de forma análoga a RAID 6, y admite hasta dos fallos simultáneos de discos sin pérdida de datos. Sin embargo, SHR-2 no es inmune a este escenario: tres fallos simultáneos rompen su matemática de paridad del mismo modo que dos fallos rompen SHR-1. Si está utilizando SHR-2 y ha perdido tres discos, se aplica la misma lógica que se explica a continuación. Para una comparación práctica de la tolerancia a fallos de SHR-1 y SHR-2, consulte nuestro artículo sobre recuperación de SHR/SHR-2 tras un fallo de hardware de Synology.
Importa cómo fallaron las dos unidades
No todos los fallos dobles son equivalentes. La secuencia y la naturaleza de las fallas determinan qué opciones de recuperación de datos son posibles:
Fallo simultáneo: evento de alimentación o controlador
Ambos discos dejaron de responder al mismo tiempo. Es probable que los datos de cada unidad estén físicamente intactos; simplemente el RAID perdió el quórum. Se trata de la versión más recuperable de un doble fallo, ya que no se sobrescribió parcialmente la información de ninguno de los discos.
Fallo de la segunda unidad durante la reconstrucción
La primera unidad falló, el conjunto de discos funcionó en modo degradado y se inició la reconstrucción; sin embargo, la segunda unidad falló a mitad del proceso. La nueva paridad se estaba escribiendo en la unidad de sustitución cuando falló la segunda unidad original. Las franjas que se reconstruyeron antes del segundo fallo permanecen intactas; las franjas que se estaban reconstruyendo en el momento del segundo fallo quedan dañadas. Por lo general, es posible una recuperación parcial.
La primera unidad falló hace tiempo, sin que se detectara
El RAID funcionó en modo degradado, es decir, sin redundancia, durante un período prolongado, y después falló la segunda unidad. Si el primer fallo pasó desapercibido, es posible que, entretanto, se hayan realizado escrituras adicionales en las franjas degradadas. Las probabilidades de recuperación dependen por completo del estado físico de la segunda unidad averiada. Consulte nuestro artículo sobre cómo reconocer a tiempo los primeros síntomas de fallo de disco duro para detectar este problema antes.
Evalúe el estado físico de cada unidad
Antes de iniciar cualquier intento por software, determine si las unidades se pueden leer físicamente. Apague correctamente el NAS si sigue en funcionamiento — no fuerce el reinicio y no inserte una unidad de reemplazo, ya que eso haría que DSM intentara ejecutar otra reconstrucción. Conecte cada unidad de forma individual a un equipo de recuperación.
Si alguna unidad emite clics audibles, sonidos de rozamiento o realiza varios intentos fallidos de puesta en marcha — apáguela de inmediato y no intente seguir leyéndola. Cada ciclo de arranque en una unidad con cabezales dañados incrementa el daño en los platos. Vaya directamente al nivel 3.
En las unidades que arrancan sin emitir ruido, ejecute mdadm --examine en cada partición del dispositivo:
mdadm --examine /dev/sdb3 Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 4b2f8e1a:7c3d9f02:1a4b8c3d:9e2f7b01 Name : DiskStation:2 Creation Time : Fri Mar 10 14:22:31 2023 Raid Level : raid5 Raid Devices : 3 Avail Dev Size : 7813959680 Array Size : 15627862016 Used Dev Size : 7813931008 Data Offset : 2048 sectors Super Offset : 8 sectors Unused Space : before=1968 sectors, after=0 sectors State : clean, degraded Device UUID : 9d3f1c2a:4e8b7f03:2c1d9e4b:7a3f8c01 Update Time : Mon Jun 2 09:14:22 2025 Bad Block Log : 512 entries available at offset 16 sectors Checksum : 3f8a1b2c - correct Events : 247
Busque tres elementos: el UUID del array debe coincidir en todas las unidades; si no coincide, la unidad pertenece a otro array o el superblock está dañado. El contador Events debe ser similar entre todos los miembros; una diferencia importante indica que una unidad se perdió un número significativo de operaciones de escritura. El campo State mostrará clean, degraded en una unidad que formaba parte de un array que perdió uno de sus miembros.
Además, abra en este punto el monitor S.M.A.R.T. integrado en RS RAID Retrieve. Los valores de Reallocated Sector Count y Pending Sectors en una unidad superviviente son importantes: una unidad que acumula sectores defectuosos durante un periodo ya degradado puede haber generado errores de lectura silenciosos que afectaron a la integridad de los datos antes de que se produjera el segundo fallo. Para más información sobre la interpretación de los datos S.M.A.R.T., consulte nuestro artículo sobre síntomas de fallo de disco duro.
Tres niveles de recuperación
Intente esta vía únicamente si mdadm --examine devuelve superblocks válidos con UUID coincidentes en todas las unidades. El enfoque desde terminal ofrece control directo sobre cada paso, pero tiene limitaciones importantes: requiere que todas las unidades estén físicamente presentes y sean legibles, no dispone de una alternativa de recuperación si los superblocks están dañados y no permite identificar de antemano qué archivos están corruptos. Cree una imagen de cada unidad con ddrescue antes de ejecutar cualquiera de los comandos siguientes; trabaje exclusivamente a partir de las imágenes.
Paso 1 — Crear una imagen de cada unidad antes de cualquier otra acción
# Instalar ddrescue si no está presente apt-get install -y gddrescue # Crear una imagen de cada unidad en un archivo independiente — ejecutar para cada miembro ddrescue -d -r3 /dev/sdb /mnt/images/sdb.img /mnt/images/sdb.log ddrescue -d -r3 /dev/sdc /mnt/images/sdc.img /mnt/images/sdc.log ddrescue -d -r3 /dev/sdd /mnt/images/sdd.img /mnt/images/sdd.log
La opción -r3 indica a ddrescue que reintente tres veces la lectura de los sectores no legibles antes de marcarlos como fallidos. El archivo .log permite reanudar el proceso de creación de imagen si se interrumpe. No omita este paso: una unidad con sectores defectuosos ocultos se degradará aún más bajo la carga de lectura sostenida que implica la reconstrucción del RAID.
Paso 2 — Verificar los superblocks en todos los miembros
# Ejecutar en cada imagen — confirmar que el UUID y los Events coinciden mdadm --examine /mnt/images/sdb.img mdadm --examine /mnt/images/sdc.img mdadm --examine /mnt/images/sdd.img
Antes de continuar, confirme tres aspectos. El Array UUID debe ser idéntico en todas las imágenes; si hay discrepancias, significa que una unidad pertenece a un arreglo RAID distinto o que su superblock está corrupto. El contador Events debe ser similar en todos los miembros; una diferencia de cientos o miles indica que una unidad se perdió una secuencia importante de escrituras. El recuento Raid Devices debe coincidir con el número esperado de miembros.
Paso 3 — Forzar el ensamblado a partir de archivos de imagen
# Indicar al kernel que trate los archivos de imagen como dispositivos de bloque losetup /dev/loop0 /mnt/images/sdb.img losetup /dev/loop1 /mnt/images/sdc.img losetup /dev/loop2 /mnt/images/sdd.img # Forzar el ensamblado: especificar las particiones de datos, no el dispositivo completo mdadm --assemble --force /dev/md0 /dev/loop0p3 /dev/loop1p3 /dev/loop2p3 # Comprobar el resultado del ensamblado cat /proc/mdstat mdadm --detail /dev/md0
--force ensambla el array RAID incluso sin un número suficiente de miembros para un estado coherente. El array resultante queda degradado. Los stripes que implicaban ambos discos fallados contienen datos reconstruidos con una paridad incorrecta; los archivos almacenados en esos stripes se corromperán o quedarán con tamaño cero al copiarlos. Los archivos de los stripes que afectaron solo a uno de los discos fallados permanecen intactos y son legibles. No es posible determinar externamente qué archivos pertenecen a cada categoría antes de intentar copiarlos.
Paso 4 — Activar LVM y montar en modo solo lectura
# Activar el grupo de volúmenes LVM en el conjunto ensamblado pvscan vgchange -ay # Listar los volúmenes lógicos para identificar la ruta correcta del dispositivo lvs # Montar en solo lectura — nunca montar con rw en un array dañado mount /dev/vg1/volume_1 /mnt/data -o ro
Monte siempre con -o ro. Escribir en un array reconstruido de forma forzada en este estado propagará la corrupción a franjas que antes estaban intactas. Una vez montado, verifique la estructura de directorios y el tamaño de los archivos antes de iniciar cualquier operación de copia. Los archivos dañados se manifiestan como errores de lectura, errores de E/S o resultados de cero bytes durante la copia; no existe un indicador previo.
Paso 5 — Copia con control de errores
# Use rsync con registro de errores — omite los archivos ilegibles en lugar de detenerse rsync -av --ignore-errors /mnt/data/ /mnt/destination/ 2>&1 | tee /mnt/rsync.log # Revisar qué se omitió grep -i "error|failed|cannot" /mnt/rsync.log
cp estándar se detiene ante el primer error de lectura. rsync --ignore-errors registra el fallo y continúa con el siguiente archivo, maximizando la cantidad total de datos recuperados. Revise después el registro para identificar qué archivos no pudieron copiarse; esos son los que estaban en bloques de datos que dependían de ambos discos fallidos.
Cuándo detenerse y pasar al Nivel 2:
mdadm --examine muestra UUID distintos entre las unidades; el ensamblado con --force falla o genera un array inactive en /proc/mdstat; la activación de LVM no encuentra ningún grupo de volúmenes; el sistema de archivos se monta, pero muestra un árbol de directorios vacío o dañado. Cualquiera de estos casos indica que el superblock o los metadatos de LVM están demasiado dañados para una recuperación manual: el Constructor RAID de RS RAID Retrieve gestiona estos escenarios.
RS RAID Retrieve cubre todo el proceso — evaluación S.M.A.R.T., creación de imágenes de los discos, reconstrucción del array RAID, activación de LVM y acceso al sistema de archivos — en una única aplicación para Windows, Linux o macOS. Incluye dos rutas de reconstrucción distintas en función del estado de los superblocks de mdadm.
Evaluación S.M.A.R.T. — antes de cualquier operación de lectura
Conecte todas las unidades a la máquina de recuperación y abra el monitor S.M.A.R.T. integrado antes de iniciar el escaneo. Los atributos más importantes en este escenario son Reallocated Sector Count (ID 05), Current Pending Sector Count (ID C5) y Uncorrectable Sector Count (ID C6). Los valores distintos de cero en cualquiera de estos parámetros, especialmente en las unidades que parecen ser las supervivientes «en buen estado», indican sectores que ya presentaban fallos durante el periodo de degradación, antes de que fallara la segunda unidad. Una unidad superviviente con sectores pendientes elevados es una unidad que puede generar errores de lectura a mitad de un escaneo de reconstrucción de varias horas.
Creación de imagen de unidad: proteja los originales del estrés de lectura
Para cualquier unidad con valores S.M.A.R.T. elevados, utilice la función integrada de creación de imagen de RS RAID Retrieve para generar una imagen a nivel de sector antes del escaneo de reconstrucción. El generador de imágenes realiza varias pasadas sobre los sectores problemáticos, registra las áreas ilegibles mediante un mapa de sectores y produce un archivo de imagen completo que representa la mejor lectura posible de esa unidad. Todos los pasos posteriores — reconstrucción del RAID, activación de LVM, análisis del sistema de archivos — se ejecutan sobre el archivo de imagen estático y no sobre la unidad en vivo. Esto evita que la unidad se deteriore aún más debido a la carga de lectura de un escaneo completo del array, que en una configuración SHR de varios terabytes puede tardar varias horas.
Reconstrucción automática de arrays RAID — cuando los superblocks están intactos
RS RAID Retrieve analiza todas las unidades y las imágenes conectadas en busca de firmas de superblock de mdadm. Cuando las encuentra, lee el UUID del array, el nivel RAID, los roles de los dispositivos miembros, el tamaño del bloque de stripe y los contadores de eventos en todos los miembros. A continuación, reconstruye la topología del volumen SHR — array mdadm → LVM Physical Volume → Volume Group → Logical Volume → sistema de archivos Btrfs o ext4 — sin requerir un quórum válido y sin escribir nada en las unidades de origen. En un caso de doble fallo, en el que ambas unidades son físicamente legibles y los superblocks están intactos, este proceso normalmente no requiere intervención manual.
La reconstrucción opera en modo degradado: las stripes en las que participaron ambas unidades averiadas no pueden reconstruirse a partir de la paridad, y los archivos correspondientes se marcan como inaccesibles. Las stripes en las que solo participó una de las dos unidades averiadas se reconstruyen a partir de los datos del miembro restante y de la paridad; esos archivos se pueden recuperar por completo. El programa marca los archivos inaccesibles en el árbol de directorios antes del paso de copia, de modo que el alcance de la recuperación queda claro antes de escribir en el destino.
RAID Constructor: cuando los metadatos del superblock están dañados
Si la detección automática no arroja resultados —porque los superblocks están parcialmente sobrescritos, corrompidos por un evento de firmware o ausentes debido a un disco averiado que se escribió parcialmente durante la reconstrucción RAID—, cambie a RAID Constructor. Este modo permite definir manualmente todos los parámetros del conjunto RAID, sin depender en absoluto del superblock.
Primero, identifique el desplazamiento del sistema de archivos con el editor HEX integrado. Abra cada disco o imagen en el editor HEX y busque el marcador ASCII LABLEONE. En las configuraciones SHR y SHR-2, esta cadena marca el inicio del área de datos del volumen. El sector inmediatamente anterior al sector LABLEONE —que aparecerá relleno con ceros— es el sector de desplazamiento. Anote su número: este es el valor que debe introducirse como parámetro de desplazamiento (Offset) en RAID Constructor.
Introduzca los siguientes parámetros en RAID Constructor:
| Parámetro | Valor para SHR-1 | Valor para SHR-2 |
|---|---|---|
| Tipo de RAID | RAID 5 | RAID 6 / Left synchronous (P+Q) |
| Tamaño de bloque | 64 KB | 64 KB |
| Bytes por sector | 512 | 512 |
| Orden de las unidades | Debe coincidir con la secuencia original de bahías del NAS: primero la bahía 1 | |
| Desplazamiento | Número de sector obtenido en la búsqueda de LABLEONE (por unidad) | |
Si se desconoce el orden original de las unidades, determínelo por ensayo: agregue los discos a la lista de Selected Disks en distintos órdenes y observe el árbol del sistema de archivos reconstruido después de cada cambio. Un orden correcto genera una estructura de directorios reconocible; un orden incorrecto produce datos incoherentes o un árbol vacío. El valor de desplazamiento debe configurarse de forma individual para cada disco físico o imagen, ya que puede ser distinto entre miembros si en la configuración SHR original había discos de capacidades diferentes.
Si uno de los discos averiados no puede conectarse en absoluto —sin respuesta a nivel mecánico, no detectado—, utilice Add empty disk para insertar un marcador de posición en la posición correcta de la lista de unidades. RS RAID Retrieve trata ese marcador como un miembro totalmente ilegible: los stripes en los que ese disco aportaba datos se reconstruyen a partir de la paridad usando los miembros restantes (recuperando los datos de esos stripes), y los stripes en los que también se necesita su contribución de paridad se marcan como irrecuperables. Este es el máximo nivel de recuperación posible en una configuración con una unidad físicamente inaccesible.
Escaneo del sistema de archivos y recuperación selectiva de archivos
Una vez reconstruido el conjunto RAID, de forma automática o mediante RAID Constructor, RS RAID Retrieve analiza el sistema de archivos Btrfs o ext4 del volumen lógico. El análisis recorre el árbol del sistema de archivos, identifica las áreas intactas y dañadas, y genera un listado completo de directorios. Los archivos y carpetas cuyos bloques de datos intersectan con franjas irrecuperables se marcan antes de iniciar la copia, por lo que no es necesario realizar pruebas de copia para determinar qué contenido es accesible.
Seleccione los archivos y carpetas que desea recuperar, indique un destino en otra unidad con espacio libre suficiente e inicie la copia. Las unidades de origen y las imágenes se acceden siempre en modo de solo lectura durante toda la operación. Para obtener orientación sobre la capa LVM entre el conjunto mdadm y el sistema de archivos, consulte nuestro artículo sobre la estructura y funcionamiento de LVM.
La recuperación de datos por software, en cualquier nivel, depende de que los cabezales de lectura/escritura de la unidad puedan entregar datos de sector al controlador anfitrión. Cuando el conjunto de cabezales presenta daños mecánicos, el actuador de la bobina móvil se ha bloqueado o el rodamiento del husillo ha fallado, la unidad no puede atender solicitudes de lectura independientemente de la configuración de software. Un laboratorio sustituye el conjunto de cabezales en una sala limpia (clase ISO 5 o superior), ajusta la alineación de los cabezales para cada plato en concreto y utiliza herramientas a nivel de firmware para extraer datos de sector de áreas que la propia electrónica de la unidad se negaría a leer.
El resultado de la intervención en laboratorio es un conjunto de archivos de imagen a nivel de sector, uno por unidad. Estas imágenes contienen la mejor lectura posible de la superficie de cada disco, incluidos los sectores recuperados de zonas físicamente dañadas que generan errores de E/S en condiciones normales. Una vez recibidas, estas imágenes se utilizan directamente en RS RAID Retrieve: RAID Constructor lee los superbloques (o utiliza el método de desplazamiento LABLEONE si los superbloques están dañados), reconstruye la topología del arreglo SHR y continúa con el análisis del sistema de archivos y la recuperación exactamente como se describe en el Nivel 2.
La limitación de paridad ante fallos dobles se aplica a las imágenes de laboratorio del mismo modo que a las unidades conectadas físicamente: las franjas que involucran a ambos miembros fallidos siguen siendo matemáticamente irrecuperables, independientemente de cuán limpia haya sido la extracción de los datos de sector. Lo que aporta el laboratorio es acceso a sectores que las herramientas de software ejecutadas sobre una unidad degradada en línea habrían omitido debido a errores de lectura, lo que puede incrementar de forma significativa la proporción de archivos recuperables.
Para obtener una visión más amplia sobre cuándo se recomienda la recuperación profesional de datos y en qué consiste el proceso, consulte nuestro artículo sobre la recuperación de datos de discos duros averiados.
Pase directamente al Nivel 3 si observa cualquiera de estas señales
- Sonido de clics, rozamiento o zumbido procedente de cualquier unidad al encenderla
- La unidad no se detecta en BIOS/UEFI ni en la salida de
lsblk - La unidad se detecta, pero
mdadm --examinedevuelve errores de E/S en lugar de datos del superbloque - La temperatura de la superficie de la unidad alcanza niveles anómalos en pocos minutos tras la conexión
- El valor S.M.A.R.T. Reallocated Sector Count (ID 05) está en los cientos, o el Spin Retry Count (ID C0) aumenta en cada ciclo de encendido
No intente una recuperación por software en una unidad con fallos mecánicos. Cada pasada de lectura añade desgaste a superficies de cabezales y platos ya dañadas. Apague el equipo y contacte con un laboratorio antes de intentar cualquier acceso adicional.
Un doble fallo en SHR-1 se sitúa en el límite entre la recuperación por software y la recuperación física de datos. Dónde se sitúe exactamente ese límite en su caso depende del estado de las unidades, no de las capacidades de las herramientas. Dos unidades físicamente íntegras con superbloques intactos ofrecen una vía real de recuperación parcial mediante software. Dos unidades con fallos mecánicos deben enviarse directamente a un laboratorio de recuperación de datos. La mayoría de los dobles fallos en entornos reales se sitúan entre esos dos extremos, por lo que evaluar el estado de la unidad antes de elegir una estrategia de recuperación es aquí más importante que en cualquier otro escenario de esta serie.





