ZFS Reemplazo de múltiples discos: el orden seguro que previene fallos

El modelo mental: qué significa realmente “orden seguro”

Reemplazar múltiples discos en ZFS de forma segura tiene menos que ver con qué bahía abres primero y más con el presupuesto de redundancia que gastas mientras lo haces.

En un mirror, tu redundancia es simple: un disco puede fallar y sigues funcionando. Durante un reemplazo, sacas intencionalmente un disco y pides al disco superviviente que haga todas las lecturas mientras además alimenta el resilver. No solo has reducido la redundancia; has aumentado la carga en los miembros restantes. Es entonces cuando “el otro disco estaba bien ayer” se convierte en “el otro disco ahora lanza errores de lectura”. Eso no es ZFS siendo dramático. Es física y probabilidad.

En RAIDZ (RAIDZ1/2/3), el presupuesto de redundancia está distribuido. Puedes perder 1, 2 o 3 dispositivos en un vdev y aún leer datos (según el nivel). Pero no puedes gastar ese presupuesto a la ligera: cada dispositivo degradado adicional incrementa tanto el riesgo de un error de lectura no corregible como el tiempo que estás sin margen. Y si reemplazas múltiples discos, es fácil ejecutar por accidente dos operaciones que se solapan en el mismo vdev. Ese es el clásico fallo “no pensé que esos reemplazos se solaparían”.

Entonces, “orden seguro” significa:

• Un vdev a la vez cuando sea posible, y nunca múltiples dispositivos degradados en el mismo vdev a menos que ya estés en modo de emergencia.
• Espera a que el resilver termine y se estabilice antes de proceder al siguiente disco en ese vdev.
• Usa identificadores persistentes de dispositivo (by-id/by-path) para que reemplaces el disco que crees que estás reemplazando.
• Valida la redundancia y la salud antes y después de cada paso con comandos que digan la verdad.

Una cita para mantenerte honesto: “La esperanza no es una estrategia”, comúnmente atribuida a ingenieros y operadores; trátala como una idea parafraseada de la cultura de fiabilidad.

Broma #1: Un resilver es como una membresía de gimnasio: fácil de empezar, difícil de terminar, y se vuelve muy caro si lo ignoras.

Datos interesantes y contexto histórico (breve, útil)

1. ZFS nació en Sun Microsystems a mediados de los 2000 para acabar con la división “sistema de archivos vs gestor de volúmenes” y hacer el almacenamiento más consistente.
2. Copy-on-write (CoW) significa que ZFS nunca sobrescribe bloques vivos; escribe bloques nuevos y cambia punteros. Por eso una pérdida de energía a mitad de una escritura no corrompe las estructuras de datos existentes como podrían hacerlo pilas antiguas.
3. “Resilver” es el término de ZFS para la reconstrucción tras el reemplazo de un dispositivo; no siempre es una reconstrucción completa porque ZFS a menudo puede reconstruir solo los datos asignados (especialmente con el comportamiento secuencial de resilver más nuevo).
4. RAIDZ no es “solo RAID-5/6”; ZFS usa ancho de franja variable e integra sumas de comprobación y autocuración, cambiando el comportamiento ante fallos por errores de lectura.
5. La realidad de sectores 4K afectó muchas implementaciones tempranas de ZFS; ajustes de ashift incorrectos causaron amplificación de escrituras y resilvers lentos que parecían “ZFS es lento”. No lo era. La configuración lo era.
6. El “recordsize 1MB” por defecto (para algunas cargas) es un compromiso de rendimiento; los registros grandes son excelentes para IO secuencial pero pueden incrementar costos de read/modify/write para actualizaciones aleatorias pequeñas en RAIDZ.
7. El crecimiento de la capacidad de los discos cambió el riesgo de reconstrucción; discos más grandes significan resilvers más largos, lo que incrementa el tiempo de exposición mientras estás degradado. Eso es riesgo operativo, no teórico.
8. El nombrado persistente de dispositivos se volvió una habilidad de supervivencia; el renumerado de /dev/sdX en Linux tras reinicios causó suficientes incidentes como para que “usar siempre /dev/disk/by-id” sea ahora ley tribal.

Prevuelo: decide si deberías empezar hoy

El reemplazo de discos no es un “mantenimiento rápido” si cualquiera de estos es cierto:

