Cómo sustituir un disco duro que falla en un RAID Linux

Cuando un disco duro empieza a fallar dentro de una configuración RAID en Linux, es fácil entrar en pánico: el servidor deja de responder, el sistema no arranca o el pool de almacenamiento se queda en estado «UNAVAIL». La buena noticia es que, si el RAID está bien planteado y se actúa con cuidado, es posible sustituir el disco problemático y recuperar la situación sin perder datos.

En este artículo vamos a ver, de forma muy detallada y con un enfoque práctico, cómo identificar el disco roto, cómo retirarlo de un RAID por software con mdadm, cómo gestionar casos más delicados como un pool ZFS que no quiere importar por falta de réplicas, qué ocurre cuando intentas leer discos en Windows con WSL2 y XFS, y cómo manejar escenarios donde los discos del RAID tienen tamaños diferentes y luego quieres aprovechar el espacio sobrante.

Conceptos básicos: RAID por software en Linux (mdadm, ZFS, tipos de RAID)

Antes de ponernos a tocar nada conviene tener claros algunos conceptos fundamentales sobre RAID en Linux. Esto evitará sustos y errores irreversibles cuando llegue el momento de reemplazar un disco dañado.

En la mayoría de servidores Linux tradicionales se utiliza RAID por software basado en mdadm. Este sistema crea dispositivos virtuales /dev/mdX (por ejemplo, /dev/md0, /dev/md1…) que se construyen a partir de particiones físicas como /dev/sda1, /dev/sdb2, etc. Sobre esos /dev/mdX se montan sistemas de ficheros ext4, XFS u otros.

Un caso diferente, cada vez más extendido, es el uso de ZFS como sistema de archivos y gestor de volúmenes. ZFS no se apoya en mdadm, sino que gestiona su propia «redundancia» mediante vdevs (mirrors, RAIDZ, etc.). Cuando se rompe un disco en ZFS, el proceso de sustitución y recuperación se gestiona con comandos como zpool y no con mdadm.

También es importante no confundir RAID con copias de seguridad: el RAID ofrece redundancia y continuidad de servicio, pero no sustituye a un backup. Un RAID1 puede salvarte si muere un disco, pero no si borras por error datos o si se corrompe toda la estructura lógica del sistema de archivos.

En muchos proveedores (como Hetzner y otros dedicados), las imágenes de sistema vienen ya con un RAID1 por software preconfigurado sobre dos discos, repartido en varias particiones: swap, /boot, la raíz / y en ocasiones /home, cada una con su correspondiente /dev/mdX.

Cómo inspeccionar el estado de un RAID por software con mdadm

Cuando sospechas que uno de los discos está empezando a fallar, lo primero es ver exactamente qué está ocurriendo en el RAID. Para eso tienes varias herramientas básicas que deberías dominar.

Una orden muy útil es lsblk, que muestra cómo se organizan los discos, particiones y dispositivos RAID en el sistema. Con un solo comando puedes ver qué discos físicos hay y cómo se relacionan con /dev/mdX:

Ejemplo de salida de lsblk (simplificada):

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop1 7:1 0 110.6M 1 loop /snap/core/...
sda 8:0 0 3.6T 0 disk
├─sda1 8:1 0 16G 0 part └─md0 9:0 0 16G 0 raid1
├─sda2 8:2 0 512M 0 part └─md1 9:1 0 511M 0 raid1 /boot
├─sda3 8:3 0 2T 0 part └─md2 9:2 0 2T 0 raid1 /
└─sda4 8:4 0 1.7T 0 part └─md3 9:3 0 1.7T 0 raid1 /home
sdb 8:16 0 3.6T 0 disk
├─sdb1 8:17 0 16G 0 part └─md0 9:0 0 16G 0 raid1
├─sdb2 8:18 0 512M 0 part └─md1 9:1 0 511M 0 raid1 /boot
├─sdb3 8:19 0 2T 0 part └─md2 9:2 0 2T 0 raid1 /
└─sdb4 8:20 0 1.7T 0 part └─md3 9:3 0 1.7T 0 raid1 /home

