Debian 13 mdadm RAID degradado: reemplazo y reconstrucción sin pérdida de datos

octubre 10, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 7

¿Te fue útil?

Suena la alarma. El gráfico de almacenamiento está “bien” (siempre lo está), pero la latencia de tu aplicación sube y un nodo
reporta errores de disco.
Accedes y lo ves: [U_], [UU_U], o el temido array “inactivo”.
Puedes reconstruir esto de forma limpia—o convertir un disco fallado en un incidente mayor con pérdida permanente de datos.

Esta es una guía para producción sobre RAID por software mdadm en Debian 13: diagnóstico rápido, reemplazo seguro, monitorización de reconstrucción,
y las esquinas afiladas con las que la gente suele cortarse. Es opinada porque el sistema de archivos no se conmueve por tus sentimientos.

Reglas básicas: qué significa realmente “degradado”

“Degradado” no es una sensación. Es un estado preciso: un array carece al menos de un miembro, ha expulsado un miembro, o tiene un miembro
presente pero no lo considera lo bastante fiable para leer de él. El array podría seguir sirviendo lecturas y escrituras. Eso es la buena noticia.
La mala noticia es que ya has gastado tu presupuesto de redundancia.

El objetivo es simple: restaurar la redundancia sin introducir nueva incertidumbre. En la práctica, eso significa:

No adivines cuál es el disco fallado. Identifícalo por atributos estables (serial, WWN, bahía del chasis).
No “force assemble” a menos que entiendas la metadata y el modo de fallo. “Force” es una herramienta potente.
No reconstruyas sobre un disco que esté silenciosamente enfermo. SMART omite cosas por omisión, no por comisión.
No cambies dos cosas a la vez. Reemplaza un disco; verifica; luego continua.

Si ejecutas RAID5/6 y ya estás degradado, el sistema vive a crédito. Las lecturas tocarán todos los discos restantes,
tu tasa de errores subirá y la ventana de reconstrucción se convierte en una lotería de fiabilidad. Aún puedes ganar. Solo que no puedes ser casual.

Guion de diagnóstico rápido (primero/segundo/tercero)

La forma más rápida de arreglar un RAID degradado es evitar “hacer cosas” hasta saber con cuál de estos casos tratas:
(1) un disco realmente muerto, (2) un problema de conectividad, (3) un cambio en nombres de kernel/dispositivos, (4) errores latentes de medio expuestos por estrés,
o (5) un humano ya intentó arreglarlo.

Primero: confirma el estado del array y si está resyncando activamente

Revisa /proc/mdstat buscando degraded, resync, recovery, reshape, o check.
Confirma qué dispositivos md existen y sus personalidades (raid1/5/6/10).
Decide: ¿congelas cambios hasta que termine el resync, o intervienes ahora?

Segundo: identifica el miembro fallido por identidad estable, no por /dev/sdX

Mapea miembros md → particiones → dispositivos de bloque subyacentes.
Recopila serial/WWN y, si aplica, el mapeo de la bahía del chasis.
Decide: ¿el disco “ausente” está realmente ausente, o solo no se está ensamblando?

Tercero: clasifica el modo de fallo

Fallo duro: errores de E/S, dispositivo desaparecido, SMART dice “failing now.” Reemplaza el disco.
Ruta/cable/HBA: resets de enlace, errores CRC, dispositivo que hace flap. Arregla la conectividad primero.
Metadata/ensamblado: UUID equivocado, superbloque antiguo, mismatch con initramfs. Corrige la configuración de mdadm y ensambla con seguridad.
Problema de consistencia: conteo discordante, apagado no limpio. Ejecuta un check después de restaurar la redundancia.

Chiste #1: RAID significa “Redundant Array of Inexpensive Disks”, pero durante la reconstrucción suele significar “Really Anxious IT Department.”

Hechos e historia interesantes (por qué mdadm se comporta así)

Linux MD precede a mdadm. El RAID por software temprano en Linux usaba raidtools; mdadm se convirtió en el estándar práctico a medida que la metadata y el ensamblado mejoraron.
Las versiones de superblock importan. El metadata 0.90 vive al final del dispositivo (compatibilidad antigua), mientras que 1.x vive cerca del inicio; esto cambia el comportamiento de arranque y la facilidad con que la metadata antigua sobrevive borrados.
El “write hole” es real. RAID5 clásico puede perder consistencia tras un crash a mitad de una actualización de stripe; journaling y bitmaps de intención de escritura ayudan, pero no hacen que la física desaparezca.
Los bitmaps no siempre fueron comunes. Los bitmaps de intención de escritura reducen drásticamente el tiempo de resync tras apagados no limpios al rastrear regiones sucias en vez de escanear todo el array.
MD puede hacer reshape en línea. Cambiar layout, número de discos o nivel RAID es posible pero arriesgado y costoso en rendimiento—especialmente mientras está degradado.
El “check” y el “repair” de MD son modos separados. Un check puede ser no destructivo; repair puede escribir correcciones. Confundirlos es la forma en que la gente “arregla” datos hasta que quedan mal.
Los nombres de dispositivos no son identidades. /dev/sda es una sugerencia que hace el kernel según el orden de descubrimiento; el WWN es una identidad que trae el hardware.
Debian históricamente fue conservador. Los valores por defecto de Debian (y la cultura alrededor) suelen favorecer la corrección y estabilidad sobre la “automatización amigable” que oculta el estado.

