Volumen NAS de solo lectura tras un apagado inseguro: primeras comprobaciones

Un volumen NAS que se vuelve de solo lectura tras un apagado inseguro generalmente está protegiendo metadatos dañados o reaccionando a errores de E/S de almacenamiento, no simplemente cambiando permisos.

Si sus recursos compartidos aún se abren pero fallan las cargas, bases de datos de aplicaciones o escaneos de medios, resista la tentación de forzar un remonte de lectura-escritura. El camino más seguro es preservar los datos legibles, identificar si el bloqueo ocurre en la capa de recurso compartido, sistema de archivos, grupo o unidad, y luego usar el método de reparación diseñado para esa pila de almacenamiento.

Primero, congele los cambios y proteja los datos legibles

Trate el modo de solo lectura como una advertencia, no como la falla en sí. Pausa trabajos de sincronización, contenedores, indexación de medios, descargas y rotación de copias de seguridad para que los reintentos repetidos no oculten los errores originales ni estresen una unidad débil.

Si los archivos importantes siguen siendo legibles, copie los datos más irremplazables a un almacenamiento sano separado antes de intentar la reparación. En un caso reportado, un sistema de archivos de solo lectura tras un corte de energía volvió después de intentos temporales de reparación, mostrando por qué la recurrencia debe tratarse como no resuelta.

1. Pausa los servicios y las escrituras de los clientes.
2. Copie archivos críticos legibles a otro lugar.
3. Guarde las pantallas de estado del almacenamiento y los registros de eventos.
4. Registre la disposición del grupo y el tipo de sistema de archivos.
5. Comience las verificaciones sin cambiar el arreglo.

Este orden preserva tanto los datos como la evidencia. Un reinicio, montaje forzado, reparación o remonte puede cambiar el estado que necesita diagnosticar, así que no haga uno de estos como primer experimento.

¿Qué se volvió realmente de solo lectura?

Una carga fallida no prueba que todo el volumen sea de solo lectura. Un recurso compartido, conjunto de datos, directorio de aplicación, sistema de archivos, grupo de almacenamiento o dispositivo físico puede bloquear escrituras, y cada capa necesita una solución diferente.

Compare la falla desde el panel NAS y desde más de un cliente. El patrón a continuación separa un problema de acceso de un evento de protección de almacenamiento antes de tocar los discos o ejecutar una herramienta de reparación del sistema de archivos.

Si el NAS puede crear un archivo de prueba pero los clientes no, mantente por encima de la capa del sistema de archivos. Si las escrituras locales también fallan y el panel informa un volumen de solo lectura, continúa con los registros y la salud del pool.

Lee los registros antes de que desaparezcan.

La primera evidencia útil es el evento inmediatamente antes de que el volumen se volviera de solo lectura. Revisa el registro de eventos del sistema, el historial del administrador de almacenamiento y los mensajes del kernel para el arranque afectado y el anterior.

Algunos sistemas de archivos detienen las escrituras tras detectar un error. En un caso donde un sistema se volvió de solo lectura de repente, los respondedores advirtieron que las nuevas entradas del diario podrían no llegar al disco. Captura los mensajes actuales del kernel antes de reiniciar siempre que sea posible.

Guarda las entradas que contengan errores del sistema de archivos, abortos de diario, fallos de suma de verificación, reinicios de dispositivos, tiempos de espera o errores de E/S de lectura/escritura. Registra el identificador del dispositivo y la marca de tiempo; las fallas repetidas en el mismo miembro importan más que un aviso genérico de "apagado no limpio".

Verifica el Pool o RAID antes del sistema de archivos.

Un sistema de archivos se encuentra sobre un pool, conjunto RAID, volumen lógico, controlador y discos. Si esa capa inferior está incompleta o inestable, la reparación del sistema de archivos puede leer datos inconsistentes o añadir carga en el peor momento.

Para RAID por software en Linux, un arreglo RAID 5 o RAID 6 sucio y degradado puede conllevar un riesgo de corrupción indetectable; la regla del arreglo sucio y degradado explica por qué puede rechazarse el inicio automático. No fuerces el ensamblaje solo para eliminar una advertencia del panel.

Comprueba si cada miembro está presente, si hay una reconstrucción o resilver activa, y si los contadores de lectura, escritura o suma de verificación están aumentando. Registra el orden de los miembros y el estado exacto sin forzar el ensamblaje, reemplazar un disco o iniciar un scrub. Estabiliza el pool antes de revisar el sistema de archivos encima.

Verifica la salud del disco, el cableado y la alimentación.

Revisa cada dispositivo HDD, SSD y NVMe, incluidos los dispositivos de caché y metadatos. Usa la página de salud del NAS para inspeccionar la salud SMART o NVMe, auto-pruebas recientes, temperaturas, errores de medios y si algún dispositivo desapareció después del apagado.

No confíes en una sola insignia verde de "saludable". Correlaciona los resultados de salud con errores de E/S del kernel, reinicios de dispositivos y el momento en que el volumen cambió de estado. Un resumen aprobado no explica una falla registrada en otra parte de la ruta de almacenamiento.

Apague el NAS limpiamente antes de volver a conectar una conexión de datos o energía accesible, y cambie solo una variable a la vez. Si varios discos desaparecen juntos o los errores siguen a un puerto en lugar de a un disco, deje de culpar a discos individuales e investigue la ruta compartida.