Con esta estructura ves que hay dos discos, sda y sdb, y que cada partición de sda tiene su espejo en sdb, formando los arrays md0, md1, md2 y md3. En un entorno así, si uno de los discos falla, el otro debería seguir conteniendo toda la información.

Para profundizar en un array concreto se usa mdadm –detail. Por ejemplo, para ver el estado de /dev/md0:

mdadm --detail /dev/md0

La salida incluye datos como el nivel de RAID, tamaño, número de discos activos y, al final, una tabla con los dispositivos que forman el array. Ahí verás algo como:

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1

En esa tabla es donde puedes detectar si una partición está marcada como faulty (defectuosa), «removed» o si falta un disco. Esa información es clave para saber qué disco hay que sustituir o de cuál conviene retirarse sin romper el sistema.

Retirar un disco sano de un RAID (por ejemplo en servidores dedicados)

En algunos casos no hay un fallo físico del disco, sino que simplemente quieres liberar uno de los discos del RAID para dedicarlo a otro uso: almacenamiento independiente, backups, etc. Esto es habitual en servidores dedicados donde el proveedor te instala un RAID1 por defecto, pero tú necesitas el segundo disco libre.

La idea es la siguiente: marcar como defectuosas las particiones de ese disco en cada array, retirarlas del RAID y luego redimensionar el número de dispositivos para que el mdX deje de esperar ese segundo disco. El sistema seguirá funcionando con un «RAID» de un solo disco, que realmente es un pseudo-RAID pero te evita reinstalar.

El proceso hay que repetirlo para cada array mdX implicado (swap, /boot, /, /home…). Vamos a verlo paso a paso para md0, sabiendo que tienes que hacer lo mismo en md1, md2, etc.

1. Revisar la partición implicada en el array

Primero, comprueba qué particiones físicas componen /dev/md0:

mdadm -D /dev/md0

En la parte final de la salida verás algo tipo:

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1

Si tu objetivo es sacar del RAID el disco sdb, esa tabla te muestra que tendrás que actuar sobre /dev/sdb1 en el caso de md0, /dev/sdb2 en md1, y así sucesivamente.

2. Marcar la partición como defectuosa

mdadm no te deja quitar alegremente una partición que considera sana; primero hay que marcarla como fallada. Eso no daña el disco físicamente, solo indica al array que deje de usar esa réplica.

Ejemplo para md0 y sdb1:

mdadm /dev/md0 --fail /dev/sdb1

La respuesta típica será algo como «set /dev/sdb1 faulty in /dev/md0». A partir de ese momento, el array sabe que esa réplica ya no es de confianza y la pone en estado de fallo.

3. Remover la partición fallida del array

Una vez marcada como faulty, ya puedes retirar la partición del RAID:

mdadm /dev/md0 --remove /dev/sdb1

Eso hará que mdadm «desenganche» la partición física del array. A nivel lógico, md0 seguirá existiendo, pero ya solo estará respaldado por /dev/sda1.

4. Ajustar el número de dispositivos del RAID

En este punto md0 puede quedar en un estado degradado si todavía cree que debería haber dos dispositivos. Para que el sistema lo considere estable, necesitas cambiar el número de discos esperados en el array:

mdadm --grow /dev/md0 --raid-devices=1 --force

Aunque la palabra «grow» parezca indicar ampliación, en realidad en este contexto estás cambiando la configuración interna para decirle al array que ahora solo habrá un dispositivo activo.

Tras repetir este proceso en todos los mdX, puedes reiniciar el servidor. El resultado será un sistema que arranca usando un RAID por software con un único disco, y el otro disco quedará totalmente libre para particionarlo y formatearlo como quieras.

Reemplazo real de un disco que falla en mdadm RAID

Cuando el problema no es que quieras liberar un disco, sino que uno de ellos ha muerto de verdad, el procedimiento es similar pero con alguna diferencia clave: en lugar de quedarte con un solo disco, el objetivo es sustituir el disco dañado por otro nuevo y reconstruir el RAID.