Tareas prácticas (comandos, salidas, decisiones)

A continuación hay tareas prácticas que puedes ejecutar en Debian 13. Cada una incluye: un comando, lo que significa una salida típica, y la decisión que tomas.
Si tratas esto como una lista de verificación en lugar de un buffet, dormirás mejor.

Tarea 1: Leer `/proc/mdstat` como un adulto

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid10]
md0 : active raid1 sda1[0] sdb1[1]
      976630336 blocks super 1.2 [2/1] [U_]
      bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: <none>

Qué significa: md0 es RAID1 con dos miembros esperados. [2/1] significa 2 ranuras, 1 dispositivo funcionando. [U_] indica que el primer disco está arriba y el segundo falta/está fallando.

Decisión: El array está en funcionamiento pero sin redundancia. Prioriza restaurar un miembro espejo. No inicies otro mantenimiento arriesgado ahora.

Tarea 2: Obtener la historia autorizada de mdadm

cr0x@server:~$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Mon Sep  2 11:40:18 2024
        Raid Level : raid1
        Array Size : 976630336 (931.51 GiB 1000.20 GB)
     Used Dev Size : 976630336 (931.51 GiB 1000.20 GB)
      Raid Devices : 2
     Total Devices : 1
       Persistence : Superblock is persistent

       Update Time : Mon Dec 29 09:11:22 2025
             State : clean, degraded
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

              Name : server:0
              UUID : 3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2
            Events : 41290

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

Qué significa: mdadm coincide en que está clean, degraded (no resyncing). El miembro ausente está “removed”, no “failed.” Eso suele pasar tras repetidos errores de E/S o una extracción manual.

Decisión: Planea un reemplazo controlado. También pregunta: ¿por qué fue removido? Revisa los registros antes de declarar victoria.

Tarea 3: Encontrar los dispositivos miembros y sus identidades estables

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sda|sdb'
lrwxrwxrwx 1 root root  9 Dec 29 09:03 ata-SAMSUNG_MZ7L3960HCGR-00005_S4JNNX0T123456 -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 29 09:03 ata-SAMSUNG_MZ7L3960HCGR-00005_S4JNNX0T789012 -> ../../sdb

Qué significa: Tienes dos seriales distintos. Incluso si /dev/sdX cambia tras un reinicio, estas rutas by-id persisten.

Decisión: Desde ahora, cuando referencies un disco en tus notas o plan de cambios, usa serial/WWN, no sdb.

Tarea 4: Confirmar qué particiones pertenecen a MD y si falta algo

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,UUID
NAME        SIZE TYPE FSTYPE            MOUNTPOINTS UUID
sda       931.5G disk
├─sda1    931.5G part linux_raid_member            3b0d0f3b-5f2e-6d7a-8c6c-9b9b9dd5a1d2
└─sda2      512M part vfat              /boot/efi   1A2B-3C4D
sdb       931.5G disk
└─sdb1    931.5G part
md0       931.5G raid1 ext4             /          7b1e4d2d-6ad0-4f1e-bb0d-3b51f7e0f88a

Qué significa: sda1 es miembro RAID; sdb1 existe pero no tiene firma linux_raid_member. Eso puede significar que es nuevo/sin particionar, o que es el disco antiguo que perdió su tabla de particiones (menos probable, pero no lo asumas).

Decisión: Si sdb está destinado a ser el reemplazo, lo particionarás para que coincida con sda, y luego lo añadirás al array. Si sdb es un miembro existente que “salió”, investiga por qué perdió la metadata.

Tarea 5: Leer logs del kernel para el fallo real

cr0x@server:~$ sudo journalctl -k -b | grep -E 'md0|sdb|I/O error|reset|fail' | tail -n 30
Dec 29 08:52:11 server kernel: ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0x6 frozen
Dec 29 08:52:11 server kernel: ata2.00: irq_stat 0x08000000, interface fatal error
Dec 29 08:52:12 server kernel: ata2: hard resetting link
Dec 29 08:52:17 server kernel: sd 1:0:0:0: [sdb] tag#19 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Dec 29 08:52:17 server kernel: blk_update_request: I/O error, dev sdb, sector 1953525160 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 29 08:52:17 server kernel: md/raid1:md0: Disk failure on sdb1, disabling device.
Dec 29 08:52:17 server kernel: md/raid1:md0: Operation continuing on 1 devices.