• El pool ya está degradado y sirve tráfico crítico.
• La velocidad de resilver históricamente es lenta en este sistema (pool ocupado, discos SMR, o HBA saturado).
• Estás cerca de la capacidad (alta fragmentación y falta de espacio libre empeoran todo).
• No puedes identificar discos de forma fiable (no hay mapeo de serial a bahía).
• No tienes un scrub reciente con resultados limpios.

Sé aburrido. Programa una ventana. Asegura acceso a la consola. Si es producción, quiere una vía de escape: reducir carga, modo mantenimiento, o la capacidad de fallar el tráfico a otro lugar.

Principios centrales: reglas que sigues incluso bajo presión

1) Reemplaza discos secuencialmente dentro de un vdev

No “paralelicen” reemplazos en el mismo vdev RAIDZ o mirror. ZFS puede manejarlo en algunos casos, pero estás convirtiendo una operación controlada en una carrera entre la finalización del resilver y la siguiente falla.

2) Prefiere explícito zpool replace sobre “desconectar y rezar”

Intercambiar físicamente un disco y esperar que ZFS “lo resuelva” es un método. Simplemente no es un buen método. Usa zpool replace con identificadores estables. Valida.

3) No borres errores para sentirte mejor

zpool clear es para limpiar un error transitorio conocido después de arreglar la causa. Usarlo como soporte emocional oculta evidencia que necesitas para tomar buenas decisiones.

4) Cada paso es: observar → actuar → observar

Antes de cada disco: verifica la salud. Después de cada comando: verifica el estado. Después de cada resilver: verifica errores y ejecuta un scrub cuando corresponda.

5) Entiende qué significa “seguro” para tu topología

Un mirror de 2 vías tolera una falla. Un vdev RAIDZ2 tolera la pérdida de dos dispositivos pero puede morir por errores de lectura durante el resilver si los discos supervivientes no pueden entregar datos correctos para la reconstrucción.

Tareas prácticas (comandos, salidas y decisiones)

Estos son movimientos reales de operador: comando, salida de ejemplo, lo que significa y qué haces a continuación. Asume el nombre del pool tank. Adapta nombres a tu entorno.

Task 1: Confirmar la salud actual del pool y localizar el dispositivo dañado

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device or use 'zpool clear' to clear the error.
  scan: scrub repaired 0B in 03:12:10 with 0 errors on Wed Dec 18 02:12:11 2025
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  FAULTED     12     0     0  too many errors
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/data/dbfile.dat

Qué significa: El pool está degradado; un dispositivo by-id específico está faulted con errores de lectura. Hay errores permanentes, lo que significa que los datos fueron corrompidos o no se pudieron reconstruir en algún momento.

Decisión: Detente y evalúa el impacto. Si ves errores permanentes, decide si restaurar los archivos afectados desde copia de seguridad antes de proceder. Reemplazar el disco no arreglará mágicamente datos de aplicación ya corruptos.

Task 2: Confirmar la topología y el nivel de redundancia

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: scrub repaired 0B in 03:12:10 with 0 errors on Wed Dec 18 02:12:11 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2-0  DEGRADED     0     0     0
            ...

Qué significa: Este es un vdev RAIDZ2. Puedes sobrevivir otra falla más en este vdev, pero no puedes ser descuidado.

Decisión: Reemplaza un disco, espera la finalización completa del resilver, verifica y luego procede. No hagas lotes.

Task 3: Mapear el dispositivo by-id a una bahía física/serial

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep S3ZABC123456 | head
lrwxrwxrwx 1 root root  9 Dec 26 08:11 ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456 -> ../../sdf
lrwxrwxrwx 1 root root 10 Dec 26 08:11 ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456-part1 -> ../../sdf1

Qué significa: El disco que falla es actualmente /dev/sdf. Eso puede cambiar después de reinicios; el nombre by-id es tu ancla.

Decisión: Usa identificadores by-id en todos los comandos de ZFS. Usa el serial para localizar la bahía (vía LEDs del chasis, gestión del HBA o tu runbook del DC).

Task 4: Comprobar SMART antes de tocar nada

cr0x@server:~$ sudo smartctl -a /dev/sdf | egrep "SMART overall-health|Reallocated_Sector_Ct|Media_Wearout_Indicator|UDMA_CRC_Error_Count"
SMART overall-health self-assessment test result: FAILED!
  5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always       -       9812
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0