En líneas generales, el ciclo sería:

• Identificar qué disco está fallando (smartctl, mensajes del kernel, mdadm –detail).
• Marcar como faulty las particiones de ese disco en cada mdX.
• Retirarlas del RAID con mdadm –remove.
• Sustituir físicamente el disco defectuoso por uno nuevo (evitar estafas al comprar discos).
• Particionar el disco nuevo para que sus particiones coincidan en tamaño y tipo con las del disco sano.
• Añadir las nuevas particiones a cada /dev/mdX con mdadm –add y dejar que se reconstruya.

Con mdadm –detail /dev/md0 puedes ir viendo el estado de la reconstrucción y comprobar cuándo vuelve a tener todos los discos activos y sincronizados. También puedes monitorizar el proceso con watch -n1 cat /proc/mdstat, que refrescará cada segundo la barra de progreso de la resync.

En configuraciones más avanzadas (por ejemplo RAID5 o RAID6), el mismo esquema aplica, pero el impacto de perder más de un disco a la vez puede ser catastrófico. Por eso es crítico sustituir rápidamente un disco que empieza a dar errores antes de que falle otro.

Crear y administrar un RAID nuevo (ejemplo RAID6 con mdadm)

Aunque el objetivo aquí es sustituir discos que fallan, ayuda ver cómo se construye un RAID desde cero para entender luego qué se está modificando al cambiar un disco. Un ejemplo típico es la creación de un RAID6 con varios discos usando mdadm.

Lo primero es asegurarse de que mdadm está instalado en el sistema. En Debian/Ubuntu se hace con:

sudo apt-get install mdadm

En sistemas tipo RedHat, el comando equivalente sería:

sudo yum install mdadm

Antes de crear el array conviene comprobar que los discos no tienen ya superbloques de RAIDs antiguos. Eso se hace examinando los discos o particiones potenciales:

sudo mdadm -E /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

Si no aparece ninguna firma previa, el siguiente paso es particionar cada disco con fdisk (o parted) creando una partición primaria de tipo RAID (código fd). La secuencia típica en fdisk sería: crear nueva partición (n), primaria (p), elegir número, aceptar sectores por defecto, cambiar tipo (t), seleccionar código fd, y escribir cambios (w).

Cuando todas las particiones estén preparadas, se crea el array:

sudo mdadm --create /dev/md0 --level=6 --raid-devices=5 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Esto generará /dev/md0 como un RAID6 utilizando cinco particiones. El array comenzará a reconstruirse automáticamente, y podrás seguir el progreso con:

watch -n1 cat /proc/mdstat

Una vez el RAID esté listo, hay que crear el sistema de archivos, por ejemplo ext4:

sudo mkfs.ext4 /dev/md0

Luego se monta sobre un directorio, por ejemplo /mnt/Raid6:

sudo mkdir -p /mnt/Raid6
sudo mount /dev/md0 /mnt/Raid6/

Para que se monte automáticamente al arrancar, se añade una entrada en /etc/fstab, algo así como:

/dev/md0 /mnt/raid6 ext4 defaults 0 0

Y para no perder la configuración del array, se genera el fichero de configuración de mdadm:

sudo mdadm --detail --scan --verbose >> /etc/mdadm.conf

Probar el RAID provocando el fallo de un disco

Antes de confiar tus datos a un RAID recién creado conviene comprobar que realmente se comporta como esperas ante un fallo. La forma más segura de hacerlo es simular el fallo de uno de los discos mediante mdadm, sin tocar el hardware físico.

Supongamos que tienes un RAID donde participan /dev/sdb1, /dev/sdc1 y un disco de reserva /dev/sdg1 preparado como spare. Puedes forzar el fallo lógico de /dev/sdc1 con:

sudo mdadm --manage --fail /dev/md0 /dev/sdc1

Después comprueba el detalle del array:

sudo mdadm --detail /dev/md0

