Cuando una matriz RAID pasa repentinamente a ser de solo lectura, forzarla de nuevo al modo de lectura y escritura no es la primera prioridad. La pregunta más importante es por qué la matriz dejó de confiar en uno o más discos.
En este hilo de mayo de 2026, una RAID 5 de cuatro discos entró en un estado protector de solo lectura después de que un disco miembro desapareciera temporalmente. Más tarde, la matriz volvió a un estado saludable [UUUU] y comenzó una larga fase de protección y resincronización, pero las desconexiones del disco volvieron a producirse. La conversación pasó entonces de «¿cómo vuelvo a activar el acceso de escritura?» a la ruta de comunicación del hardware.
La matriz entró en modo protector de solo lectura
El hilo no mostró que el usuario hubiera pulsado accidentalmente un interruptor de solo lectura. El análisis de la comunidad interpretó este estado como una respuesta a una condición de almacenamiento degradada o inestable.
La RAID podía recuperarse y aun así tener un problema subyacente
Tras reiniciar y recuperar el sistema, los cuatro miembros de la RAID volvieron a ser visibles y la matriz entró en «Protección en curso».
Reiniciar repetidamente durante una resincronización de paridad puede reiniciar o prolongar las tareas de recuperación. El consejo de la comunidad fue dejar que la matriz completara su proceso de protección mientras se investigaba por qué desaparecían los discos.
SMART aprobó los discos, pero el historial de errores de la interfaz era importante
Los dos discos Toshiba informaron de un estado general de SMART aprobado, sin sectores reasignados ni pendientes en los datos compartidos. Por eso, no estaba justificada una conclusión sencilla de que «los discos están definitivamente averiados».
Sin embargo, los registros SMART también mostraban recuentos de errores CRC de Ultra DMA y múltiples errores de comandos ICRC/ABRT. Estos campos suelen asociarse con fallos de comunicación entre una unidad y el host, más que únicamente con defectos del soporte. Por ello, la comunidad se centró en los cables de datos SATA, el suministro eléctrico, la estabilidad del controlador, el firmware y los reinicios repetidos del enlace.
No fuerces una matriz degradada de vuelta al modo de lectura y escritura
El hilo no contiene ningún comando de IceWhale que anule de forma segura el estado protector. Para ofrecer una orientación duradera, ese es el límite correcto: realiza una copia de seguridad de los datos accesibles, verifica el estado de la matriz, inspecciona las conexiones físicas y diagnostica la desconexión antes de intentar eludir la protección.
Usa el panel de almacenamiento actual para confirmar el estado de la matriz
El ZimaOS actual muestra el estado del almacenamiento y de las unidades miembro en Ajustes > Almacenamiento. Si estás solucionando problemas en una versión moderna, comprueba cómo la interfaz de almacenamiento actual informa sobre la matriz y sus unidades miembro antes de aplicar conclusiones de este incidente de 2026.
Preguntas frecuentes sobre RAID de solo lectura en ZimaOS
¿ZimaOS cambió aleatoriamente una RAID saludable a solo lectura?
Las pruebas disponibles apuntan a desconexiones de unidades miembro. El estado protector apareció junto con un disco ausente, no como un cambio aislado de una opción de la interfaz.
¿SMART demostró que los discos Toshiba habían fallado?
No. El estado general de SMART fue aprobado y los contadores habituales de fallos de sectores estaban en cero, aunque los registros contenían errores importantes de comunicación de la interfaz.
¿Qué debo investigar cuando aparecen errores CRC o ICRC?
La comunidad se centró en los cables SATA, las conexiones de alimentación, la estabilidad de la fuente de alimentación, el comportamiento del controlador, el firmware y si la misma unidad o el mismo puerto se desconectan repetidamente.
¿Hubo un diagnóstico oficial de la causa raíz por parte de IceWhale?
No. El hilo publicado terminó con un análisis del hardware por parte de la comunidad, no con una conclusión de ingeniería de IceWhale.