Qué significa: El disco está realmente fallando (reubicaciones masivas). Los errores CRC son cero, así que no es solo un problema de cableado.

Decisión: Reemplaza el disco. Si fueran solo errores CRC, revisarías cableado/backplane primero y evitarías churn innecesario de discos.

Task 5: Verificar espacio libre del pool y riesgo de fragmentación

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,mountpoint -r tank | head
NAME         USED  AVAIL  REFER  MOUNTPOINT
tank         68.1T  3.2T   128K  /tank
tank/data    66.9T  3.2T  66.9T  /tank/data
tank/logs    1.2T   3.2T  1.2T   /tank/logs

Qué significa: Solo ~3.2T libres en un pool de ~71T. Eso está justo. El rendimiento de resilver y scrub puede degradarse; la asignación se complica.

Decisión: Si puedes, libera espacio antes de empezar. Si no puedes, acepta que el resilver tomará más tiempo y la ventana de exposición crecerá.

Task 6: Verificar el último scrub y decidir si hacer uno antes

cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
  scan: scrub repaired 0B in 03:12:10 with 0 errors on Wed Dec 18 02:12:11 2025

Qué significa: Un scrub se ejecutó recientemente y no encontró errores. Bien: tienes evidencia reciente de que la redundancia funcionó.

Decisión: Procede con el reemplazo. Si el último scrub es antiguo o tuvo errores, quizá hagas un scrub primero (si el pool no está demasiado frágil) para sacar a la luz problemas latentes antes de estresarlo con un resilver.

Task 7: Poner el dispositivo OFFLINE (cuando quieras una extracción controlada)

cr0x@server:~$ sudo zpool offline tank ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456
cr0x@server:~$ sudo zpool status tank | grep -A2 S3ZABC123456
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456  OFFLINE      0     0     0

Qué significa: Le has dicho a ZFS “este disco está intencionalmente fuera”. Esto evita confusión si el disco desaparece a mitad de IO.

Decisión: Ponlo OFFLINE antes de retirarlo físicamente a menos que estés en un escenario de hot-swap forzado y el disco ya haya desaparecido.

Task 8: Reemplazar el disco usando identificadores persistentes

cr0x@server:~$ sudo zpool replace tank ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456 ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654
cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Fri Dec 26 08:33:02 2025
        2.11T scanned at 1.35G/s, 410G issued at 262M/s, 68.1T total
        410G resilvered, 0.59% done, 3 days 02:11:22 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ...
            replacing-2                           DEGRADED     0     0     0
              ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZABC123456  OFFLINE      0     0     0
              ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654  ONLINE       0     0     0  (resilvering)

Qué significa: ZFS creó un vdev replacing y empezó a resilverizar hacia el nuevo dispositivo. ETA es largo: ese es el tiempo de exposición.

Decisión: No toques otro disco en este vdev hasta que este resilver termine y el pool vuelva a estar ONLINE (o al menos el vdev vuelva a la redundancia completa).

Task 9: Monitorear progreso del resilver y vigilar errores de lectura

cr0x@server:~$ watch -n 10 sudo zpool status tank
Every 10.0s: sudo zpool status tank

  pool: tank
 state: DEGRADED
  scan: resilver in progress since Fri Dec 26 08:33:02 2025
        9.82T scanned at 1.12G/s, 1.84T issued at 214M/s, 68.1T total
        1.84T resilvered, 2.70% done, 2 days 20:05:13 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ...
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZOLD111222  ONLINE      18     0     0

Qué significa: Uno de los discos restantes ahora muestra errores de lectura. Esa es tu advertencia temprana de que el estrés del resilver está revelando debilidades.

Decisión: Pausa cargas no esenciales, reduce IO, y considera planificar reemplazo proactivo. Si los errores aumentan o otro disco se degrada, puede que necesites detenerte y pasar a respuesta de emergencia (backups, replicación, preparación de restauración).

Task 10: Revisar logs del kernel por resets de enlace y errores de transporte

cr0x@server:~$ sudo dmesg -T | egrep -i "ata[0-9]+:|link reset|I/O error|blk_update_request" | tail -n 12
[Fri Dec 26 09:01:12 2025] ata9.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
[Fri Dec 26 09:01:12 2025] ata9.00: failed command: READ FPDMA QUEUED
[Fri Dec 26 09:01:13 2025] ata9: hard resetting link
[Fri Dec 26 09:01:18 2025] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Fri Dec 26 09:01:19 2025] blk_update_request: I/O error, dev sdi, sector 1293849216 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0

