Se reemplazó un disco de 4 TB en una matriz SHR de Synology por un disco de 8 TB. La reconstrucción (rebuild) se inició, avanzó durante un tiempo y luego se detuvo. DSM muestra Degraded, Crashed, o la barra de progreso no se ha movido en horas. El NAS puede haber quedado completamente inoperativo. Este artículo aborda la recuperación de datos tras una falla en la reconstrucción de un SHR: qué ocurrió dentro de la matriz, cómo interpretar el estado actual sin agravar el problema y cómo recuperar sus archivos.
Antes de intervenir
Tres acciones parecen lógicas cuando una reconstrucción (por ejemplo, una reconstrucción de RAID) se congela — y cualquiera de ellas puede convertir una situación recuperable en una pérdida permanente de datos:
Reinicio del NAS
Un array RAID degradado conserva el estado de sus miembros en memoria. Un reinicio obliga a mdadm a volver a leer los superbloques desde el disco —si esos superbloques están desincronizados por una reconstrucción interrumpida, el array podría no reensamblarse en absoluto tras el reinicio.
Extracción de discos
Esto afecta incluso al disco que DSM marca como «Faulty». Al retirar un miembro se altera el recuento del conjunto RAID y mdadm actualiza los superbloques de las unidades restantes, registrando la extracción como un evento permanente. Como resultado, una unidad que en realidad era legible puede quedar excluida de forma definitiva.
Hacer clic en «Reparar» en el Administrador de almacenamiento
La opción «Reparar» inicia un nuevo intento de reconstrucción. Si la reconstrucción inicial falló debido a errores de lectura en una unidad existente, un segundo intento vuelve a leer los mismos sectores — agravando el daño en una unidad ya sometida a estrés y aumentando el riesgo de un fallo adicional.
Apagado forzado
Un corte de energía repentino durante una reconstrucción activa (incluso si está congelada) puede escribir bloques de paridad parciales en la unidad nueva, dejando la matriz RAID en un estado en el que ni los datos antiguos ni los nuevos son coherentes. Para preservar la integridad de datos durante una reconstrucción RAID, utilice siempre el procedimiento de apagado de DSM si la interfaz sigue accesible.
Ejecutar fsck o btrfs check
Las herramientas de reparación de sistemas de archivos operan en la capa de volúmenes —un nivel por encima de la matriz RAID. Ejecutarlas en una matriz degradada implica que leerán datos reconstruidos que pueden contener errores de paridad y que podrían volver a escribir metadatos corruptos en el disco.
Agregar otra unidad
Al insertar un disco de repuesto en un conjunto RAID que ha fallado, DSM intenta una reconstrucción automática. Si no se identifica la causa del primer fallo de reconstrucción, un segundo intento encontrará el mismo problema —y además implicará otra ronda de lecturas de disco de todo el conjunto sobre un hardware ya sobrecargado.
Por qué falló la reconstrucción
Cuando SHR (Synology Hybrid RAID) sustituye un disco de distinta capacidad, realiza mucho más que una simple copia de datos. La secuencia es la siguiente:
mdadm lee todas las particiones de datos de los discos restantes a un rendimiento secuencial sostenido — durante horas o días en matrices RAID de varios terabytes.
Se calcula y escribe la paridad en el disco nuevo. En SHR con discos de tamaño mixto, mdadm utiliza varios dispositivos md de diferentes tamaños apilados, por lo que el cálculo de la paridad es más complejo que en un RAID 5 de geometría fija.
LVM recalcula la asignación de extents físicos en el pool de almacenamiento ampliado. Si el disco nuevo tiene mayor capacidad, esto implica remapear la disposición del Grupo de Volúmenes — una operación independiente que se ejecuta en paralelo o tras la reconstrucción de mdadm.
Cualquier error en cualquiera de las fases aborta la secuencia. Tres causas raíz explican la mayoría de los fallos de reconstrucción de SHR:
Errores de lectura irrecuperables (URE)
Los discos de consumo presentan una tasa de errores de lectura irrecuperables (URE) de aproximadamente 1 por cada 1014 bits leídos. En un disco de 4 TB, esto implica que, estadísticamente, es probable que ocurra un error de lectura en algún punto durante una pasada secuencial completa. En funcionamiento normal esos sectores rara vez se acceden. Durante una reconstrucción de RAID se leen todos los sectores — y un único sector ilegible detiene el cálculo de paridad de toda la franja. No es necesario que la unidad falle por completo; basta con que produzca un error de lectura en el momento inoportuno.
Tiempos de espera SATA bajo carga
Una conexión de cable o del backplane que sea marginal con cargas de trabajo normales puede fallar de forma constante durante las lecturas sostenidas de alto rendimiento propias de una reconstrucción del RAID. El kernel registra un error SATA; mdadm interpreta que el disco queda inaccesible y lo marca como «Faulty», aunque el disco en sí esté físicamente sano. Tras reconectar el dispositivo vuelve a funcionar, pero mdadm ya lo ha eliminado del conjunto RAID.
Tareas en segundo plano de DSM
Synology programa automáticamente pruebas S.M.A.R.T., la indexación de medios (para Photo Station y Video Station) y las comprobaciones de integridad de Btrfs (scrub). Cualquiera de estas tareas, si se ejecuta simultáneamente con una reconstrucción, compite por el mismo ancho de banda de E/S del disco. En un sistema que ya está realizando una lectura sostenida del disco al completo, las E/S adicionales pueden elevar la latencia de lectura hasta provocar tiempos de espera del disco, obteniéndose el mismo resultado que ante un problema de conexión física.
Para una comparación más amplia del riesgo de una reconstrucción frente a la recuperación directa de datos, consulte nuestro artículo sobre Reconstrucción de RAID frente a recuperación por software.
Leer el estado actual del array
Antes de cualquier intento de recuperación, determine exactamente qué informa mdadm. Si dispone de acceso por SSH, dos comandos ofrecen la información completa. Para una guía detallada sobre cómo interpretar la salida de mdadm, consulte nuestra guía de recuperación RAID con mdadm. A continuación se muestran los patrones específicos que debe buscar en este escenario.
cat /proc/mdstat — muestra el estado de ensamblaje y, si hay una reconstrucción en curso, el progreso y la velocidad actuales.
Una reconstrucción congelada se muestra así:
Personalities : [raid5] [raid6] [raid1] md3 : active raid5 sdb3[0] sdc3[1] sdd3[2] 5860468736 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/2] [UU_] [================>....] recovery = 83.2% (2436352/2930234) finish=∞ speed=0K/sec unused devices: <none>
finish=∞ y speed=0K/sec confirman que la reconstrucción se ha detenido: mdadm está bloqueado esperando un sector que no puede leer.
Un array caído se muestra así:
Personalities : [raid5] [raid6] [raid1] md3 : inactive sdb3[0](S) sdc3[1](S) 5860468736 blocks super 1.2 unused devices: <none>
inactive con las marcas (S) (spare) indica que mdadm no tiene el array activo: los dispositivos están presentes pero no ensamblados. Los datos están físicamente en los discos pero inaccesibles.
La tabla siguiente relaciona el estado que muestra DSM con lo que realmente ocurre y la acción recomendada:
| Qué muestra DSM | Qué significa | No hacer | Siguiente paso |
|---|---|---|---|
| Reconstrucción congelada, velocidad = 0 Degradado | Error de lectura no recuperable (URE) en una unidad existente que bloquea las escrituras de paridad. Array degradado pero íntegro. | No espere; no reinicie la reconstrucción | RS RAID Retrieve |
| Una unidad marcada como Faulty, reconstrucción detenida Degradado | mdadm descartó una unidad tras errores de lectura repetidos o errores SATA. Funcionando sin redundancia. | No retire la unidad marcada como Faulty | Comprobación S.M.A.R.T., luego RS RAID Retrieve |
| Pool de almacenamiento: Caído Caído | mdadm no pudo mantener el quórum. Array inactivo — datos presentes pero inaccesibles. | No haga clic en Reparar; no reinicie | RS RAID Retrieve |
| NAS no responde, DSM no carga Desconocido | Posible bloqueo del kernel durante E/S de reconstrucción. Estado del array desconocido. | No apagar por fuerza si es evitable | Apagado limpio manteniendo pulsado el botón de encendido, luego RS RAID Retrieve |
Recuperación de datos con RS RAID Retrieve
RS RAID Retrieve reconstruye la configuración del array SHR a partir de los superbloques de mdadm en las unidades restantes. Esta herramienta de recuperación de datos RAID funciona con arrays degradados en los que falta un miembro o está marcado como defectuoso, y ofrece acceso de solo lectura al volumen para la recuperación selectiva de archivos — sin iniciar un nuevo intento de reconstrucción.
Paso 1 — Conectar unidades y comprobar S.M.A.R.T.
Apague el NAS de forma ordenada si es posible. Conecte todas las unidades —incluida la que DSM marcó como defectuosa— a un equipo de recuperación y abra el monitor S.M.A.R.T. integrado en RS RAID Retrieve. Realice la comprobación S.M.A.R.T. en todos los discos, no solo en el que falló. Durante la reconstrucción del RAID, la unidad que aparenta estar sana suele ser la que provocó la avería por errores de lectura en un miembro del conjunto.
Paso 2 — Crear imagen de cualquier unidad con valores S.M.A.R.T. elevados
Si alguna unidad muestra valores no nulos en el Conteo de Sectores Reasignados, Sectores Pendientes o Errores No Corregibles, cree una imagen a nivel de sector (imagen sector por sector) de esa unidad utilizando la función de imagen integrada de RS RAID Retrieve antes de iniciar el escaneo. Todo el trabajo de recuperación posterior se realizará sobre la imagen. Esto protege la unidad de origen frente a lecturas adicionales durante el escaneo y evita un mayor deterioro en una unidad que ya está estresada.
Paso 3 — Reconstrucción automática del arreglo
RS RAID Retrieve lee el superbloque de mdadm de cada unidad o imagen conectada, identifica el UUID del conjunto, los roles de los miembros, el nivel RAID y los parámetros de franja (stripe), y reconstruye la estructura del volumen SHR. Para un arreglo RAID degradado con un miembro ausente o averiado, el programa puede reconstruir usando las unidades restantes: calcula los datos faltantes a partir de la paridad —de la misma forma que lo haría mdadm en modo degradado— pero sin escribir nada de vuelta en el disco.
Paso 4 — Examinar y recuperar archivos
Apague el NAS de forma ordenada siempre que sea posible. Conecte todos los discos —incluido el que DSM marcó como «Faulty»— a un equipo de recuperación de datos y abra el monitor S.M.A.R.T. integrado en RS RAID Retrieve. Verifique todas las unidades, no solo la que falló. Durante la reconstrucción del RAID, la unidad que aparenta estar sana suele ser la que provocó la falla debido a errores de lectura en el miembro existente.
Funciona con arreglos RAID degradados y averiados
Reconstruye volúmenes SHR a partir de los discos miembros disponibles sin exigir un arreglo RAID completo y operativo para la recuperación de datos —incluye arreglos inactivos que mdadm se niega a ensamblar—.
Monitorización S.M.A.R.T.
Compruebe la salud de la unidad antes de iniciar el escaneo. Permite identificar qué unidad provocó la falla de reconstrucción y si es necesario crear una imagen del disco antes de la recuperación de datos.
Creación de imagen de disco
Crear una imagen a nivel de sectores (imagen sectorial) de una unidad con problemas antes de la recuperación de datos. Todo el trabajo se realiza sobre la imagen forense, protegiendo el original de ciclos de lectura adicionales.
Conexión SSH
Si el NAS sigue encendido y es accesible en la red, RS RAID Retrieve puede conectarse mediante SSH — sin necesidad de extraer físicamente los discos del chasis.
Cuando la recuperación por software no es suficiente
Si varias unidades no aparecen al conectarlas al equipo de recuperación de datos, o si S.M.A.R.T. devuelve valores críticos en más de un miembro de la matriz, la situación ha superado el ámbito del software. Una matriz SHR‑1 con dos unidades fallidas carece de la paridad necesaria para reconstruir los datos: no existe una vía matemática para recuperar la información perdida únicamente mediante software, por lo que se requiere intervención física o un servicio profesional de recuperación de datos.
Detenga el equipo y contacte a un laboratorio de recuperación de datos si observa
- Dos o más discos duros o unidades no detectados, o que muestran fallo S.M.A.R.T. inmediato al encender
- Ruidos de clics, rechinamientos o fallos repetidos de arranque en cualquier unidad
- RS RAID Retrieve no puede reconstruir la matriz ni siquiera en modo manual
- Las unidades se encuentran calientes al tacto a los pocos minutos de conectarlas
La recuperación física de datos — sustitución de cabezas, transferencia de platos — requiere instalaciones con sala limpia. Cada ciclo de encendido adicional en una unidad con fallo mecánico reduce la probabilidad de recuperación de datos.
Después de la recuperación: prevención de la próxima falla de reconstrucción
Una caída durante la reconstrucción del RAID al reemplazar una unidad no es aleatoria. Se dirige a una vulnerabilidad específica: todas las unidades restantes están sometidas a la carga máxima sostenida de lectura en el instante exacto en que el conjunto RAID queda sin redundancia. Los pasos siguientes reducen la probabilidad de que se repita este escenario.
Comprobar S.M.A.R.T. antes de reemplazar una unidad
Ejecute una prueba S.M.A.R.T. completa (extendida) en todas las unidades restantes antes de retirar la unidad antigua. Un disco con sectores reasignados o errores pendientes probablemente provoque un URE (error de lectura irrecuperable) durante la reconstrucción posterior del RAID.
Desactivar tareas en segundo plano de DSM durante la reconstrucción
Vaya a Panel de control → Programador de tareas y suspenda las pruebas programadas S.M.A.R.T., las operaciones scrub de Btrfs y los escaneos de la biblioteca multimedia durante la reconstrucción (por ejemplo, de un RAID). Las E/S concurrentes son una de las causas de fallo de reconstrucción más fácilmente evitables.
Reconectar los cables SATA antes de iniciar
Una conexión marginal que funciona con cargas ligeras puede fallar bajo el rendimiento sostenido de una reconstrucción prolongada (por ejemplo, una reconstrucción RAID de varios días). Desconecte y reconecte todos los cables SATA de datos y de alimentación antes de iniciar el proceso de reemplazo.
No mezclar lotes de unidades de almacenamiento
Las unidades adquiridas al mismo tiempo y procedentes de la misma serie de producción acumulan desgaste a la misma tasa. Cuando una falla, las demás unidades suelen fallar poco después. Procure obtener unidades de reemplazo de un fabricante o de un lote de producción distinto para reducir el riesgo de fallos simultáneos y mejorar la fiabilidad del almacenamiento (HDD/SSD).
Habilitar notificaciones por correo en DSM
Panel de control → Notificación → Correo electrónico. DSM puede emitir una alerta en cuanto una unidad se marca como defectuosa o un grupo de almacenamiento se degrada. Detectar la falla de forma temprana —antes de que la reconstrucción supere las 60 horas— permite conservar más opciones de recuperación.
Mantener una copia de seguridad independiente
SHR ofrece tolerancia a fallos, no copia de seguridad. Un conjunto degradado durante la reconstrucción no está protegido frente a una segunda falla. Hyper Backup a una unidad externa o a un destino en la nube es la única garantía de que un fallo durante la reconstrucción no se convierta en una pérdida de datos permanente.
Un fallo de reconstrucción durante el reemplazo de una unidad es uno de los escenarios de pérdida de datos en SHR más habituales, precisamente porque se produce en el peor momento posible: carga máxima de E/S sobre el hardware más antiguo del conjunto, con margen de redundancia nulo. Una vez recuperados los datos, el suceso debe interpretarse como una señal —no solo sobre la unidad que falló, sino sobre la salud y la integridad de todo el hardware que convivía en el conjunto.