Qué significa: Esto no es “mdadm actuando raro.” Son resets de enlace y errores de E/S. Suele ser el disco, pero también puede ser un cable, backplane o puerto HBA.

Decisión: Antes de reconstruir, decide si confías en la ruta. Si esto es una bahía hot-swap, vuelve a insertar o mueve el disco a una ranura conocida buena. Si es un servidor con cables SATA antiguos, reemplaza el cable. Las reconstrucciones son excelentes para convertir marginales en muertos.

Tarea 6: SMART del dispositivo sospechoso (e interprétalo como un pesimista)

cr0x@server:~$ sudo smartctl -a /dev/sdb | sed -n '1,120p'
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0-amd64] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       SAMSUNG MZ7L3960HCGR-00005
Serial Number:                      S4JNNX0T789012
Firmware Version:                   EDA7902Q
User Capacity:                      960,197,124,096 bytes [960 GB]
SMART overall-health self-assessment test result: PASSED

=== START OF SMART DATA SECTION ===
Critical Warning:                   0x00
Media and Data Integrity Errors:    14
Error Information Log Entries:      27
Warning  Comp. Temperature Time:    0
Unsafe Shutdowns:                   9

Qué significa: “PASSED” no es un certificado de salud perfecto. Dispositivos NVMe/SATA pueden “pasar” mientras registran errores de medio. Media and Data Integrity Errors > 0 es una señal roja en un array degradado.

Decisión: Si el dispositivo registra errores de medio/integridad, reemplázalo. Si SMART está limpio pero los logs del kernel muestran resets de enlace, prioriza revisar la ruta/hardware.

Tarea 7: Verificar que el array está montado y no hace algo peligroso ya

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/md0 / ext4 rw,relatime,errors=remount-ro

Qué significa: Root reside en /dev/md0. Esto importa porque no puedes detener el array casualmente.

Decisión: Cualquier plan de reconstrucción debe ser online y cauteloso. Si necesitas parar/ensamblar, lo harás desde medios de rescate—no improvises en un array root en vivo.

Tarea 8: Confirmar que la configuración de mdadm conoce el array (chequeo de fiabilidad al arranque)

cr0x@server:~$ grep -R "UUID=3b0d0f3b" /etc/mdadm /etc/mdadm/mdadm.conf
/etc/mdadm/mdadm.conf:ARRAY /dev/md0 metadata=1.2 UUID=3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2 name=server:0

Qué significa: Bien: el array está declarado. Mal: si falta, el ensamblado en arranque puede volverse “mejor esfuerzo”, lo que a veces significa “disco equivocado, día equivocado”.

Decisión: Si la entrada falta o está obsoleta, actualízala y reconstruye el initramfs una vez el sistema sea estable.

Tarea 9: Comprobar por “metadata fantasma” en el disco de reemplazo antes de añadirlo

cr0x@server:~$ sudo mdadm --examine /dev/sdb1
mdadm: No md superblock detected on /dev/sdb1.

Qué significa: Perfecto para un add fresco. Si vieras un superblock antiguo con un UUID distinto, tendrías que borrarlo o corres el riesgo de ensamblado incorrecto o rechazo al añadir.

Decisión: Procede a particionar y añadir. Si existe metadata antigua, detente y límpiala deliberadamente (ver checklist).

Tarea 10: Clonar la tabla de particiones del disco bueno al nuevo

cr0x@server:~$ sudo sfdisk -d /dev/sda | sudo sfdisk /dev/sdb
Checking that no-one is using this disk right now ... OK

Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: SAMSUNG MZ7L3960HCGR-00005
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

sfdisk: Successfully wrote the new partition table.
Syncing disks.

Qué significa: El disco nuevo ahora coincide con el layout conocido bueno. Esto es más seguro que editar manualmente starts/ends y crear desalineado o discrepancias de tamaño por error.

Decisión: Vuelve a leer particiones y verifica que existan antes de añadir al md.

Tarea 11: Volver a leer particiones y confirmar que el kernel ve la nueva partición

cr0x@server:~$ sudo partprobe /dev/sdb
cr0x@server:~$ lsblk /dev/sdb
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sdb      8:16   0 931.5G  0 disk
├─sdb1   8:17   0 931.5G  0 part
└─sdb2   8:18   0   512M  0 part

Qué significa: Las particiones están presentes. Si partprobe falla porque el disco está “ocupado”, puede que necesites un reinicio—pero no reinicies un sistema degradado casualmente a menos que hayas validado el ensamblado en arranque.

Decisión: Si las particiones existen, adelante. Si no, detente y corrige antes de tocar md.

Tarea 12: Añadir el nuevo miembro al array y observar que comience la reconstrucción

cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdb1
mdadm: added /dev/sdb1
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid10]
md0 : active raid1 sdb1[2] sda1[0]
      976630336 blocks super 1.2 [2/1] [U_]
      [=>...................]  recovery =  7.3% (71680000/976630336) finish=58.4min speed=258432K/sec
      bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: <none>

Qué significa: La recuperación está en marcha. Observa: sigue mostrando [U_] al principio; una vez que suficientes regiones se sincronicen, debería pasar a [UU] cuando termine.

Decisión: No lo toques salvo que sea necesario. Tu trabajo ahora es monitorizar errores y mantener el sistema tranquilo (CPU, I/O, temperaturas).

Tarea 13: Monitorizar el progreso de reconstrucción con más contexto

cr0x@server:~$ watch -n 2 'cat /proc/mdstat; echo; sudo mdadm --detail /dev/md0 | egrep "State|Rebuild|Resync|Raid Devices|Active Devices|Working Devices|Failed Devices"'
Every 2.0s: cat /proc/mdstat; echo; sudo mdadm --detail /dev/md0 | egrep "State|Rebuild|Resync|Raid Devices|Active Devices|Working Devices|Failed Devices"

md0 : active raid1 sdb1[2] sda1[0]
      976630336 blocks super 1.2 [2/2] [UU]
      bitmap: 0/8 pages [0KB], 65536KB chunk

             State : clean
      Raid Devices : 2
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0

Qué significa: El array volvió a clean, ambos miembros activos, sin dispositivos fallados. Este es el estado que quieres antes de hacer cualquier chequeo de consistencia.

Decisión: Con la redundancia restaurada, programa un scrub/check y luego arregla el “por qué” (monitorización, cableado, firmware, repuestos).

Tarea 14: Actualizar la configuración de mdadm e initramfs para que el próximo reinicio no sea picante

cr0x@server:~$ sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
ARRAY /dev/md0 metadata=1.2 UUID=3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2 name=server:0
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

Qué significa: initramfs ahora incluye la información de ensamblado actual de mdadm. Esto reduce sorpresas de “no arranca después de cambiar un disco”.

Decisión: Si este es un array root, este paso no es opcional. Las reconstrucciones arreglan la redundancia; initramfs arregla la mañana siguiente.

Tarea 15: Ejecutar una comprobación de consistencia no destructiva (después de la reconstrucción)

cr0x@server:~$ echo check | sudo tee /sys/block/md0/md/sync_action
check
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid10]
md0 : active raid1 sdb1[2] sda1[0]
      976630336 blocks super 1.2 [2/2] [UU]
      [==>.................]  check = 11.6% (113246208/976630336) finish=45.2min speed=317120K/sec

unused devices: <none>

Qué significa: Esto lee y compara espejos. En RAID5/6, check lee paridad; puede sacar a la luz errores latentes.

Decisión: Si el conteo de mismatches sube (ver tarea siguiente), investiga la causa. Unos pocos mismatches tras un apagado no limpio pueden ocurrir; mismatches persistentes o crecientes significan problema.

Tarea 16: Leer contadores de mismatch (y decidir si “repair”)

cr0x@server:~$ cat /sys/block/md0/md/mismatch_cnt
0

Qué significa: Cero mismatches es lo que quieres. En RAID5/6, los mismatches pueden indicar write hole, RAM/controladora defectuosa, o un disco/controlador que miente bajo carga.

Decisión: No ejecutes repair por reflejo. Repair escribe correcciones—úsalo solo cuando sepas cuál lado es el correcto (a menudo: después de validar hardware y tener copias de seguridad).

Listas de verificación / plan paso a paso (reemplazo seguro de disco)

Aquí hay un plan que funciona bajo presión. Es deliberadamente aburrido. Aburrido es bueno; aburrido mantiene tus datos.

Checklist A: Antes de tocar nada

Confirma que las copias de seguridad son reales. No “tenemos snapshots.” Recuperación real y probada para los datos en este array.
Captura el estado actual: /proc/mdstat, mdadm --detail, lsblk, logs recientes del kernel.
Identifica la ruta fallida por serial/WWN. Escríbelo. Haz una foto de la etiqueta del chasis si es físico.
Comprueba si el array ya está resyncing. Si lo está, tu intervención puede ralentizarlo o desestabilizarlo.
Fija expectativas. En RAID5/6, el tiempo de reconstrucción bajo carga no es el número del folleto del proveedor.

Checklist B: Si el disco aún es visible pero está “faulty”

Si md marcó un miembro como faulty pero el kernel aun muestra el dispositivo, elimínalo limpiamente. Eso evita que md siga intentando hablar con un disco que ya se porta mal.

cr0x@server:~$ sudo mdadm --detail /dev/md0 | egrep "faulty|removed|active"
      RaidDevice State
      active sync   /dev/sda1
      removed
