- Identificar correctamente el disco y las particiones implicadas en el RAID es clave antes de marcar nada como defectuoso o retirarlo con mdadm.
- Para sustituir un disco en RAID Linux se marcan sus particiones como faulty, se eliminan del array y se añade un disco nuevo con el mismo esquema para resincronizar.
- La gestión de swap, particiones especiales y el montaje correcto de discos RAID en otros sistemas evita errores al extraer o reutilizar discos.
- RAID proporciona redundancia, pero no reemplaza a las copias de seguridad externas, imprescindibles ante fallos lógicos o errores humanos.
Trabajar con un RAID por software en Linux cuando un disco empieza a dar problemas puede imponer bastante respeto, sobre todo si todo el sistema (incluido el arranque) vive dentro de ese RAID. Sin embargo, conociendo bien las herramientas y entendiendo qué estás haciendo en cada paso, es perfectamente posible cambiar un disco defectuoso sin cargarte el sistema ni tener que reinstalarlo desde cero.
El objetivo de esta guía es explicar, paso a paso y con todo lujo de detalles, cómo sustituir un disco duro que falla en una configuración RAID en Linux basada en mdadm, cómo preparar el sistema para ello, qué comprobar antes de tocar nada y qué hacer después del reemplazo. Además, veremos algunos casos prácticos habituales, como servidores con RAID1 o RAID10, entornos tipo Hetzner con RAID por defecto y problemas típicos al intentar leer discos RAID desde otros sistemas.
Conceptos básicos: RAID por software con mdadm en Linux
En muchos servidores Linux el RAID se monta con mdadm como RAID por software, sin controlador hardware dedicado. Esto significa que el kernel y la herramienta mdadm son quienes gestionan los arrays RAID (md0, md1, md2, etc.) usando particiones de discos físicos como /dev/sda1, /dev/sdb1, etc.
La configuración más habitual en servidores dedicados o domésticos es el RAID1 (espejo) o RAID10 (striping sobre espejos). En estos escenarios, cada partición de los discos físicos se asocia a una partición RAID:
- md0 suele usarse como espacio de swap.
- md1 acostumbra a ser la partición /boot.
- md2 se reserva para la partición raíz /.
- md3 puede estar montada en /home u otros datos.
Cada mdX se alimenta de las particiones equivalentes de todos los discos: por ejemplo, md0 usa /dev/sda1 y /dev/sdb1; md1 usa /dev/sda2 y /dev/sdb2; y así sucesivamente. De esta forma, cuando un disco falla, el RAID sigue funcionando gracias a las copias en el resto de discos.
Antes de tocar nada conviene revisar el estado general del RAID. Dos comandos clave para esto son:
- cat /proc/mdstat – muestra de forma resumida el estado de todos los arrays md.
- mdadm –detail /dev/mdX – da información detallada de un array concreto.
Un ejemplo típico del contenido de /proc/mdstat en un RAID1 podría ser:
# cat /proc/mdstat
Personalities :
md3 : active raid1 sda3 sdb3
439553856 blocks super 1.0
md1 : active raid1 sdb1 sda1
19529600 blocks super 1.0
unused devices: <none>
Los indicadores entre corchetes son fundamentales: significa que las dos copias (dos discos) están bien; indicaría que solo una de las dos copias está activa; marca una partición como faulty o defectuosa dentro del array.