Qué significa: El SO está viendo resets de enlace y errores de IO de lectura en un disco específico. Esto podría ser un disco fallando, o podría ser cableado/backplane/HBA con problemas.

Decisión: Si los contadores CRC suben en SMART y los logs muestran resets de enlace, revisa la conectividad física antes de declarar el disco muerto.

Task 11: Confirmar expectativas de ashift / alineación de sectores del disco nuevo (chequeo de sanity)

cr0x@server:~$ sudo zdb -C tank | egrep -n "ashift|vdev_tree" | head -n 8
40: vdev_tree:
56:         ashift: 12
57:         asize:  12003003719680

Qué significa: ashift: 12 implica sectores de 4K (2^12). Bueno para discos modernos. Si de alguna forma tuvieras ashift: 9 con discos 4K, el rendimiento sería doloroso y los resilvers serían más lentos.

Decisión: Si ashift está mal, no lo “arregles” reemplazando discos; ashift se fija por vdev al crear. Arreglarlo requiere recrear/migrar el vdev. Planifícalo, no improvises.

Task 12: Cuando el resilver termine, verificar que el pool esté sano y sin errores

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: resilvered 68.1T in 2 days 21:44:02 with 0 errors on Mon Dec 29 06:17:04 2025
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          raidz2-0                                ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3Z...  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654  ONLINE       0     0     0
            ...

Qué significa: El pool está ONLINE, el resilver finalizó y los errores son cero. Este es el estado que quieres antes de pasar al siguiente reemplazo de disco.

Decisión: Solo ahora procede al siguiente dispositivo. Si estás rotando un lote, reemplaza el siguiente disco en el mismo vdev uno por uno con finalización completa entre ellos.

Task 13: Iniciar un scrub después de un ciclo de reemplazos (paso de validación)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | sed -n '1,10p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 29 06:22:11 2025
        1.14T scanned at 992M/s, 12.3G issued at 10.7M/s, 68.1T total
        0B repaired, 0.01% done, 19:05:41 to go

Qué significa: El scrub está en ejecución. Observa la diferencia entre tasa de scan y tasa emitida; la tasa emitida refleja IO real realizado.

Decisión: Déjalo terminar. Si el scrub saca a la luz errores, trátalos como evidencia de un problema más amplio (otro disco débil, controlador, cableado o corrupción latente).

Task 14: Usar zpool events para ver lo que realmente pasó

cr0x@server:~$ sudo zpool events -v | tail -n 20
TIME                           CLASS
Dec 29 2025 06:17:04.123456789  resilver.finish
    pool = tank
    vdev_path = /dev/disk/by-id/ata-SAMSUNG_MZ7LM1T9HMLP-00003_S3ZNEW987654
    resilvered_bytes = 74882345013248
Dec 29 2025 06:22:11.987654321  scrub.start
    pool = tank

Qué significa: Tienes una línea de tiempo auditable. Esto importa cuando alguien pregunta “¿cuándo empezamos a estresar el pool?”

Decisión: Guarda esta salida en tu ticket de cambio. El tú del futuro agradece la evidencia.

Orden seguro según la topología del vdev

Mirrors (2-way, 3-way)

Regla de orden: reemplaza una hoja a la vez, espera la finalización del resilver, luego pasa al siguiente mirror. Si tienes muchos mirrors (común en “striped mirrors”), puedes reemplazar un disco por mirror de forma secuencial, pero no degrades múltiples mirrors simultáneamente a menos que puedas tolerar reducción de redundancia en todo el pool.

Por qué: Cuando falta un miembro del mirror, el disco restante es tu punto único de falla para los datos de ese mirror. Además, ese disco superviviente ahora realiza todas las lecturas y alimenta la reconstrucción. Ese es el momento en que aparecen errores de lectura ocultos.

Orden recomendado:

1. Elige un vdev mirror.
2. Reemplaza el peor disco (SMART fallando, errores, o lote más antiguo).
3. Espera a que termine el resilver, verifica ONLINE, comprueba errores.
4. Opcionalmente, ejecuta un scrub después de un lote de reemplazos.
5. Pasa al siguiente vdev mirror.