cr0x@server:~$ sudo mdadm /dev/md0 --fail /dev/sdb1
mdadm: set /dev/sdb1 faulty in /dev/md0
cr0x@server:~$ sudo mdadm /dev/md0 --remove /dev/sdb1
mdadm: hot removed /dev/sdb1 from /dev/md0

Interpretación: Marcar como faulty y luego remover crea una ranura limpia. También evita lecturas parciales aleatorias desde un disco moribundo.

Decisión: Si la remoción falla porque el dispositivo desapareció, perfecto—continúa con el reemplazo. Si falla porque está “ocupado”, detente y vuelve a comprobar que apuntaste al miembro correcto.

Checklist C: Preparar correctamente el disco de reemplazo

Hay dos reglas grandes: igualar el layout de particiones, y asegurar que no sobreviva metadata RAID antigua.

Particiónalo para que coincida con el miembro existente. Usa clonación con sfdisk, no edición manual.
Borra superbloques md antiguos si existen. Usa mdadm --zero-superblock en las particiones miembro, no en el disco entero si puedes evitarlo.
Comprueba tamaños de sector. Un disco 4Kn intercambiado en un array 512e puede ser un lío de compatibilidad según controladoras y particionado.

cr0x@server:~$ sudo mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 1.2
           UUID : 11111111:22222222:33333333:44444444
     Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing)
cr0x@server:~$ sudo mdadm --zero-superblock /dev/sdb1
mdadm: Unrecognised md component device - /dev/sdb1
cr0x@server:~$ sudo wipefs -n /dev/sdb1
offset               type
0x00000400           linux_raid_member   [raid]

Interpretación: El ejemplo muestra señales contradictorias que verás en la vida real: metadata obsoleta y herramientas en desacuerdo cuando los dispositivos están medio inicializados.
Si wipefs -n muestra linux_raid_member, necesitas eliminarlo antes de añadirlo al nuevo array.

Decisión: Usa wipefs para borrar la firma, luego re-verifica con mdadm --examine para asegurarte de que realmente se fue.

cr0x@server:~$ sudo wipefs -a /dev/sdb1
/dev/sdb1: 8 bytes were erased at offset 0x00000400 (linux_raid_member): a9 2b 4e fc 00 00 00 00
cr0x@server:~$ sudo mdadm --examine /dev/sdb1
mdadm: No md superblock detected on /dev/sdb1.

Checklist D: Añadir el disco y controlar el impacto de la reconstrucción

Las reconstrucciones consumen mucha I/O. Puedes cambiar velocidad por seguridad (menos carga) o velocidad por riesgo (darle caña).
En producción, me inclino por “terminar de forma fiable”, no “terminar rápido y quizá morir a mitad”.

cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_min
1000
cr0x@server:~$ cat /proc/sys/dev/raid/speed_limit_max
200000
cr0x@server:~$ echo 50000 | sudo tee /proc/sys/dev/raid/speed_limit_max
50000

Interpretación: Estos son límites en KiB/s. Limitar la velocidad máxima puede mantener la latencia aceptable para clientes y reducir estrés térmico. Alargará el tiempo de reconstrucción.

Decisión: Si esto es una máquina de base de datos sirviendo producción, limita la velocidad y sobrevive. Si es una ventana de mantenimiento, abre el acelerador.

cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdb1
mdadm: added /dev/sdb1

Checklist E: Después de la reconstrucción, endurece para no repetir esto la próxima semana

Actualiza mdadm.conf y regenera initramfs.
Ejecuta un check y revisa conteos de mismatch.
Arregla la causa raíz: reemplaza cable/backplane, actualiza firmware, ajusta monitorización.
Configura alerta para eventos md y advertencias SMART.

cr0x@server:~$ sudo systemctl enable --now mdadm --quiet || true
cr0x@server:~$ sudo systemctl status mdadm --no-pager
● mdadm.service - MD array assembly and monitoring
     Loaded: loaded (/lib/systemd/system/mdadm.service; enabled; preset: enabled)
     Active: active (exited) since Mon 2025-12-29 09:30:14 UTC; 2min ago

Interpretación: En Debian, el comportamiento del servicio puede ser “active (exited)” y aun así ser correcto; arma y delega la monitorización a otras unidades/config.

Decisión: Confirma que tienes alertas reales (email, exportador Prometheus, lo que use tu stack). “Enabled” sin receptor es teatro.

Casos especiales: RAID1 vs RAID5/6 vs RAID10, bitmaps y reshape

RAID1: la reconstrucción más fácil, y por eso la gente se descuida

Las reconstrucciones en RAID1 son sencillas: md copia bloques del disco bueno al nuevo. Tu mayor riesgo es humano:
reemplazar el disco equivocado o reconstruir desde el lado equivocado en una situación de split-brain (raro en un único host, pero ocurre tras
resets de controladora extraños y reboots en pánico).

