Errores de corrupción en la caché de Unraid: diagnóstico y recuperación sin formatear

Pasos a seguir

1. Identifica el pool y reduce nuevas escrituras

   Anota el mensaje exacto, la hora y qué aplicaciones estaban activas. Comprueba si el problema corresponde a un pool, a una unidad del array o a otro dispositivo. Detén de forma controlada contenedores y máquinas virtuales que escriban en el almacenamiento afectado. Evita reinicios repetidos y conserva el estado necesario para investigar. Si hay ruidos mecánicos, desconexiones constantes o datos irremplazables sin copia, valora asistencia especializada antes de someter la unidad a lecturas intensivas. No conviertas una incidencia limitada en una pérdida mayor ejecutando varias reparaciones incompatibles una detrás de otra.

2. Guarda diagnósticos y reconoce el sistema de archivos

   Descarga los diagnósticos de Unraid y conserva registros fuera del servidor. Identifica el sistema de archivos real del pool y los números de serie de sus miembros. Btrfs, ZFS y XFS no utilizan los mismos controles ni los mismos procedimientos. Comprueba también perfiles o topología de redundancia: dos dispositivos instalados no demuestran que los datos tengan dos copias útiles. No selecciones una unidad por una letra de dispositivo que puede cambiar tras reiniciar. Relaciona ranura, serie y función antes de tocar conexiones o seguir instrucciones de mantenimiento.

3. Protege los archivos que todavía puedes leer

   Si el pool permite acceso estable, copia primero el contenido prioritario a otro almacenamiento y verifica una muestra. Incluye datos persistentes de aplicaciones y sus exportaciones coherentes cuando puedas obtenerlas sin agravar el problema. No muevas la única copia; conserva el origen hasta validar el destino. Si una lectura falla, registra qué archivo o ruta queda afectado en vez de repetir transferencias indiscriminadamente. Una copia parcial identificada puede ser valiosa para recuperar el servicio. No utilices como destino otra carpeta que reside en el mismo pool dañado.

4. Revisa hardware antes de atribuir todo al formato

   Comprueba alertas de las unidades, errores de enlace, temperaturas y estabilidad de alimentación. Un cable o controlador defectuoso puede producir síntomas que reaparecerán después de reparar metadatos. Guarda los valores y distingue errores históricos de los que siguen aumentando. Cuando debas revisar conexiones físicas, apaga de forma segura y etiqueta antes de desconectar. Considera también memoria si aparecen errores inexplicables en distintos archivos o dispositivos, utilizando el procedimiento de prueba apropiado. No interpretes un único indicador saludable como garantía de que toda la cadena de almacenamiento funciona correctamente.

5. Sigue el procedimiento del sistema de archivos concreto

   En Btrfs, un scrub comprueba datos y solo puede reparar ciertos daños cuando dispone de una copia válida redundante. No ejecutes btrfs check --repair como respuesta genérica a cualquier aviso. En ZFS utiliza sus herramientas de estado y scrub, no una utilidad tradicional de reparación de otro formato. En XFS sigue el modo y recorrido que documenta la versión de Unraid para ese dispositivo. Antes de una operación que escriba cambios, conserva la copia posible y revisa el informe de diagnóstico. Los comandos sobre paridad, discos emulados y miembros físicos no son intercambiables.

6. Valida datos y aplicaciones antes de volver al uso normal

   Después de resolver la causa y completar el procedimiento adecuado, revisa estado del pool y registros. Abre archivos recuperados y comprueba aplicaciones en un entorno controlado. Una base de datos puede necesitar restauración propia aunque el sistema de archivos vuelva a montar. Reanuda servicios por grupos y observa si aparecen nuevos errores. Conserva los diagnósticos iniciales y el registro de cambios. Si reconstruyes el pool desde backup, valida restauración antes de retirar la copia anterior. El objetivo final es contenido utilizable y estabilidad, no únicamente que desaparezca una notificación.

Guía detallada

Por qué formatear no es reparar

Formatear crea un sistema de archivos nuevo y vacío. No reconstruye automáticamente la estructura que no podía montarse. En el array, además, la operación puede actualizar la paridad con ese estado vacío; no debes esperar que una reconstrucción posterior recupere el contenido anterior. En un pool, la paridad del array tampoco proporciona esa salida. Lee cualquier diálogo de formato como una operación destructiva sobre el dispositivo seleccionado. Si la interfaz lo ofrece tras un fallo, detente y determina primero qué datos deben recuperarse y desde qué copia.

Un espejo no garantiza que el contenido sea correcto

La redundancia ayuda frente a ciertos fallos, pero no sustituye comprobaciones ni versiones independientes. Una corrupción de aplicación o un borrado autorizado puede afectar a estados replicados correctamente. El scrub necesita información válida con la que contrastar o reparar; no puede inventar un archivo completo si todas sus copias están dañadas. Verifica qué errores se corrigieron y cuáles permanecen. Conserva una estrategia de backup del pool, especialmente para appdata, máquinas virtuales y documentos que todavía no han pasado al array mediante Mover.

Preparar el siguiente incidente

Después de estabilizar el sistema, documenta pool, miembros, sistema de archivos y tareas que dependen de él. Configura avisos y revisiones acordes con la plataforma. Mantén copias de datos persistentes de aplicaciones y prueba su restauración, no solo la del contenedor. Revisa que las rutas de las shares apuntan al almacenamiento esperado y que no quedan duplicados confusos tras la recuperación. Si la causa fue capacidad agotada, dimensiona margen y políticas de movimiento. Si fue hardware, confirma que la corrección eliminó los errores nuevos antes de dar el caso por cerrado.

Comparar situaciones

Preguntas frecuentes

Guías relacionadas

• Regla de copia de seguridad 3-2-1: cómo organizarla y probarla