RAIDZ1

Regla de orden: nunca tengas dos reemplazos concurrentes en el mismo vdev RAIDZ1. RAIDZ1 tiene un margen de seguridad delgado: un disco faltante está bien; una segunda falla significa desastre.

Realidad operativa: RAIDZ1 en discos grandes es un intercambio de riesgo. Si haces reemplazos múltiples en RAIDZ1, tu “orden seguro” es básicamente “un disco, resilver completo, verificar, repetir” — y deberías estar algo nervioso. Eso es saludable.

RAIDZ2 / RAIDZ3

Regla de orden: aún así haz reemplazos secuenciales dentro de un vdev. Sí, RAIDZ2 puede tolerar dos fallas, pero el resilver es cuando discos débiles se revelan y cuando tu tiempo medio hasta una segunda falla se reduce.

Orden recomendado:

1. Reemplaza primero cualquier disco que esté faulted o lance errores de lectura/escritura.
2. Luego reemplaza discos con indicadores SMART crecientes (reallocations, sectores pendientes, desgaste de medios).
3. Deja los discos “saludables pero antiguos” para el final, y detente si observas nuevos errores en los miembros supervivientes durante el resilver.

Vdevs especiales: SLOG, L2ARC, clase de asignación especial

Estos no son vdevs de datos de la misma manera, pero aún pueden arruinar tu día.

• SLOG (separate intent log): perderlo no pierde datos comprometidos, pero puede causar una caída de rendimiento y timeouts de clientes. Reemplázalo con cuidado, valida el comportamiento de cargas sync.
• L2ARC: es seguro de quitar/reemplazar desde el punto de vista de integridad de datos. Pero si lo quitas bajo carga, puedes desencadenar una tormenta de amplificación de lecturas cuando los datos calientes vuelvan a discos giratorios.
• Vdev especial: trátalo como datos. Perderlo puede ser catastrófico según la configuración, porque metadata y bloques pequeños pueden vivir allí. El orden de reemplazo es “nunca degradarlo más allá de su redundancia”, igual que mirrors/RAIDZ.

Broma #2: Hot-swapear el disco equivocado es una excelente manera de aprender cuánto confías en tus copias de seguridad.

Listas de verificación / plan paso a paso

Checklist A: antes de reemplazar cualquier disco (la lista “no seas listo”)

• Confirma la topología del pool y la redundancia por vdev (zpool status).
• Confirma resultados y fecha del último scrub (zpool status).
• Revisa espacio libre (zfs list) y planifica resilveres más largos si el espacio es ajustado.
• Recolecta línea base de rendimiento y contadores de error (SMART, dmesg para errores de enlace).
• Mapea dispositivo by-id a bahía/serial y etiqueta el disco físico que vas a extraer.
• Confirma que tienes acceso a consola/manos remotas si el host se reinicia o cuelga.
• Asegura que tienes un plan de rollback: reducir carga, failover o pausar ingestión.

Checklist B: ciclo de reemplazo de un disco (repetible, seguro)

1. Observar: zpool status -v e identifica el nombre exacto del leaf vdev a reemplazar.
2. Offline (opcional pero recomendado): zpool offline ese leaf.
3. Swap físico: retira/insertar el disco; confirma que el SO vea la nueva entrada by-id.
4. Reemplazar: zpool replace pool old-by-id new-by-id.
5. Monitorear: vigila zpool status para progreso y errores.
6. Validar: tras la finalización, asegura que el pool vuelva a ONLINE y que los errores sigan en cero.
7. Registrar: captura fragmentos de zpool events -v y SMART del disco nuevo (baseline).

Checklist C: reemplazando un lote entero (cuando varios discos son sospechosos)

Aquí es donde la gente se cree lista y ZFS les recuerda que es un sistema de archivos, no un terapeuta.

1. Ordena discos por urgencia: faulted > errores de lectura/escritura > SMART pre-fail > lote antiguo.
2. Reemplaza un disco a la vez por vdev.
3. Después de cada resilver, revisa SMART y contadores ZFS de los otros discos; el estrés cambia la verdad.
4. Después de 2–3 reemplazos (o tras cualquier incidente), ejecuta un scrub en una ventana controlada.
5. Si ves nuevos errores de lectura en supervivientes, detén el lote y reevalúa. “Terminar el calendario” no es un principio SRE.