Un array RAID1 puede estar clean, degraded y aún consistente. No confundas “degradado” con “sucio”.
La reconstrucción debería ser segura mientras el disco restante esté sano.

RAID5/6: degradado significa que cada lectura es un trabajo en equipo

Con RAID de paridad, un único disco ausente significa reconstrucción en lecturas (o lecturas por todos los discos restantes) y mucha I/O.
Durante la reconstrucción estás forzando a cada disco superviviente—justo en el momento en que descubres cuáles estaban al límite.

Implicaciones prácticas:

La cadencia de scrubs importa. Si nunca haces scrubs, encontrarás errores latentes durante la reconstrucción. Ese es el peor momento.
El rendimiento fluctúa. Espera picos de latencia. Planea limitación de reconstrucción.
Tener una condición de parada. Si un segundo disco comienza a fallar durante la reconstrucción de RAID5, detente y reevalúa. Continuar puede destruir lo que queda.

RAID10: las reconstrucciones son localizadas, pero no te confíes

RAID10 reconstruye pares espejo. Eso suele ser más rápido y menos estresante que RAID5/6, pero no es magia.
Si pierdes un disco de un par y el compañero espejo sobreviviente es viejo, la reconstrucción leerá todo el compañero—otra vez, estrés.

Bitmaps: tu amigo tras un apagado no limpio

Los bitmaps internos registran qué regiones pueden estar fuera de sincronía, permitiendo un resync más rápido. Si tus arrays son grandes y tus apagados no son
perfectamente limpios (eventos de energía ocurren, la gente ocurre), los bitmaps pueden ahorrar horas.

Pero los bitmaps no son gratis: añaden overhead de escritura y complejidad. En la práctica, para la mayoría de arrays de producción donde importa la disponibilidad,
sigo prefiriéndolos.

Reshape: no lo hagas mientras estés degradado a menos que disfrutes el suspense

mdadm puede reshapear arrays: cambiar nivel RAID, añadir discos, cambiar tamaño de chunk, etc. Es potente.
También es el tipo de operación donde “casi correcto” no es suficiente.

Regla: Restaura la redundancia primero, luego reshapea. Si ya estás degradado, el reshape aumenta las piezas en movimiento y la superficie de fallo.

Tres micro-historias corporativas desde el campo

Micro-historia 1: El incidente causado por una suposición equivocada

Una compañía SaaS mediana ejecutaba servidores Debian con mdadm RAID1 para arranque y RAID10 para datos. Un nodo marcó RAID1 degradado en md0.
El ingeniero on-call vio que /dev/sdb faltaba y asumió “disco 2 muerto,” porque esa es la historia que nos contamos:
Linux nombra discos en un orden amable y el universo es bondadoso.

Cambiaron el disco en la bahía 2, arrancaron, y el array seguía mal. Frustrados, “lo arreglaron” añadiendo el “disco nuevo”
al array y dejándolo reconstruir. La máquina volvió limpia. Todos respiraron.

Dos días después, un reinicio planificado ocurrió. El sistema cayó en initramfs quejándose de que no podía ensamblar root.
¿Qué cambió? La enumeración. Una actualización de firmware y un orden de descubrimiento ligeramente distinto intercambiaron /dev/sda y /dev/sdb.
El disco que se reconstruyó no era el que todos pensaban. El array no se ensambló consistentemente porque mdadm.conf no se actualizó e initramfs seguía con pistas obsoletas.

La recuperación no fue heroica; fue cuidadosa. Arrancaron con medios de rescate, ensamblaron por UUID, confirmaron qué miembro tenía el último contador de eventos,
y reconstruyeron el espejo correcto. La lección real no fue “Linux es aleatorio.” La lección fue: /dev/sdX no es una identidad.

Después de eso, etiquetaron bahías con números de serie y actualizaron su runbook: toda operación de disco empieza con /dev/disk/by-id,
y todo cambio de mdadm termina con update-initramfs -u.

Micro-historia 2: La optimización que salió mal

Otra organización tenía una carga analítica pesada y quería que las reconstrucciones terminaran más rápido. Alguien encontró los límites de velocidad md y subió
speed_limit_max a un número grande en toda la flota. En la siguiente falla, la reconstrucción fue a todo gas.
El dashboard se veía genial. El tiempo a redundancia cayó. High fives en el canal.

Pero durante horario laboral, la latencia también se disparó. No poco. La reconstrucción compitió con lecturas de producción, saturó la cola HBA,
y elevó la temperatura del dispositivo. Uno de los discos “sanos” comenzó a registrar errores UDMA CRC—signo clásico de enlace marginal.
Luego empezó a hacer timeouts bajo carga. md lo expulsó. En RAID6 eso se tolera; en RAID5 no.

