La corrección más importante de esta fuente es que la matriz no permaneció como un RAID confirmado con «un disco averiado». Después de que el usuario iniciara el sistema con cada unidad por separado, ambas funcionaban individualmente. Al volver a conectar ambas unidades se produjo [UU] en /proc/mdstat, lo que significa que ambos miembros del RAID 1 estaban presentes y sincronizados en ese momento.
El hilo se amplió para abarcar la inestabilidad de SATA, los enlaces y la alimentación, los fallos de USB y del monitor, los arranques en modo de emergencia, los errores de NFS y el hecho de que ZimaOS volviera a la otra ranura del sistema. Los datos se recuperaron, pero la fuente nunca demuestra una causa final única. No lo conviertas en un sencillo tutorial de «reemplaza el disco X».
No hagas clic en Romper ni en Formatear mientras aún sea posible recuperar los datos
El primer consejo de la comunidad fue correcto en este punto de seguridad: si los datos son importantes y se desconoce el estado real de la matriz, las acciones destructivas de la interfaz pueden dificultar la recuperación. Haz primero una copia de seguridad de los datos legibles.
Cada disco funcionó al probarlo por separado
El autor original desconectó las unidades una por una y dijo que cada una producía una ruta funcional para el sistema y los datos. Eso debilitó de inmediato la suposición de que un disco hubiera muerto físicamente.
Volver a conectar ambos produjo una matriz md [UU] en buen estado
El estado publicado mostraba md0 : raid1 activo ... [2/2] [UU]. En ese momento, la capa md de Linux consideraba presentes ambos miembros.
Por eso, la conversación posterior se centró en la estabilidad de los cables, los puertos SATA, el controlador, los adaptadores o la placa posterior y la alimentación, en lugar de centrarse únicamente en los metadatos del RAID.
La inestabilidad de SATA o de la alimentación puede hacerse pasar por un fallo del RAID
Más adelante, la fuente informó de fallos más generales que afectaban al comportamiento de SATA, USB y la pantalla. Entre las sugerencias de la comunidad estuvieron reemplazar los cables SATA, probar otros puertos, evitar divisores o adaptadores inestables y realizar pruebas de carga mientras se vigilaban los reinicios de E/S.
Esos fueron diagnósticos de la comunidad, no un defecto de hardware confirmado por IceWhale.
Los problemas posteriores del modo de emergencia y NFS eran una capa independiente
Después de cambiar los cables y reiniciar, el sistema entró en modo de emergencia y mostró fallos relacionados con NFS/RPC. Los intentos de la comunidad por borrar el estado de NFS o desactivarlo no produjeron una reparación confirmada.
No se debe inferir que NFS causó la inaccesibilidad original del RAID; apareció más tarde en un sistema que ya presentaba una inestabilidad más generalizada.
El sistema también volvió a la otra ranura de ZimaOS
El usuario informó que había arrancado desde el bloque/la ranura B en lugar de A. El ZimaOS actual utiliza dos ranuras del sistema para la recuperación, por lo que la conmutación por error puede indicar que una de las ranuras del sistema no superó las comprobaciones de estado/arranque, no que se hayan perdido los datos del usuario en el RAID.
Consulta el modelo actual de recuperación de doble ranura de ZimaOS.
El ZimaOS actual tiene un flujo de trabajo oficial de reparación de RAID 1
ZimaOS 1.4.4 añadió la reparación de RAID1 para conjuntos degradados/dañados y solucionó el problema por el que los discos usados anteriormente no estaban disponibles durante la recuperación.
Usa la función oficial de reparación de RAID1 antes de aplicar comandos manuales antiguos de modificación de mdadm.
Los metadatos del RAID son más resistentes en las versiones más recientes de ZimaOS
ZimaOS 1.6.0 añadió un mecanismo de guardado de metadatos del RAID diseñado para volver a identificar y montar automáticamente el conjunto original después de reinstalar el sistema operativo o reemplazar el dispositivo. Esto mejora el proceso de recuperación en comparación con la época de la fuente, correspondiente a la versión 1.5.x.
Orden de recuperación actual más seguro
- No formatees ni deshagas el conjunto.
- Identifica los modelos y números de serie de los discos, así como el estado actual del RAID, mediante diagnósticos de solo lectura.
- Haz una copia de seguridad inmediata de los datos accesibles.
- Comprueba los cables, los puertos, la alimentación, SMART y los registros de E/S/reinicio del kernel.
- Usa la interfaz actual de reparación del RAID cuando el conjunto esté realmente degradado.
- Trata la recuperación de la ranura del sistema por separado de la recuperación de los datos del RAID.
El hilo de recuperación finalmente llegó a las opciones de restablecimiento/recuperación de ZimaOS
Un estado md [UU] significa que ambos miembros del RAID 1 estaban presentes en ese momento
Después de volver a conectar ambos discos, la fuente mostró el conjunto activo con dos miembros y [UU]. Eso era una prueba sólida de que el espejo se había vuelto a ensamblar correctamente en ese momento.
No explica por qué el conjunto había aparecido inaccesible anteriormente ni por qué la inestabilidad posterior de SATA/USB/monitor continuó.
Los diagnósticos de solo lectura son más seguros que los comandos manuales de reparación de mdadm
La comunidad solicitó información sobre la matriz y su estado antes de sugerir cambios. Ese es el orden correcto: identifica qué dispositivos pertenecen a la matriz, si está activa o degradada y qué informa el kernel antes de añadir o eliminar miembros o recrear los metadatos.
No copies un mdadm --create, un ensamblaje forzado o un comando para borrar el superbloque de otro caso de Linux en un RAID que contiene la única copia de tus datos.
Copia los datos importantes en cuanto la matriz vuelva a ser legible
El usuario de la fuente recuperó el acceso. En ese momento, la prioridad debería ser copiar los datos irremplazables a un almacenamiento independiente antes de seguir experimentando con cables, controladores, ranuras del sistema, NFS o reinstalaciones.
RAID 1 ofrece redundancia, pero un host o controlador inestable puede hacer que ambos miembros no estén disponibles al mismo tiempo.
Cuando aparecen problemas de SATA, USB y pantalla a la vez, amplía el diagnóstico
Los síntomas posteriores ya no describían claramente un fallo de un solo disco. La detección intermitente de SATA, el comportamiento de USB y los problemas de monitor o arranque pueden apuntar a problemas de cableado, alimentación, controlador, firmware de la placa base u otra inestabilidad de la plataforma.
Prueba con una fuente de alimentación y cables que sepas que funcionan, y simplifica la configuración del hardware antes de reconstruir repetidamente el RAID.
La recuperación de la ranura del sistema y la recuperación de RAID son procesos independientes
ZimaOS puede arrancar desde ranuras de sistema alternativas para recuperar el sistema operativo. Volver a la ranura B puede reparar o eludir un problema de la ranura del sistema operativo, pero no repara por sí solo una matriz degradada.
Usa el modelo actual de recuperación del sistema de ZimaOS cuando la ranura del sistema operativo también esté dañada.
Desconecta los discos de datos al reinstalar el sistema operativo si el plan de recuperación lo indica
La comunidad de la fuente recomendó aislar los discos RAID durante una reinstalación limpia del sistema operativo para reducir la posibilidad de seleccionar o modificar la unidad equivocada. Si el soporte actual de IceWhale proporciona un plan de reinstalación, etiqueta cada disco y conserva primero los metadatos del almacenamiento y las copias de seguridad.
Preguntas frecuentes sobre la recuperación de RAID 1
¿La fuente confirmó definitivamente que uno de los discos estaba averiado?
No. Posteriormente, ambos discos funcionaron de forma independiente y la matriz mostró [UU] al volver a conectarlo.
¿La fuente identificó una causa raíz definitiva?
No. Se solaparon problemas de RAID, inestabilidad de SATA/alimentación, inicio de NFS y las ranuras del sistema operativo.
¿La versión actual de ZimaOS permite reparar RAID1?
Sí. IceWhale añadió un flujo de reparación oficial para RAID1 en la versión 1.4.4.