Comprobar qué disco está fallando realmente
Antes de marcar nada conviene asegurarse de qué disco es el problemático. Un paso muy recomendable es revisar el estado SMART de las unidades para detectar sectores reasignados, errores de lectura o cualquier indicio de fallo físico, o usar herramientas como HD Tune para comprobar la salud del disco.
Para ello se usa la herramienta smartctl, incluida en el paquete smartmontools. Su instalación es sencilla:
En CentOS:
yum install smartmontools
En Ubuntu o Debian:
sudo apt-get install smartmontools
Una vez instalado, se puede consultar el estado SMART de un disco con:
sudo smartctl -a /dev/sda
sudo smartctl -a /dev/sdb
Revisando parámetros como Reallocated_Sector_Ct, Current_Pending_Sector o errores de lectura se puede confirmar si uno de los discos (sdb, por ejemplo) está en peor estado y conviene sacarlo del RAID y sustituirlo.
En entornos con RAID por hardware también es útil identificar el controlador instalado. Para eso se recurre a lshw, que genera un inventario del hardware del servidor.
Instalación de lshw:
CentOS:
yum install lshw
Ubuntu o Debian:
sudo apt-get install lshw
Para ver un resumen rápido del hardware se puede usar:
lshw -short
O bien volcar toda la información a un fichero de texto con:
lshw > hardware-info.txt
En la salida verás, por ejemplo, controladoras PERC H330 u otros modelos si hay RAID hardware, aunque en esta guía nos centramos en mdadm (RAID por software).
Identificar la estructura del RAID y las particiones implicadas
Antes de quitar un disco del RAID es básico entender cómo están repartidas las particiones. El comando lsblk es perfecto para esto, ya que muestra tanto los discos físicos como los arrays RAID md y sus puntos de montaje.
Un ejemplo típico en un servidor con dos discos en RAID1 sería:
root@server:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
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
└─sda5 8:5 0 1M 0 part
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
└─sdb5 8:21 0 1M 0 part
De esta salida podemos extraer varias conclusiones:
- Hay dos discos físicos, sda y sdb, con idéntico esquema de particiones.
- Cada par de particiones sdaX / sdbX alimenta a un mdX concreto (md0, md1, md2, md3).
- Las particiones md están en RAID1, es decir, cada bloque se guarda en ambos discos.
Para profundizar en la información de cada array podemos usar:
mdadm --detail /dev/md0
La parte final de la salida muestra los dispositivos que participan en ese array:
# mdadm --detail /dev/md0
...
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
Esta relación es crítica para no equivocarse de partición a la hora de marcarla como defectuosa o retirarla.
Marcar un disco como defectuoso y retirarlo del RAID con mdadm
Supongamos que hemos detectado que el disco /dev/sdb es el que está fallando (por ejemplo, presenta errores SMART o problemas de lectura). La idea es “expulsarlo” del RAID de forma controlada, array por array.
En un primer momento, /proc/mdstat puede mostrar algo así:
# cat /proc/mdstat
Personalities :
md3 : active raid1 sda3 sdb3
439553856 blocks super 1.0
md1 : active raid1 sdb1 sda1
19529600 blocks super 1.0
unused devices: <none>
Aunque sdb esté tocado, sigue integrado en el RAID y aparentemente operativo. Para poder retirarlo correctamente hay que seguir dos pasos con cada partición implicada: marcarla como faulty y luego eliminarla del array.
1. Marcar la partición del disco como faulty
mdadm no permite quitar una partición sana sin más. Primero hay que indicarle que esa partición es defectuosa. El comando general es:
mdadm RUTA_DEL_RAID_ARRAY -f RUTA_DEL_DISCO_DURO
Por ejemplo, si queremos marcar como defectuosas las particiones /dev/sdb3 y /dev/sdb1 en los arrays md3 y md1 respectivamente, haríamos:
# mdadm /dev/md3 -f /dev/sdb3
mdadm: set /dev/sdb3 faulty in /dev/md3
# mdadm /dev/md1 -f /dev/sdb1
mdadm: set /dev/sdb1 faulty in /dev/md1
Tras esto, /proc/mdstat ya reflejará que esas particiones están marcadas como (F):
# cat /proc/mdstat
Personalities :
md3 : active raid1 sda3 sdb3(F)
439553856 blocks super 1.0
md1 : active raid1 sdb1(F) sda1
19529600 blocks super 1.0
unused devices: <none>
El indicador nos confirma que solo queda una copia activa en cada RAID, lo cual significa que el array está degradado pero aún funcional.
2. Eliminar la partición faulty del array RAID
Una vez marcada como defectuosa, ya podemos retirar la partición del array con el parámetro -r de mdadm:
mdadm -r /RUTA_DEL_RAID_ARRAY /RUTA_DEL_DISCO_DURO
Aplicado a nuestro ejemplo:
# mdadm -r /dev/md3 /dev/sdb3
mdadm: hot removed /dev/sdb3 from /dev/md3
# mdadm -r /dev/md1 /dev/sdb1
mdadm: hot removed /dev/sdb1 from /dev/md1
Si repetimos este proceso con todas las particiones del disco sdb que formen parte de arrays md (sdb1, sdb2, sdb3, sdb4…), terminaremos teniendo un RAID compuesto solo por las particiones de sda.
El estado final de /proc/mdstat, tras retirar todas las particiones de sdb, puede ser algo así:
# cat /proc/mdstat
Personalities :
md3 : active raid1 sda3
439553856 blocks super 1.0
md1 : active raid1 sda1
19529600 blocks super 1.0
unused devices: <none>
Aunque el array siga pensando que debería tener 2 discos (2/1), en la práctica está funcionando con uno solo, y eso nos permitirá plantear dos caminos: o bien “reducir” el RAID a un solo dispositivo con mdadm –grow, o bien añadir un disco nuevo como reemplazo para que se resincronice.
Gestionar la swap y otras particiones especiales en el disco defectuoso
Cuando se trabaja con discos en RAID es habitual que también haya particiones swap repartidas entre ellos. Antes de extraer físicamente un disco o reformatearlo, hay que asegurarse de que la swap de ese disco no está en uso.
Para ver qué áreas de intercambio está usando el sistema se consulta:
# cat /proc/swaps
Filename Type Size Used Priority
/dev/sda2 partition 9765884 0 -1
/dev/sdb2 partition 9765884 0 -2
También se puede comprobar qué entradas de swap hay definidas en /etc/fstab:
# grep swap /etc/fstab
/dev/sda2 none swap sw
/dev/sdb2 none swap sw
Antes de quitar el disco sdb o sus particiones, desactiva su swap con:
# swapoff /dev/sdb2
Después de esto, es buena idea eliminar o comentar la línea correspondiente en /etc/fstab para que el sistema no intente activar esa swap en futuros reinicios.
Reducir el RAID a un solo disco sin reinstalar el sistema
En algunos escenarios, el objetivo no es sustituir el disco defectuoso por otro, sino liberar ese segundo disco para otros usos (por ejemplo, en un servidor dedicado como los de Hetzner) y seguir funcionando con un RAID “de un solo disco”. Aunque la idea suena rara, a efectos prácticos permite mantener la estructura mdX sin reinstalar.
El procedimiento general consiste en:
- Marcar como faulty y eliminar las particiones del segundo disco del RAID (como hemos visto).
- Usar mdadm –grow para ajustar el número de dispositivos RAID esperados a 1.
- Repetir este proceso para todos los arrays md implicados (md0, md1, md2, md3…).
Una vez retirada, por ejemplo, /dev/sdb1 de md0, podemos “agrandar” (en terminología de mdadm) el array para que pase a considerar solo un dispositivo:
root@server:~# mdadm --grow /dev/md0 --raid-devices=1 --force
raid_disks for /dev/md0 set to 1
Este ajuste evita que mdadm marque el array como degradado permanentemente por falta del segundo disco. Lo mismo se hace con md1, md2 y md3, adaptando el número de raid-devices a 1 tras retirar el disco sobrante.
Cuando se complete el proceso en todas las particiones, el servidor puede reiniciarse sin necesidad de reinstalar el sistema operativo. El disco “liberado” (antes sdb) ya no estará asociado a los arrays y podrá reparticionarse y formatearse para otros usos.
Para comprobar el resultado final se puede recurrir tanto a mdadm -D /dev/mdX como a lsblk para ver qué md sigue montado en qué punto y con qué discos físicos debajo.
Sustituir el disco por uno nuevo y resincronizar el RAID
El caso más habitual en un RAID1 o RAID10 es que quieras cambiar el disco que falla por uno nuevo manteniendo la redundancia. A grandes rasgos, el proceso es:
- Retirar todas las particiones del disco defectuoso del RAID (como hemos visto).
- Extraer físicamente el disco dañado y colocar el nuevo (en la misma bahía, si es hot-swap).
- Particionar o inicializar el disco nuevo con el mismo esquema que el disco sano.
- Añadir las nuevas particiones al RAID con mdadm –add y dejar que se resincronicen.
En un RAID10 doméstico de cuatro discos, sin disco de sistema separado, todo el sistema puede estar dentro del RAID, con la imagen de arranque en cada uno de los discos. En ese caso, es crucial clonar también la parte de arranque (MBR/EFI) al disco nuevo para que siga siendo arrancable si falla otro disco; si necesitas gestionar particiones y arranque, consulta la guía para convertir un disco de MBR a GPT.
Tras añadir el disco nuevo al RAID, un mdadm –detail /dev/md0 mostrará una entrada para ese nuevo dispositivo como “spare” o en proceso de “recovery” hasta completar la resincronización. El listado típico de discos en el RAID podría ser:
Number Major Minor RaidDevice State
7 8 128 0 active sync /dev/sdi
1 8 32 1 active sync /dev/sdc
2 8 48 2 active sync /dev/sdd
3 8 64 3 active sync /dev/sde
4 8 80 4 active sync /dev/sdf
6 8 112 5 active sync /dev/sdh
Mientras dure la resincronización es normal ver actividad sostenida en /proc/mdstat indicando el porcentaje completado. Conviene no hacer operaciones agresivas de E/S durante este proceso para no alargarlo innecesariamente.
Montar y leer discos RAID en otros sistemas (por ejemplo, Windows o WSL2)
Un problema bastante común es intentar leer un disco que formaba parte de un RAID Linux desde otro sistema, ya sea directamente desde Windows o a través de WSL2. En esos casos, muchas herramientas solo ven “Linux RAID” y no el sistema de ficheros real (XFS, ext4, etc.).
Por ejemplo, si conectas un disco que pertenecía a un RAID a un Linux independiente, el comando fdisk -l puede mostrar algo como:
Disk /dev/sdd: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WD20EARX-00PASB0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 65AC2242-AC51-4A1B-8A4C-01D7890D6711
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
Al intentar montar directamente la partición grande como XFS puede aparecer:
sudo mount -t xfs /dev/sdd4 /mnt/tempdisk
mount: /mnt/tempdisk: wrong fs type, bad option, bad superblock on /dev/sdd4,
missing codepage or helper program, or other error.
Si montas sin especificar tipo de sistema de archivos, probablemente dirá:
sudo mount /dev/sdd4 /mnt/tempdisk
mount: /mnt/tempdisk: unknown filesystem type 'linux_raid_member'.
Esto no significa que los datos estén perdidos, sino que esa partición no es directamente un sistema de ficheros, sino un miembro de un RAID md. Para leer su contenido hay que ensamblar primero el RAID con mdadm (usando el superblock), de forma que aparezca el dispositivo /dev/mdX correspondiente, y solo entonces montar el sistema de ficheros XFS o ext4 sobre /dev/mdX, no sobre /dev/sdd4.
En Windows la cosa se complica aún más, porque el soporte nativo para XFS o mdadm no existe y hay que recurrir a software de terceros. Muchas herramientas gratuitas solo soportan ext2/3/4 de forma limitada y no entienden los metadatos RAID, de ahí que algunas unidades aparezcan vacías o ilegibles.
RAID no es copia de seguridad: consideraciones finales y riesgos
Algo que no conviene olvidar nunca es que RAID aporta redundancia, no backups. Un RAID1 o RAID10 protege frente al fallo de uno de los discos, pero no frente a borrados accidentales, corrupción lógica, ransomware o errores del usuario: esos se replican en todos los discos del array.
Cuando tocas una configuración RAID en producción, cualquier comando mal lanzado (por ejemplo, eliminar la partición equivocada, marcar como faulty el disco sano, o confundir sda con sdb) puede dejar el sistema en un estado irrecuperable sin copias externas. Por eso es tan importante:
- Revisar dos veces qué dispositivo vas a tocar (lsblk, mdadm -D, /proc/mdstat).
- Hacer copia de seguridad previa siempre que sea posible.
- Tomar nota de la configuración actual (salida de mdadm –detail –scan, particionamiento, etc.).
Un enfoque prudente es probar antes en un entorno de laboratorio o en una máquina virtual con un RAID de prueba, replicando la estructura de particiones y arrays. Así puedes practicar el proceso de marcar discos faulty, retirarlos, usar mdadm –grow y volver a añadir discos hasta sentirte cómodo con los comandos y su efecto real.
Manejar correctamente un disco que falla en un RAID Linux exige calma y método: identificar el disco problemático con SMART y lshw, revisar la estructura del RAID con lsblk y mdadm, marcar de forma segura las particiones como faulty, retirarlas, ajustar el número de dispositivos si quieres quedarte con un solo disco, o bien introducir un disco nuevo para que el array se resincronice. Todo ello sin perder de vista que el RAID no te exime de tener buenas copias de seguridad externas, que serán tu última línea de defensa si algo sale mal; consulta también cómo recuperar un disco duro dañado si llegases a necesitarlo.