Guion de diagnóstico rápido

Cuando un reemplazo de disco sale mal, necesitas responder una pregunta rápido: ¿estamos limitados por los discos, el controlador/enlaces, o la carga? Aquí está el orden que te lleva a una respuesta útil rápido.

1º: Verdad a nivel ZFS (estado del pool, errores, estado de scan/resilver)

• Revisar: zpool status -v
• Buscar: DEGRADED/FAULTED, contadores READ/WRITE/CKSUM crecientes, “too many errors,” y ETA de resilver que explota en vez de estabilizarse.
• Decisión: Si los errores aumentan en múltiples dispositivos del mismo vdev, para de hacer cambios y reduce IO. Prepárate para restaurar/replicar.

2º: Señales del SO de transporte y controlador (dmesg)

• Revisar: dmesg -T por resets de enlace, timeouts, “frozen,” “I/O error.”
• Buscar: resets repetidos en el mismo puerto/dispositivo, que a menudo implican cableado/backplane/firmware del HBA más que el disco.
• Decisión: Si múltiples discos en el mismo HBA muestran resets, pausa reemplazos y arregla la capa de transporte primero.

3º: Salud por disco y tipos de error (SMART)

• Revisar: smartctl -a por reubicaciones, sectores pendientes, contadores CRC, desgaste de medios.
• Buscar: CRC en aumento (cableado), realloc/pending en aumento (medio), o “FAILED” en overall health.
• Decisión: Reemplaza discos con problemas de medio. Arregla cableado/backplane para problemas CRC.

4º: Presión de la carga (¿se le está pidiendo demasiado al pool?)

• Revisar: patrones de IO activos: lecturas secuenciales grandes, escrituras aleatorias pequeñas, escrituras sync intensas.
• Buscar: tasa issued del resilver colapsando mientras la tasa de scan se mantiene alta; aplicaciones con timeouts; picos de latencia.
• Decisión: limitar o pausar IO no esencial. En casos extremos, detener ingestión, reprogramar reemplazos en lote o failover del tráfico.

Errores comunes: síntoma → causa raíz → solución

Error 1: “Reemplazamos el disco A, así que ahora podemos reemplazar el B inmediatamente.”

Síntoma: el pool pasa de DEGRADED a UNAVAIL durante el segundo reemplazo; el resilver nunca termina.

Causa raíz: estado degradado solapado en el mismo vdev (mirror/RAIDZ) redujo la redundancia por debajo de lo que el vdev tolera.

Solución: reemplaza un disco por vdev a la vez; espera la finalización del resilver y el estado ONLINE antes de proceder.

Error 2: El resilver es dolorosamente lento y la ETA sigue creciendo

Síntoma: “3 days remaining” se convierte en “9 days remaining”, el throughput emitido es bajo, las cargas hacen timeouts.

Causa raíz: el pool está casi lleno, alta fragmentación, IO concurrente elevado, discos SMR, o un controlador saturado.

Solución: reduce carga, libera espacio, programa reemplazos en baja carga, y valida que no estés mezclando discos SMR en un entorno con muchas reconstrucciones.

Error 3: El disco nuevo aparece como ONLINE pero el pool sigue reportando errores

Síntoma: zpool status muestra contadores READ/CKSUM no cero en discos supervivientes tras el resilver.

Causa raíz: errores de lectura latentes durante el resilver; problemas de transporte; o corrupción existente descubierta durante la reconstrucción.

Solución: revisa zpool status -v por errores permanentes, ejecuta un scrub, revisa SMART y dmesg. Si hay errores permanentes, restaura los datos afectados desde backup.

Error 4: “Usamos /dev/sdX porque era obvio.”

Síntoma: se reemplazó el disco equivocado; el disco malo previsto sigue en el pool; falta un disco sano.

Causa raíz: renumerado de dispositivos; /dev/sdX no es estable tras reinicios y eventos hotplug.

Solución: usa siempre /dev/disk/by-id o /dev/disk/by-path en comandos ZFS; confirma que el serial coincide con el disco físico.

Error 5: Borrar errores temprano para que el panel luzca bien

Síntoma: los errores desaparecen y luego reaparecen más tarde; no puedes probar cuándo empezó el problema.

Causa raíz: zpool clear borró los contadores sin arreglar el dispositivo o el enlace subyacente.

