El disco está físicamente presente, SMART no detecta errores y el arreglo de Unraid arrancó sin problemas — pero un recurso compartido ha desaparecido y la interfaz WebGUI muestra el disco como No montable. Se trata de un evento de corrupción del sistema de archivos, y es una clase de problema distinta a una falla de hardware.
La paridad no puede ayudar en este caso. El disco de paridad mantiene un espejo bit a bit de los sectores de datos, no un registro de la integridad de los metadatos del sistema de archivos. Si el journal (registro) o el superbloque de un disco de datos está dañado, la paridad preservará fielmente esa corrupción. Recuperar este estado requiere trabajar directamente con las herramientas de reparación del sistema de archivos — xfs_repair para volúmenes XFS y btrfs check para BTRFS — desde el terminal de Unraid. Para la recuperación de datos a nivel de archivos puede ser necesario usar utilidades externas especializadas.
| Situación | Sistema de archivos | Acción | Resultado esperado |
|---|---|---|---|
| Disco no montable, SMART limpio | XFS | Modo mantenimiento → xfs_repair /dev/sdXp1 → reiniciar |
✅ Disco se monta, datos intactos |
xfs_repair falla: error de journal sucio |
XFS | xfs_repair -L /dev/sdXp1 (pone a cero el journal) |
⚠️ Disco se monta; los archivos que estaban abiertos durante el fallo pueden quedar parciales o vacíos |
| Disco no montable, SMART limpio | BTRFS | btrfs scrub (montado) → btrfs check /dev/sdXp1 (solo lectura) → evaluar errores |
✅ Errores menores: el disco se monta tras la comprobación |
btrfs check informa errores en extent o en el árbol de chunks |
BTRFS | Evitar --repair → usar RS RAID Retrieve para recuperación a nivel de archivos primero |
⚠️ Recuperación parcial; la reparación estructural puede provocar pérdida adicional |
| Disco no montable, SMART muestra sectores defectuosos | XFS / BTRFS | RS RAID Retrieve → Análisis completo → recuperar a disco separado → planificar el reemplazo del disco | ⚠️ Archivos recuperables; el hardware está fallando — la reparación no será duradera |
| Las herramientas de terminal no pueden montar el disco; archivos faltan tras la reparación | XFS / BTRFS | Conectar los discos a un PC con Windows → RS RAID Retrieve → Fast Scan o Full Analysis | ✅ Recuperación a nivel de archivos sin montar el sistema de archivos |
| Se pulsó «Formatear» en el disco no montable | Cualquiera | No existe ruta de recuperación — la paridad ahora refleja un disco vacío | ❌ Datos perdidos de forma permanente |
Cómo Unraid utiliza sistemas de archivos independientes por disco
En un escenario de fallo lógico, la arquitectura de Unraid es el factor determinante para comprender qué está dañado y qué no, y para planificar la recuperación de datos.
A diferencia de RAID 5 o RAID 6, donde la distribución en franjas (striping) abarca varios discos físicos, Unraid escribe los archivos completos en discos individuales. Cada disco de datos funciona como un volumen autónomo — formateado en XFS o BTRFS — y es montado de forma independiente por el sistema operativo. La capa de array de Unraid, situada por encima, gestiona la agregación de recursos compartidos y las actualizaciones de paridad; la capa de sistema de archivos, por debajo, corresponde al Linux estándar.
XFS
Predeterminado en UnraidCaracterísticas relevantes para la reparación:
- Recuperación de metadatos basada en registro (journal)
- La reparación requiere que el disco esté desmontado
- En Unraid: requiere modo de mantenimiento
- Herramienta principal:
xfs_repair - La corrupción del registro requiere la opción
-L(destructiva)
BTRFS
Opcional en UnraidCaracterísticas relevantes para la reparación y la integridad de datos:
- Copy-on-write (COW); sumas de verificación integradas para datos y metadatos
- La comprobación puede ejecutarse sobre un volumen montado
- El modo de reparación (
--repair) es agresivo — úselo con precaución - Herramientas principales:
btrfs check,btrfs scrub - Es posible la recuperación de subvolúmenes incluso con corrupción parcial
Consecuencia práctica de esta arquitectura: la corrupción del sistema de archivos en Disco 3 no afecta a los sistemas de archivos de Disco 1, Disco 2 ni a ningún otro disco. Los datos de cada disco están aislados. Está reparando un volumen, no el conjunto (array) completo. La excepción es el disco de paridad: no tiene sistema de archivos y nunca debe someterse a herramientas de reparación de sistemas de archivos.
El disco de paridad no tiene sistema de archivos — nunca ejecute xfs_repair ni btrfs check sobre él.
El disco de paridad almacena datos XOR en desplazamientos de sectores fijos. No dispone de una tabla de particiones visible para las herramientas de sistema de archivos, y el intento de repararlo como si fuera un sistema de archivos corromperá los datos de paridad, dejando todo el array sin protección. Identifique el disco de paridad en la interfaz web (WebGUI) antes de abrir cualquier terminal.
Causas de la corrupción del sistema de archivos en Unraid
La corrupción del sistema de archivos en Unraid suele deberse a una de tres causas raíz. Identificar cuál se aplica afecta al enfoque de reparación y a la estrategia de recuperación de datos.
Apagado abrupto
Un corte de energía o un reinicio forzado mientras la matriz está activa deja las operaciones de escritura en curso sin confirmar. El journal (registro) contiene transacciones incompletas. En el siguiente montaje, el sistema de archivos detecta la inconsistencia y se niega a montarse. Esta es la causa más frecuente.
Memoria RAM defectuosa
La memoria ECC no es estándar en la mayoría de las implementaciones de Unraid. Un único error de bit (inversión de bit) en un búfer de escritura puede corromper los metadatos del sistema de archivos — entradas de directorio, tablas de inodos o el superbloque — comprometiendo la integridad de los datos de formas que se asemejan a un corte de energía, pero que son más difíciles de prevenir.
Errores en sectores del disco
Los sectores reasignados o pendientes en los datos SMART de una unidad indican zonas que el disco no puede leer o escribir con fiabilidad. Si estructuras de metadatos se ubican en esos sectores, el sistema de archivos queda corrupto incluso sin un evento de corte de energía. Un disco que muestra corrupción del sistema de archivos junto con recuentos SMART distintos de cero probablemente presenta un fallo de hardware subyacente.
Antes de ejecutar cualquier herramienta de reparación — compruebe SMART primero:
- Abra la interfaz web de Unraid (WebGUI) → pestaña Main → haga clic en el disco afectado → Informe SMART.
- Si
Reallocated_Sector_Ct(sectores reasignados),Current_Pending_Sector(sectores pendientes) oOffline_Uncorrectable(errores no corregibles fuera de línea) son distintos de cero, la reparación del sistema de archivos puede tener éxito de forma temporal, pero el hardware subyacente está fallando. Planifique la sustitución del disco independientemente del resultado de la reparación. - Si el informe SMART está limpio, la corrupción probablemente se debió a un evento puntual —por un corte de energía o un fallo de software— y la reparación tiene más probabilidades de mantenerse a largo plazo.
El botón Formatear: qué hace realmente y por qué no debe pulsarse
Cuando un disco deja de poder montarse, la interfaz web de Unraid (WebGUI) muestra una opción «Formatear» junto a los botones de diagnóstico. Para usuarios que desconocen cómo Unraid gestiona la paridad, esto induce a una suposición peligrosa: creer que al pulsar «Formatear» se restaurará el disco a un estado operativo y que la paridad llevará a cabo la reconstrucción de los datos perdidos.
Formatear no recupera datos. Los destruye de forma permanente.
Al pulsar Formatear en un disco que no se puede montar se borra por completo el sistema de archivos y se crea un nuevo volumen vacío. A continuación, la paridad se recalcula respecto a ese disco ahora vacío. Los datos originales desaparecen —no quedan corruptos ni recuperables, desaparecen definitivamente. La paridad reflejará correctamente un disco vacío, lo que hace inútil cualquier intento de recuperación posterior.
Este es el escenario más habitual de pérdida de datos en Unraid, aparte de las fallas de hardware, y es totalmente iniciado por el usuario. Los datos que había en el disco antes de formatear, en la mayoría de los casos, pueden recuperarse con las herramientas descritas en este artículo.
La secuencia correcta cuando un disco no se puede montar: diagnosticar primero, reparar después, y formatear solo como último recurso absoluto —y únicamente después de haber recuperado todos los datos a otra ubicación.
Reparación de un disco XFS no montable en Unraid: xfs_repair paso a paso
xfs_repair requiere que el sistema de archivos objetivo esté completamente desmontado antes de ejecutarse. En un array de Unraid en funcionamiento, todos los discos de datos están montados. Para desmontar un disco XFS concreto para su reparación sin detener por completo las comparticiones (shares), es necesario iniciar Unraid en Modo de mantenimiento — un modo de arranque que inicia el array sin montar ninguna compartición y sin que haya discos en uso.
Paso 1: Iniciar el array en Modo de mantenimiento
Desde la WebGUI de Unraid, vaya a Main. Antes de hacer clic en Start, marque la casilla Maintenance Mode que aparece debajo de los controles de arranque del array. Haga clic en Start. El array se inicia, pero ningún disco queda montado en los recursos compartidos. Este es el estado requerido para xfs_repair (reparación del sistema de archivos XFS).
Unraid 7.0 y posteriores: utilice primero los botones de reparación de la WebGUI.
A partir de Unraid 7.0, la WebGUI muestra los botones CHECK y FIX directamente en la vista de discos. Estos ejecutan xfs_repair con las opciones adecuadas de forma automática. Si su versión es compatible, pruebe primero la vía de la interfaz web antes de abrir una terminal — el resultado es idéntico, pero la interfaz gestiona el Modo de mantenimiento y la selección de la ruta del dispositivo por usted.
Paso 2: Identificar la ruta de dispositivo correcta
Este paso evita un error frecuente y crítico. En Unraid, cada disco de datos tiene dos rutas de dispositivo:
/dev/mdXp1— el dispositivo MD (array), gestionado por la capa de array de Unraid. No use esta ruta para xfs_repair./dev/sdXp1— la partición del disco en crudo, ruta directa al hardware. Use esta ruta.
Para identificar qué /dev/sdX corresponde al disco que desea reparar, abra una terminal (desde la WebGUI: Tools → Terminal, o por SSH) y ejecute:
# List disks with their Unraid slot assignments ls -la /dev/disk/by-id/
Compare el número de serie que aparece en el informe SMART de la WebGUI con el enlace simbólico en /dev/disk/by-id/ para confirmar la ruta de dispositivo antes de continuar.
Paso 3: Ejecutar xfs_repair — pasada estándar
# Replace sdX with your actual device identifier (e.g. sdb, sdc) xfs_repair /dev/sdXp1
xfs_repair realizará varias fases de comprobación del sistema de archivos XFS, verificando inodos, directorios y el mapa de espacio libre. En un journal sano, reproduce las transacciones no confirmadas y finaliza mostrando un resumen. Si se completa sin errores fatales, se puede intentar montar el disco reiniciando el sistema sin modo de mantenimiento.
Paso 4: Si xfs_repair falla debido a un journal sucio en XFS — la opción -L
Si la reparación finaliza con un mensaje como «ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed» y se niega a continuar, el registro del journal no es legible. En ese caso, la única opción es poner a cero el journal usando la opción -L.
La opción -L descarta el journal: comprenda sus implicaciones
Poner a cero el registro (log/journal) obliga a xfs_repair a abandonar cualquier transacción de metadatos pendiente que no se haya escrito en disco. En la práctica, esto significa que los archivos que se estaban escribiendo en el momento del fallo pueden perderse de forma parcial o aparecer con tamaño cero. Los archivos que se escribieron por completo antes del evento de corrupción no se ven afectados.
Utilice -L únicamente después de que haya fallado un intento de reparación estándar con xfs_repair. No lo emplee como primer recurso.
# Force repair by zeroing the dirty log # Use only after standard xfs_repair has failed xfs_repair -L /dev/sdXp1
Paso 5: Verificar la reparación
Tras una reparación exitosa, ejecute xfs_repair una vez más en modo de solo comprobación (-n) para confirmar que no quedan inconsistencias:
# Comprobación en seco — no realiza cambios, informa de problemas pendientes xfs_repair -n /dev/sdXp1
Si la comprobación en seco resulta limpia, reinicie el sistema de forma normal (sin activar el Modo de mantenimiento). El disco debería montarse y su recurso compartido volver a estar disponible. A continuación, ejecute una comprobación de paridad no correctiva para confirmar la validez de la paridad.
✓ Salida esperada tras una reparación exitosa
xfs_repair mostrará líneas de finalización de fases (Fase 1 a Fase 7) y finalizará con: «done». No deben aparecer errores en las fases 3–7. Los archivos que se hayan trasladado a /lost+found durante la reparación estarán accesibles allí una vez que el disco se monte; pueden devolverse a su ubicación original si se conoce dónde corresponden.
Reparación de un volumen BTRFS corrupto en Unraid
La corrupción del sistema de archivos BTRFS en Unraid es menos frecuente que la de XFS, en parte porque BTRFS emplea la semántica copy-on-write (COW): nunca sobrescribe los datos existentes, sino que escribe nuevas versiones de los bloques en espacio libre. Esto lo hace más resistente frente a escrituras incompletas. No obstante, puede producirse corrupción de metadatos, y el procedimiento de reparación difiere del de XFS en varios aspectos importantes.
Paso 1: Empiece con btrfs scrub — no con btrfs check
Antes de ejecutar cualquier reparación, ejecute un scrub en el volumen montado. A diferencia de xfs_repair, el comando btrfs scrub puede ejecutarse con el sistema de archivos montado. Verifica las sumas de comprobación (checksums) de todos los bloques de datos y metadatos y reporta cualquier discrepancia. En un volumen Unraid de un solo disco sin RAID de BTRFS, el scrub no puede corregir errores automáticamente —no existen copias redundantes— pero identifica exactamente qué bloques están dañados, información útil antes de decidir la estrategia de reparación. Inicie el array con normalidad (no en Modo de Mantenimiento) y abra un terminal:
# Reemplace /mnt/diskX por la ruta de montaje real del disco en Unraid btrfs scrub start /mnt/diskX # Supervisar el progreso btrfs scrub status /mnt/diskX
Si el scrub finaliza sin errores, el disco está sano y el estado «no montable» pudo haber sido un evento transitorio. Reinicie el servidor y compruebe si el disco se monta con normalidad.
Paso 2: Ejecutar btrfs check en modo de solo lectura
Si btrfs scrub informa errores o el disco sigue sin montarse tras un intento de scrub, proceda a btrfs check. Detenga primero el array para desmontar el disco y, a continuación, ejecute btrfs check en modo de solo lectura para evaluar el alcance del daño antes de intentar cualquier reparación:
# Stop array first, then check without making changes btrfs check /dev/sdXp1
Revise la salida con atención. btrfs check listará errores concretos en los árboles y elementos huérfanos. Las inconsistencias menores — inodos huérfanos, referencias de raíz incorrectas — pueden repararse de forma segura. Los errores en el árbol de extents o en el árbol de chunks indican daños estructurales más profundos y la recuperación mediante el modo de reparación puede ser incompleta.
Paso 3: Modo de reparación — utilícese con precaución
btrfs check –repair puede provocar pérdida de datos adicional
A diferencia de xfs_repair, diseñado para ejecutarse de forma rutinaria, los desarrolladores de Btrfs advierten explícitamente contra el uso del modo --repair sin la orientación de un desarrollador o sin haber creado previamente una imagen del disco. En casos de corrupción grave del árbol de extents, el modo de reparación puede eliminar archivos que considera huérfanos en lugar de recuperarlos, lo que aumenta el riesgo de pérdida de datos en Btrfs.
Si la comprobación en modo solo lectura detecta errores en el árbol de extents y dispone de datos irremplazables en el disco, omita el modo de reparación y proceda directamente a RS RAID Retrieve para una recuperación a nivel de archivos antes de intentar cualquier reparación estructural.
Para corrupciones menores y bien acotadas — errores en la caché de espacio libre, inodos huérfanos, referencias de raíz incorrectas — el modo de reparación suele ser seguro:
# Only for minor, well-scoped corruption # Image the disk first if data is critical btrfs check --repair /dev/sdXp1
Paso 4: Recuperar subvolúmenes individuales
Si el árbol Btrfs de nivel superior está dañado pero los subvolúmenes de datos permanecen íntegros, a veces es posible montar directamente un subvolumen concreto y extraer sus datos sin reparar el árbol completo:
# List subvolumes on a partially readable volume btrfs subvolume list /mnt/diskX # Mount a specific subvolume by ID if the default mount fails mount -o subvolid=256 /dev/sdXp1 /mnt/recovery_point
Si algún subvolumen se monta correctamente, se debe copiar inmediatamente su contenido a un disco sano antes de intentar cualquier reparación adicional del volumen dañado. Este procedimiento es habitual en la recuperación de datos Btrfs y al montar subvolúmenes por ID.
Cuando las herramientas de terminal fallan: recuperar archivos de un disco Unraid corrupto con RS RAID Retrieve
Tanto xfs_repair como btrfs check actúan a nivel de la estructura del sistema de archivos: intentan que el volumen vuelva a montarse. Cuando esto no es posible por una corrupción grave de metadatos, o cuando la reparación finaliza pero siguen faltando archivos o aparecen vacíos, el siguiente paso es la recuperación a nivel de archivo a partir de los datos en bruto del disco.
Aquí es donde entra en juego RS RAID Retrieve. El programa lee directamente los sectores del disco, omite las estructuras de sistema de archivos dañadas y reconstruye árboles de directorios y el contenido de los archivos a partir de las tablas de asignación subyacentes. Es compatible con XFS y BTRFS —sistemas que Windows no puede montar de forma nativa—, por lo que el flujo de trabajo habitual es trabajar desde un PC con Windows con el disco conectado externamente para la recuperación de datos.
Qué hace RS RAID Retrieve con un disco Unraid corrupto
El programa identifica la estructura del array de Unraid a partir de los metadatos del disco, reconstruye el volumen lógico y, a continuación, escanea el sistema de archivos (por ejemplo, XFS) a nivel de sectores para la recuperación de datos. Incluso cuando xfs_repair ha desplazado archivos a /lost+found o los metadatos están demasiado dañados para montar el volumen, el programa suele poder recuperar el contenido de los archivos y las rutas de directorio originales leyendo directamente los datos de asignación.
Recuperación de datos de matrices RAID dañadas
Detener el servidor Unraid y extraer el disco afectado
Apague el servidor de forma limpia si el sistema aún es accesible. Conecte el disco dañado a un PC con Windows; utilice una conexión SATA directa siempre que sea posible. Conecte también los discos restantes del array RAID y el disco de paridad: RS RAID Retrieve los emplea para reconstruir la configuración completa del array RAID e identificar correctamente el rol de cada unidad dentro de la estructura de Unraid durante la recuperación de datos.
Launch RS RAID Retrieve — detección automática de la matriz
Al iniciarse, el programa escanea todos los discos conectados, lee los metadatos de Unraid de cada uno y reconstruye automáticamente la configuración de la matriz para la recuperación RAID. El disco dañado aparece en la lista de unidades junto a los miembros en buen estado. Windows no asigna letras de unidad a volúmenes XFS o BTRFS; esto es normal y no indica un problema de conexión.
Seleccione el tipo de escaneo según la extensión de la corrupción
Haga clic con el botón derecho sobre el conjunto reconstruido o el disco individual en el Administrador de discos y seleccione Abrir. Para corrupciones del sistema de archivos en las que la tabla de particiones y el superbloque están intactos, un Escaneo rápido es suficiente para la recuperación de datos y mostrará el árbol de directorios con los archivos recuperables resaltados. Si el propio superbloque está dañado o el Escaneo rápido devuelve un árbol de archivos vacío, ejecute un Análisis completo; este realiza un escaneo sector a sector basado en firmas y puede recuperar archivos incluso cuando los metadatos del directorio han desaparecido, aunque los nombres de archivo y las rutas pueden no conservarse.
Previsualice archivos antes de confirmar la recuperación
RS RAID Retrieve permite previsualizar el contenido de los archivos antes de escribir nada en el disco. Esto facilita verificar que los archivos recuperados estén intactos y sean aptos para la recuperación de datos. Por ejemplo, abra una muestra de documentos, imágenes y archivos comprimidos directamente en el panel de vista previa. Los archivos que se muestran correctamente en la vista previa se recuperarán correctamente. En cambio, los archivos que aparecen vacíos o dañados en la vista previa probablemente no permitan recuperar contenido útil, independientemente de la herramienta utilizada.
Copiar archivos recuperados a un disco sano
Seleccione los archivos y directorios a recuperar, haga clic en Recuperar y especifique una ruta de salida en un disco sano y separado. No recupere archivos en el disco de origen ni en ningún disco que forme parte del array de Unraid. Verifique una selección representativa de los archivos recuperados tras la copia antes de dar por concluida la recuperación de datos.
Resultados de recuperación según tipo de corrupción
Corrupción del journal / apagado incorrecto
El escenario con mayor probabilidad de recuperación de datos. Las estructuras de asignación de archivos suelen permanecer intactas. RS RAID Retrieve puede reconstruir el árbol de directorios completo y recuperar archivos con sus nombres y rutas originales. Normalmente, Fast Scan es suficiente.
Corrupción parcial de metadatos
Durante la recuperación de datos, los árboles de directorios pueden quedar incompletos. En la vista de recuperación, algunos archivos pueden aparecer sin nombre. El contenido de los archivos suele permanecer intacto incluso cuando los metadatos están dañados. El Análisis completo recupera más archivos, pero puede sacrificar la estructura de directorios original en las zonas afectadas.
Superbloque y árbol de extents destruidos
Si el disco fue formateado después de pasar al estado Unmountable, o si el daño en sectores físicos ha destruido los superbloques primario y de respaldo, la recuperación a nivel de archivos no es posible. Este resultado es poco frecuente en escenarios de fallo puramente lógico, pero habitual cuando se pulsó el botón Format o cuando el disco presentaba una degradación de hardware avanzada.
La corrupción del sistema de archivos en Unraid es recuperable en la mayoría de los casos — siempre que se siga la secuencia correcta y no se pulse el botón Format antes de asegurar los datos. La ruta de decisión es sencilla:
Una falla lógica no implica que la paridad sea inválida — pero no confíe en ella ciegamente.
Tras reparar el sistema de archivos, el disco de paridad sigue conteniendo la operación XOR de los sectores — incluidos aquellos que estaban corruptos antes de la reparación. Una vez que el disco se haya reparado y monte correctamente, ejecute una comprobación de paridad sin corrección para identificar inconsistencias. Si se encuentran errores, ejecute una comprobación de paridad correctiva para sincronizar la paridad con el estado actual del disco. Hágalo antes de reanudar el uso normal de la matriz.
Preguntas frecuentes
ddrescue -d -r3 /dev/sdXp1 /path/to/image.img /path/to/map.log. Una vez que tengas la imagen, ejecuta xfs_repair sobre el archivo de imagen en lugar del disco en vivo — xfs_repair /path/to/image.img. Si la reparación produce un resultado peor del esperado, todavía tendrás la copia a nivel de sectores para volver a trabajar desde ella. La única restricción: el destino de la imagen debe ser un disco lo bastante grande para contener el tamaño bruto completo de la partición origen, no solo el espacio usado.
/lost+found y les asigna nombres basados en su número de inodo. Si recuerdas tamaños aproximados de archivo, fechas de creación o tipos de contenido, puedes reducir los candidatos usando stat para comprobar los metadatos del inodo y file para identificar el tipo de contenido a partir del encabezado binario — file /mnt/diskX/lost+found/123456789 te dirá si un inodo contiene un JPEG, un contenedor de vídeo, un archivo comprimido, etc. Para archivos multimedia, la mayoría pueden identificarse y renombrarse según su contenido. Para bases de datos o datos de aplicaciones sin un encabezado legible, la identificación es más difícil y puede requerir comparar tamaños de archivo con copias de seguridad verificadas o con los registros de la aplicación que registraron los nombres de archivo originales.