En la salida deberías ver que el disco marcado como fallo ha pasado a estado faulty y se ha sustituido por el spare, que empezará a sincronizarse. Es la mejor prueba de que el RAID responde bien ante un incidente real.

Casos especiales: problemas con ZFS cuando muere un disco del pool

En entornos más modernos, especialmente con hipervisores como Proxmox, se utiliza ZFS para gestionar discos en pools con redundancia nativa. Un caso típico: tienes un pool ZFS en mirror (RAID1), uno de los dos discos muere y de repente el servidor deja de arrancar porque el pool raíz no se puede importar.

En esa situación, al intentar importar manualmente el pool puedes encontrarte mensajes como:

zpool import -f rpool
cannot import 'rpool': no such pool or dataset
Destroy and recreate the pool from a backup source

O un intento con otras opciones:

zpool import -N

Que devuelve un estado UNAVAIL e indica «insufficient replicas» y «damaged devices or data». El resumen es que ZFS no ve suficientes copias válidas para asegurar la integridad del pool, y por eso se niega a importarlo de forma estándar.

En estos casos es crítico no improvisar demasiados comandos al azar. Algunas ideas a tener en cuenta:

• Si el mirror estaba correctamente montado, un solo disco sano debería bastar para importar el pool en modo degradado. Si ZFS dice que no hay suficientes réplicas, puede haber corrupción grave o mala detección de dispositivos.
• No puedes «decirle» a ZFS que sustituya directamente un disco muerto por otro si el pool no llega a importarse; no es como mdadm donde trabajas a nivel de partición sin montar el sistema de archivos.
• Lo prudente suele ser intentar una importación forzada y en solo-lectura con flags avanzados (por ejemplo, -F, -o readonly=on), revisar qué datasets son recuperables y copiar datos fuera si es posible.
• Si de verdad el pool no se deja importar de ninguna forma, el siguiente paso sensato es clonar o hacer imagen de bloque del disco que aún funciona, para preservar esa «copia de seguridad» antes de más experimentos.

El gran problema en un escenario como el descrito (donde el disco bueno es a la vez el único sitio donde están los datos) es que no hay red de seguridad adicional. Por eso conviene interrumpir cualquier intento agresivo de reparación y centrarse primero en salvar el contenido del disco que todavía responde, aunque sea fuera de ZFS.

Leer un RAID Linux (XFS, ext4) desde Windows usando WSL2

Otro escenario muy habitual es el de quien saca un disco de un servidor Linux y quiere leer sus datos desde un PC con Windows. A primera vista puede parecer sencillo: conectas el disco por USB, usas alguna herramienta tipo Linux Reader y listo. Pero cuando ese disco forma parte de un RAID por software, la cosa se complica.

En el caso concreto de un disco con tabla GPT donde todas las particiones aparecen como «Linux RAID», Windows y muchas utilidades gráficas no saben qué hacer con ellas. Por ejemplo, un fdisk puede mostrar algo así:

Device Start End Sectors Size Type
/dev/sdd1 1032192 5031935 3999744 1.9G Linux RAID
/dev/sdd2 5031936 9031679 3999744 1.9G Linux RAID
/dev/sdd3 30720 1032191 1001472 489M Linux RAID
/dev/sdd4 9031680 3907028991 3897997312 1.8T Linux RAID

Si dentro de /dev/sdd4 hay, por ejemplo, un sistema de archivos XFS perteneciente a un array mdadm, intentar montarlo directamente suele dar algo como:

mount -t xfs /dev/sdd4 /mnt/tempdisk
mount: wrong fs type, bad superblock on /dev/sdd4...

O si lo intentas sin especificar tipo de FS:

mount /dev/sdd4 /mnt/tempdisk
mount: unknown filesystem type 'linux_raid_member'

Esos mensajes indican que /dev/sdd4 no es directamente un sistema de archivos, sino un miembro de un RAID. El sistema de ficheros «real» está sobre /dev/mdX, que en este contexto todavía no existe. Para poder leer el contenido desde WSL2 (Ubuntu, por ejemplo) tendrás que:

