El RAID por software delega en el kernel la lógica que en otros entornos maneja una controladora dedicada. mdadm es la interfaz de usuario para el subsistema md (Multiple Devices) del kernel Linux, que existe desde el 2.4 y lleva décadas siendo la solución estándar en bare metal sin RAID hardware. Lo que hace el kernel es presentar un dispositivo de bloque virtual —por ejemplo /dev/md0— construido sobre dos o más discos físicos, aplicando la estrategia de redundancia que hayas elegido.
La razón por la que esto funciona bien es que la lógica de paridad y mirroring es simple aritmética de bloques. No necesitas hardware especializado: cualquier CPU moderna ejecuta esas operaciones con un coste despreciable. La ventaja real sobre el RAID hardware tradicional es la portabilidad: el array md vive en los metadatos del propio disco, así que puedes mover los discos a otra máquina con Linux y el array se reensambla solo. Con una controladora propietaria, dependes de que el fabricante siga existiendo y de que tengas exactamente el mismo modelo.
Cuándo usarlo está bastante claro: servidores bare metal donde controlas el hardware. En cloud, AWS, GCP o cualquier proveedor de IaaS ya gestiona la redundancia a nivel de almacenamiento subyacente; montar mdadm sobre EBS o persistent disk es redundancia inútil que solo añade complejidad. En bare metal con discos locales —un servidor de base de datos, un NAS con hardware de PC, un servidor de ficheros físico— mdadm es exactamente lo que necesitas.
Lo que rompes si te equivocas depende del nivel. En RAID 1 (mirroring puro) cada disco tiene una copia completa: tolerancia a un fallo, pero el espacio útil es el 50% del total. En RAID 5 distribuyes paridad entre todos los discos: toleras un fallo, recuperas espacio (N-1 discos útiles), pero el rebuild tras un fallo es IO-intensivo y si otro disco muere durante ese rebuild pierdes todo. En RAID 10 combinas striping y mirroring (necesitas mínimo 4 discos): mejor rendimiento de escritura que RAID 5 y rebuild más rápido, pero mismo overhead de espacio que RAID 1. El error clásico es confundir RAID con backups: un array degradado no te protege de un borrado accidental, corrupción de datos, o fallo simultáneo que supere la tolerancia del nivel.
# Escenario: cuatro discos en un servidor bare metal.
# Vamos a crear un RAID 10 con /dev/sdb, /dev/sdc, /dev/sdd, /dev/sde.
# Antes de nada, confirma que no tienen particiones ni arrays previos:
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
wipefs -a /dev/sdb /dev/sdc /dev/sdd /dev/sde
# Crear el array RAID 10 — el kernel empieza la sincronización inmediatamente
mdadm --create /dev/md0 \
--level=10 \
--raid-devices=4 \
/dev/sdb /dev/sdc /dev/sdd /dev/sde
# La sincronización inicial es en background; puedes ver el progreso aquí:
cat /proc/mdstat
# Estado detallado del array: discos activos, spare, estado de sync
mdadm --detail /dev/md0
# Guardar la configuración en mdadm.conf para que el array
# se reensamble automáticamente en el próximo arranque.
# --scan lee los metadatos de todos los arrays activos del sistema.
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
# Regenerar initramfs para que el boot loader incluya la config
update-initramfs -u
# Crear sistema de ficheros sobre el dispositivo md y montarlo
mkfs.ext4 -F /dev/md0
mkdir -p /srv/datos
mount /dev/md0 /srv/datos
# Entrada en /etc/fstab para montaje persistente.
# noatime reduce escrituras innecesarias en producción.
echo '/dev/md0 /srv/datos ext4 defaults,noatime 0 2' >> /etc/fstab
# ── Simulación de fallo y reemplazo de disco ──────────────────────────
# Marcar /dev/sde como fallido manualmente (simula un fallo real)
mdadm /dev/md0 --fail /dev/sde
# Comprobar que el array está degradado pero sigue funcionando
mdadm --detail /dev/md0 | grep -E 'State|Active|Failed'
# Quitar el disco fallido del array antes de extraerlo físicamente
mdadm /dev/md0 --remove /dev/sde
# Tras insertar el disco de reemplazo (aquí asumimos que aparece como /dev/sde)
# Limpiar cualquier firma residual del disco nuevo
wipefs -a /dev/sde
# Añadir el disco de reemplazo — el kernel inicia el rebuild automáticamente
mdadm /dev/md0 --add /dev/sde
# Monitorizar el progreso del rebuild; finish= te da la estimación de tiempo
watch -n5 cat /proc/mdstat
# Opcional: configurar notificaciones por email de eventos del array.
# MAILADDR en mdadm.conf activa el demonio de monitoreo.
grep -q 'MAILADDR' /etc/mdadm/mdadm.conf \
|| echo 'MAILADDR root' >> /etc/mdadm/mdadm.conf
# Habilitar el servicio de monitoreo de mdadm
systemctl enable --now mdmonitor
El punto de entrada real del subsistema es /proc/mdstat: ese fichero lo mantiene el kernel en tiempo real y refleja el estado de todos los arrays activos. El porcentaje que ves durante un rebuild —[====>................]— es la fracción de bloques que el kernel ya ha sincronizado entre los discos del par mirror correspondiente. El tiempo estimado en finish= varía según la IO del sistema porque md es deliberadamente throttled por defecto para no saturar el servidor; puedes ajustar eso con echo 50000 > /proc/sys/dev/raid/speed_limit_min si el rebuild de producción va demasiado lento.
El flujo --fail → --remove → --add no es arbitrario: md necesita saber explícitamente que un disco está fuera antes de aceptar uno nuevo en su lugar. Si añades directamente un disco sin pasar por --fail/--remove, el kernel lo rechazará a menos que el array tenga ranuras spare configuradas desde el principio. Para automatizar reemplazos hot-spare puedes añadir un quinto disco al crear el array con --spare-devices=1; en ese caso, mdadm inicia el rebuild solo cuando detecta el fallo, sin intervención manual.
El bloque mdadm --detail --scan >> /etc/mdadm/mdadm.conf seguido de update-initramfs -u es crítico. Sin eso, el initramfs no sabe ensamblar /dev/md0 antes de intentar montar el sistema de ficheros raíz —o en este caso /srv/datos— y el arranque falla con un error de dispositivo no encontrado. update-initramfs empaqueta la configuración dentro de la imagen de arranque para que mdadm en early userspace pueda reensamblar el array antes de que se ejecute el resto del init.
El servicio mdmonitor arranca mdadm --monitor en background, que vigila los eventos del subsistema md —fallos, rebuilds completados, arrays degradados— y los notifica vía MAILADDR. En servidores desatendidos eso es la diferencia entre enterarte de un disco fallido en minutos y enterarte cuando el segundo disco muere y pierdes datos.