Solución: solo borra errores después de la acción correctiva y tras capturar evidencia (salida de status, SMART, logs).

Error 6: Reemplazar discos mientras un scrub está en ejecución

Síntoma: saturación de IO; resilver se ralentiza hasta quedar en cero; timeouts incrementados; impacto en clientes.

Causa raíz: scrub y resilver compiten por IO; ambos son intensivos en lecturas y estresan discos envejecidos.

Solución: no solaparlos a menos que tengas una razón muy concreta. Pausa el scrub si es posible; programa scrub después del resilver.

Error 7: Asumir que un “checksum error” significa que el disco está malo

Síntoma: CKSUM en aumento; discos se ven sanos en SMART.

Causa raíz: corrupción por cableado/backplane/controlador; errores DMA; problemas intermitentes de transporte.

Solución: inspecciona y vuelve a sentar cables, cambia puertos, actualiza firmware del HBA y observa contadores CRC en SMART.

Tres minihistorias del mundo corporativo

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

Tenían un pool striped-mirror que alimentaba una granja de builds y un almacén de artefactos. Nada exótico, solo mucho IO y una respetable cantidad de “lo limpiaremos después”. Un disco empezó a hacer flapping. Alguien hizo lo correcto y lo marcó para reemplazo.

La suposición equivocada fue simple: “Todos los mirrors son independientes, así que podemos reemplazar un disco en el mirror A y otro en el mirror B al mismo tiempo.” Suena razonable hasta que notas que la carga no es independiente. El almacén de artefactos estaba golpeando el pool, y los dos miembros restantes del mirror ahora hacían doble trabajo: servir lecturas y alimentar resilvers.

En horas, un segundo disco en uno de los mirrors empezó a reportar errores de lectura. No era nuevo, y no estaba contento de ser la última fuente de verdad para la mitad de los datos bajo máxima carga CI. El pool no murió instantáneamente; se degradó en cámara lenta, que es peor porque todos piensan que “solo terminamos la reconstrucción”.

La solución no fue ingeniosa: pausaron CI, drenaron colas y terminaron un resilver a la vez. Luego escribieron una regla en su proceso de cambios: “Solo un mirror degradado a la vez a menos que hagamos failover”. La lección no fue que ZFS sea frágil. La lección fue que el acoplamiento de cargas hace que “vdevs independientes” sea una mentira cuando saturas los mismos discos.

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

Un equipo quiso resilvers más rápidos, así que afinó agresivamente. Más concurrencia, más hilos, y dejaron que los reemplazos corrieran durante horario laboral porque “el pool puede con ello”. Las métricas se veían bien el día uno. El día dos, las alarmas de latencia de la base de datos empezaron. El día tres, el equipo de aplicación apareció con gráficos y horcas.

El fracaso no fue misterioso: resilver consume muchas lecturas, y esas lecturas compiten con todo lo demás. Al “optimizar” la velocidad del resilver sin controlar la carga, crearon la tormenta perfecta: lecturas aleatorias de aplicaciones más lecturas secuenciales del resilver más escrituras sync de una carga con journaling. El pool vivió en colas altas, y la latencia fue espiga e impredecible.

Luego llegó el efecto de segundo orden: un disco marginal empezó a timeoutear, que ZFS interpretó como errores. Ahora el pool no solo era lento: estaba degradado. Lo que los salvó fue revertir la “optimización”. Programaron resilvers de noche, redujeron IO diurno y usaron controles operativos (limitación de tasa vía gestión de cargas en lugar de intentar burlar al almacenamiento). Más rápido es bueno. Rápido en el momento equivocado es cómo fabricas incidentes.

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

Otro entorno: una empresa con cumplimiento estricto y control de cambios riguroso. Era el tipo de lugar donde pones los ojos en blanco por el papeleo hasta que algo falla. Tenían un pool RAIDZ2 con un lote de discos envejeciendo, y planearon un reemplazo rodante durante semanas.

La práctica aburrida: cada disco tenía su serial mapeado a una bahía, escrito y verificado por manos remotas con una segunda persona leyendo el serial de la etiqueta. Nada de “probablemente es la ranura 7”. También capturaban zpool status, resúmenes SMART y zpool events antes y después de cada reemplazo.