Lo peor: no fue ni siquiera un problema de disco al principio. El cable había estado ligeramente flojo durante meses, pero nada lo estresó lo suficiente como para mostrar síntomas.
La reconstrucción convirtió un problema latente en una interrupción.

Revirtieron la “optimización” global y reemplazaron el cableado cuestionable. La mejor optimización fue política:
las reconstrucciones van más lentas en horas punta, más rápidas en ventanas de mantenimiento. Los sistemas reales tienen clientes conectados.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de servicios financieros ejecutaba mdadm RAID6 en un conjunto de discos nearline. Tenían dos hábitos que nadie celebraba:
comprobaciones RAID mensuales y un procedimiento estricto de reemplazo con verificación por número de serie.

Un viernes por la noche, un disco falló. Lo reemplazaron y comenzaron la reconstrucción. A mitad de camino, un segundo disco devolvió un error de lectura en un sector.
Ese es el momento en que RAID6 demuestra su valor: puede tolerar dos fallos, pero solo si el segundo no escala.

Como hacían checks mensuales, el equipo ya sabía que los conteos de mismatch eran estables y que ningún otro disco estaba lanzando sectores pendientes.
También tenían baselines SMART recientes. El error del segundo disco era nuevo y aislado; redujeron la velocidad de reconstrucción y la dejaron terminar.
Luego programaron el reemplazo controlado del segundo disco en la siguiente ventana.

Sin pérdida de datos. Sin fin de semana. Sin drama. La razón por la que funcionó es dolorosamente poco sexy:
no descubrieron sus errores de medio por primera vez durante una reconstrucción.

Cita (idea parafraseada) de la almirante Grace Hopper: “La frase más peligrosa es ‘siempre lo hemos hecho así’.” Aplicado al almacenamiento: verifica, no heredes.

Errores comunes (síntomas → causa raíz → solución)

1) Síntoma: El array está degradado tras reiniciar; los discos parecen “bien”

Causa raíz: mdadm.conf/initramfs no incluye definiciones ARRAY correctas; el ensamblado depende de escaneo y timing.

Solución: Regenera configuración e initramfs después de estabilizar.

cr0x@server:~$ sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
ARRAY /dev/md0 metadata=1.2 UUID=3b0d0f3b:5f2e6d7a:8c6c9b9b:9dd5a1d2 name=server:0
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

2) Síntoma: Añades un disco y mdadm dice “device has wrong UUID” o se niega a añadirlo

Causa raíz: El disco de reemplazo aún tiene superblock md antiguo o firmas de sistema de archivos (común con repuestos reutilizados).

Solución: Borra firmas en la partición miembro específica y luego añade.

cr0x@server:~$ sudo wipefs -n /dev/sdb1
offset               type
0x00000400           linux_raid_member   [raid]
cr0x@server:~$ sudo wipefs -a /dev/sdb1
/dev/sdb1: 8 bytes were erased at offset 0x00000400 (linux_raid_member): a9 2b 4e fc 00 00 00 00
cr0x@server:~$ sudo mdadm --add /dev/md0 /dev/sdb1
mdadm: added /dev/sdb1

3) Síntoma: La reconstrucción es extremadamente lenta y la latencia del sistema es terrible

Causa raíz: La reconstrucción satura I/O; el scheduler/profundidad de cola interactúa mal con la carga; errores de dispositivo provocan reintentos.

Solución: Limita la velocidad de reconstrucción; reduce la carga; revisa logs por reintentos/timeouts.

cr0x@server:~$ echo 20000 | sudo tee /proc/sys/dev/raid/speed_limit_max
20000
cr0x@server:~$ sudo journalctl -k -b | grep -E 'reset|timeout|I/O error' | tail -n 20
Dec 29 09:12:04 server kernel: blk_update_request: I/O error, dev sdc, sector 1234567 op 0x0:(READ)

4) Síntoma: La reconstrucción RAID5 falla con “read error” en otro disco

Causa raíz: Sector malo latente encontrado durante la reconstrucción; RAID5 no puede tolerar un segundo fallo o error de lectura irrecuperable.

Solución: Detén y evalúa: intenta remapear sector leyendo la región ofensora; considera clonar; restaura desde backup si es necesario.

Habla real: RAID5 no es una copia de seguridad, y durante la reconstrucción no es ni siquiera una historia de redundancia especialmente convincente. Trata esto como un incidente, no una advertencia.

5) Síntoma: El array muestra “clean” pero el conteo de mismatch sube durante el check

Causa raíz: Apagado no limpio previo, write hole (RAID5), RAM/controladora inestable, o corrupción silenciosa previamente enmascarada.

Solución: Investiga hardware, ejecuta pruebas de memoria, verifica cableado, y solo entonces considera repair con backups disponibles.

cr0x@server:~$ cat /sys/block/md0/md/mismatch_cnt
12