Empareje la Herramienta de Reparación con el Sistema de Archivos

Ext4 y XFS: Reparación Offline con Herramientas Nativas

Ext4 usa e2fsck, mientras que XFS usa xfs_repair; ninguno debe dirigirse a un volumen montado o a una ruta de dispositivo incierta. Si el NAS no puede desmontar el volumen de forma segura, use su flujo de trabajo de mantenimiento o un entorno de recuperación soportado.

Una guía práctica de solución de problemas de sistemas de archivos separa las verificaciones de la familia ext de la reparación de XFS y coloca las verificaciones en un sistema de archivos desmontado. Preserva una copia de seguridad, identifique el dispositivo exacto y comience con el modo nativo no modificante del sistema de archivos cuando esté disponible.

Btrfs: Prefiera Verificaciones Solo de Lectura y Guía Experta

Btrfs separa el scrub, la verificación estructural y la reparación. Un scrub valida sumas de comprobación y puede usar una réplica buena, mientras que una verificación estructural examina objetos del sistema de archivos; ninguno debe considerarse un interruptor genérico que haga que un volumen dañado sea escribible.

La advertencia oficial de btrfs check recomienda desmontar primero y advierte explícitamente contra el uso de --repair sin guía experta. Comience con la recuperación de datos legibles y una verificación no modificante, luego siga la ruta de recuperación documentada por el proveedor del NAS.

ZFS: Estabilice el Pool Antes de Realizar un Scrub

ZFS no utiliza un flujo de trabajo tradicional de fsck. Primero lea el estado del pool, preserve archivos críticos y resuelva dispositivos faltantes o con fallas antes de añadir la carga sostenida de E/S de un scrub.

Un scrub de pool en OpenZFS verifica sumas de comprobación de bloques y puede reparar a partir de réplicas buenas, pero es intensivo en E/S y no puede inventar una copia válida cuando la redundancia se agota. Inícielo solo después de que el pool esté estable y los datos críticos estén protegidos.

Cuándo Restaurar Escrituras—y Cuándo Detenerse

Restaurar el servicio de lectura-escritura solo después de que el pool esté estable, se complete la verificación offline relevante o la recuperación nativa, y los registros recientes no muestren errores recurrentes de E/S o metadatos. Luego, inicie un servicio de bajo riesgo y pruebe un archivo desechable antes de reanudar las cargas de trabajo normales.

Si un remonte forzado falla o el volumen vuelve inmediatamente a solo lectura, acepte ese resultado como nueva evidencia. Repetir el mismo comando no elimina la causa; solo aumenta las escrituras, el calor y la presión de recuperación.

Detenga la reparación DIY cuando falten múltiples miembros del pool, los contadores de errores sigan aumentando, una unidad haga clics o se desconecte repetidamente, las sumas de verificación sean irrecuperables o la única copia legible sea crítica. Preserve los registros y el orden de los dispositivos, mantenga el sistema apagado si el hardware es inestable y contacte soporte calificado de recuperación de almacenamiento o plataforma.

Prevenga el próximo apagado inseguro

Use un UPS que pueda señalar al NAS para apagarse automáticamente, no solo una batería con puertos de comunicación sin usar. Esta lista de verificación para cortes de energía en NAS cubre la comunicación de apagado, verificaciones posteriores al corte y por qué la energía estable es importante durante la recuperación.

Mantenga copias de recuperación fuera del pool activo. RAID puede preservar la disponibilidad después de algunas fallas de unidades, pero sigue la corrupción en vivo y no proporciona una versión limpia anterior; la distinción entre RAID y recuperación de respaldo es lo que más importa cuando una reparación no tiene éxito.

Finalmente, active las alertas de disco, pool y UPS; programe verificaciones o escaneos apropiados para el sistema de archivos; y pruebe una pequeña restauración periódicamente. Un arranque exitoso es útil, pero un camino de recuperación verificado es lo que convierte el próximo apagado de una crisis en un evento controlado.

Preguntas frecuentes

¿Puede un reinicio arreglar un volumen NAS de solo lectura?

Un reinicio puede completar la reproducción del diario o limpiar un estado temporal del servicio, pero no es prueba de que el almacenamiento esté saludable. Verifique primero los registros guardados y el estado del pool, especialmente si el volumen ya ha cambiado a solo lectura más de una vez.

¿Puedo forzar un remonte en modo lectura-escritura el tiempo suficiente para copiar archivos?

Prefiera copiar desde el estado existente de solo lectura. Un montaje forzado en modo escritura puede desencadenar nuevas actualizaciones de metadatos y puede fallar inmediatamente si el kernel aún detecta errores. Úselo solo dentro de un plan de recuperación específico del sistema de archivos después de proteger la mejor copia disponible.

¿Qué pasa si SMART pasa pero los registros aún muestran errores de E/S?

Trate los registros como evidencia no resuelta. La falla puede involucrar una interfaz, cable, backplane, controlador, ruta de alimentación o un problema con la unidad que no se resume en el resultado general de SMART. Aísle un componente a la vez y deténgase si los errores continúan.

La primera comprobación más segura es la que preserva las opciones: proteger los datos legibles, identificar la capa bloqueada y dejar que la evidencia verificada—no un remonte forzado—decida la siguiente acción.