A mitad del lote, un disco falló en serio. No era el que estaban reemplazando—otro. En muchas empresas ahí empieza el pánico. Aquí, miraron sus registros y vieron que el pool había completado scrubs limpios, el último resilver fue sin errores y los discos nuevos tenían baselines SMART limpios. Esa evidencia les permitió tomar una decisión calma: proceder con un reemplazo de emergencia único, pausar el resto del lote y programar un scrub una vez restaurada la redundancia.

No tuvieron un incidente visible para clientes. El papeleo no evitó la falla. Evitó el error humano que convierte una falla en un outage. Lo aburrido es una característica.

Preguntas frecuentes

1) ¿Puedo reemplazar varios discos a la vez si tengo RAIDZ2?

Puedes, pero no deberías. RAIDZ2 tolera dos dispositivos faltantes, pero los resilvers solapados multiplican el riesgo y el tiempo de exposición. Reemplaza un disco por vdev, espera la finalización.

2) ¿Debería poner un disco offline antes de sacarlo?

Sí, cuando puedas. Ponerlo offline hace la remoción intencional y reduce comportamientos sorpresa. Si el disco ya desapareció, procede con zpool replace usando el identificador del dispositivo faltante.

3) ¿Cuál es la diferencia entre scrub y resilver?

Un scrub valida datos leyendo y verificando sumas por todo el pool. Un resilver reconstruye datos en un dispositivo de reemplazo. Ambos estresan discos; no los solapes a la ligera.

4) ¿Por qué ZFS muestra “errores permanentes” incluso después de reemplazar el disco?

Porque algunos datos eran ilegibles o estaban corruptos en el momento en que se necesitaron. Reemplazar el disco restaura la redundancia; no corrige retroactivamente archivos de aplicación corruptos. Restaura esos archivos desde backup o réplicas.

5) ¿Debo usar /dev/sdX en zpool replace?

No. Usa /dev/disk/by-id o el nombre exacto del leaf vdev mostrado en zpool status. /dev/sdX puede y va a cambiar.

6) El resilver es lento. ¿Significa que algo va mal?

A veces. Un resilver lento puede ser normal bajo carga, en pools casi llenos o con medios lentos. Es sospechoso cuando se vuelve progresivamente más lento o los errores empiezan a acumularse durante el proceso.

7) ¿Necesito ejecutar un scrub después de cada reemplazo de disco?

No siempre después de cada disco, pero deberías ejecutar uno tras un lote de reemplazos o tras cualquier evento con errores. El objetivo es validación, no ritual.

8) ¿Qué pasa si el disco nuevo es más grande que el antiguo?

ZFS generalmente usará el tamaño más pequeño hasta que todos los miembros del vdev estén actualizados y expandas (dependiendo de features y configuración). No asumas ganancias de capacidad instantáneas.

9) ¿Qué pasa si el disco nuevo es más pequeño que el antiguo?

No lo hagas. Incluso diferencias pequeñas pueden impedir el reemplazo. Iguala o supera tamaño, y prefiere la misma clase/modelo cuando sea posible para evitar desajustes de rendimiento.

10) ¿Puedo reemplazar discos en diferentes vdevs concurrentemente?

A veces, pero aún es arriesgado porque el presupuesto de IO del pool es compartido. Si debes hacerlo, solo hazlo cuando puedas reducir la carga y tengas fuerte visibilidad operativa.

Siguientes pasos que realmente puedes hacer

• Escribe tu mapeo de dispositivos: by-id ↔ bahía ↔ serial. Hazlo antes de que el próximo incidente fuerce improvisación.
• Decide tu política de reemplazo: uno a la vez por vdev, con “condiciones de parada” explícitas (nuevos errores en discos supervivientes, resets de enlace, colapso de rendimiento).
• Automatiza la captura de evidencia: guarda zpool status -v, resúmenes SMART y zpool events -v en tu registro de cambios.
• Practica en un pool no crítico: realiza un reemplazo controlado para que la primera vez no sea durante una paginación.
• Después de un lote, ejecuta scrub y revisa: trata el informe de scrub como tu certificado de “estamos estables otra vez”.

Reemplazar múltiples discos en ZFS es seguro cuando respetas el presupuesto de redundancia y la dimensión temporal. Reemplaza un disco, termina el resilver, verifica la salud, luego sigue. El orden no es una superstición. Es la forma de evitar que el mantenimiento se convierta en respuesta a incidentes.