6) Síntoma: El disco sigue siendo expulsado, pero SMART parece bien

Causa raíz: Problemas a nivel de enlace (errores CRC), resets de controladora, fallos en backplane, problemas de alimentación.

Solución: Reemplaza cable/bahía de backplane; revisa alimentación; analiza logs del kernel por resets. No sigas intercambiando discos “buenos” en una ranura mala.

7) Síntoma: No puedes saber qué disco físico es /dev/sdb

Causa raíz: Sin etiquetado, sin mapeo de bahía del chasis, y deriva de nombres de dispositivos entre reinicios.

Solución: Usa by-id seriales, propiedades udev, y (si existe) herramientas de gestión de chasis; luego etiqueta el hardware.

Chiste #2: Lo único más frágil que un RAID5 degradado es la confianza de alguien que acaba de teclear --force.

Preguntas frecuentes

1) ¿Puedo mantener el servidor en funcionamiento mientras se reconstruye?

Normalmente sí. mdadm está diseñado para reconstrucciones online. El intercambio es rendimiento y riesgo: la carga de reconstrucción puede exponer problemas latentes.
Si es tu array root, online suele ser la única opción práctica sin tiempo de inactividad.

2) ¿Debería reemplazar el disco inmediatamente o intentar reseatarlo primero?

Si los logs muestran resets de enlace/errores CRC y el dispositivo desaparece/aparece, reseata y revisa cableado/backplane primero.
Si SMART muestra errores de medio/integridad o sectores realocados/pendientes (según el tipo de dispositivo), reemplaza el disco.

3) ¿Cómo sé qué disco sacar en un chasis hot-swap?

Usa seriales en /dev/disk/by-id y compáralos con las etiquetas de las unidades. Si tienes mapeo de bahías (SAS expanders),
úsalo. No confíes en /dev/sdX.

4) ¿Cuál es la forma más segura de particionar el disco nuevo?

Clona la tabla de particiones de un miembro conocido bueno usando sfdisk -d piped a sfdisk.
Luego verifica con lsblk y solo entonces añade al md.

5) mdadm dice que el array está “clean, degraded.” ¿Es eso malo?

Es mejor que “dirty, degraded,” pero aun así no tienes redundancia. Un segundo problema de disco puede provocar pérdida de datos según el nivel RAID.
Trátalo como urgente, no necesariamente pánico.

6) ¿Debería ejecutar `sync_action=repair` después de una reconstrucción?

No por defecto. Repair escribe cambios. Si tienes mismatches, primero determina si son esperados (apagado no limpio) o sintomáticos
(hardware/firmware). Ten backups antes de permitir cualquier “repair” a nivel de bloque.

7) ¿Por qué la reconstrucción tardó tanto comparado con la velocidad nominal del disco?

La velocidad de reconstrucción está limitada por I/O aleatoria, actividad del sistema de archivos, límites de la controladora, reintentos por errores, throttling térmico, y límites de md.
Los números secuenciales de marketing del proveedor no son tu carga de trabajo.

8) ¿Necesito actualizar initramfs después de reemplazar un miembro RAID?

Si el array participa en el arranque (root, /boot), sí. Actualiza /etc/mdadm/mdadm.conf y ejecuta update-initramfs -u.
De lo contrario, arriesgas fallo de arranque o un ensamblado inconsistente del array.

9) ¿Qué pasa si reemplacé el disco equivocado?

Detén. No añadas nada. Identifica los discos restantes por serial, examina superbloques, y determina qué miembro tiene el último contador de eventos.
Si no estás seguro, arranca medios de rescate y ensambla por UUID. Adivinar es como convertir “recuperable” en “desarrollo de carrera”.

10) ¿Es mdadm RAID “seguro” comparado con RAID por hardware?

mdadm es perfectamente viable en producción cuando se opera correctamente: monitorización, recuperación probada, y procedimientos disciplinados.
RAID por hardware puede ocultar problemas hasta que no puede más. RAID por software es honesto, lo cual es incómodo pero útil.

Conclusión: qué hacer a continuación

Un RAID mdadm degradado en Debian 13 es solucionable sin drama si te abstienes de pulsar botones de pánico y sigues una secuencia estricta:
identifica el disco correcto por identidad estable, valida el modo de fallo, reemplaza limpiamente, reconstruye con carga controlada y luego verifica la consistencia.

Próximos pasos que deberías realmente hacer (no solo asentir):

Configurar monitorización de eventos mdadm para que “degradado” sea una página, no un descubrimiento arqueológico.
Programar ejecuciones periódicas de check y rastrear conteos de mismatch con el tiempo.
Etiquetar discos por serial y documentar el mapeo de bahías. El tú del futuro le deberá un café al tú del presente.
Tras cualquier trabajo en discos que afecte arrays de arranque: actualizar mdadm.conf y regenerar initramfs.