• Cargar los módulos de mdadm en el kernel de WSL2 si no lo están.
• Usar mdadm –examine sobre las particiones RAID para identificar el array al que pertenecen.
• Recrear el array mdX en modo «assemble» (mdadm –assemble) para que /dev/md0 (o el que toque) aparezca.
• Una vez exista /dev/md0, montar ese dispositivo con el tipo de FS adecuado (XFS, ext4, etc.).

Sin pasar por esa fase de ensamblado del RAID, no podrás montar directamente las particiones marcadas como Linux RAID, ni aunque sepas que dentro hay un XFS. Y en Windows nativo, salvo herramientas muy específicas (y normalmente de pago o de solo lectura), es difícil manejar bien estos casos.

RAID con discos de distinto tamaño y aprovechamiento del espacio sobrante

Un caso curioso, pero cada vez más frecuente, es el de quien monta un RAID1 con dos discos de tamaños muy diferentes, por ejemplo, un NVMe de 1 TB y un SATA de 500 GB. En un apuro puede ser aceptable, pero el RAID1 solo aprovechará el tamaño del disco más pequeño para el espejo.

En ese escenario, el resultado típico será que la «segunda mitad» del disco de 1 TB quede sin usar, simplemente porque el RAID1 está limitado a los primeros 500 GB (el tamaño del disco pequeño). Esa parte no formará parte del array y quedará como espacio no asignado o en otra partición independiente.

Supongamos que ahora decides hacer las cosas bien y quieres reemplazar el disco pequeño por otro disco de 1 TB idéntico al primero. El procedimiento de sustitución de disco en mdadm es similar a lo ya descrito: se marca el disco viejo como faulty, se retira del array, se inserta el disco nuevo, se crean las particiones equivalentes y se añade al RAID para que se reconstruya.

La duda viene después: ¿cómo aprovechar el espacio adicional que ahora tienes en ambos discos para ampliar, por ejemplo, la partición raíz / en unos 500 GB más? A grandes rasgos, los pasos que se suelen seguir son:

• Redimensionar las particiones RAID en ambos discos para que ocupen el espacio extra (con herramientas como parted o fdisk, y siempre con extremo cuidado).
• Usar mdadm –grow sobre el array mdX para decirle que ahora su tamaño efectivo es mayor.
• Una vez que el dispositivo RAID tenga más capacidad, redimensionar el sistema de archivos encima (por ejemplo, ampliar ext4 con resize2fs; ver cómo liberar espacio de disco en Linux).

Este tipo de operaciones, especialmente sobre la partición raíz y con UEFI/EFI, swap y demás, implican toquetear la tabla de particiones, el array RAID y los sistemas de ficheros. Es muy recomendable tener copias de seguridad recientes, y entender bien cómo están configuradas las particiones EFI y la swap para no dejar el sistema sin arranque.

Si se hace todo correctamente, ni la swap ni la partición EFI deberían desconfigurarse, pero cualquier error en los números de sector, en el orden de las particiones o en los dispositivos registrados en /etc/fstab y el cargador de arranque puede dejar el sistema en modo «rescue» pidiendo reparaciones manuales.

En resumen, el uso de discos de distinto tamaño en RAID1 es viable a corto plazo pero poco recomendable a medio-largo plazo, porque complica mucho la gestión futura del espacio cuando intentes homogeneizar el hardware.

Después de todo este repaso, la idea que debe quedarte clara es que sustituir un disco que falla en un RAID Linux no es magia, pero sí requiere método: primero entender la topología del RAID (mdadm o ZFS), luego identificar sin lugar a dudas qué disco o partición intervenir, y finalmente ejecutar los comandos adecuados (mdadm –fail, –remove, –add, zpool import, etc.) con cabeza fría. Con una estrategia ordenada, buenos backups y sin prisas se puede salir airoso de la mayoría de situaciones, desde liberar un disco en un servidor dedicado hasta recuperar un pool ZFS rebelde o intentar rescatar datos desde Windows a través de WSL2.