Estrategia de hot-swap en ZFS: cómo reemplazar discos sin entrar en pánico

noviembre 10, 2025 • febrero 3, 2026 • Lectura: 30 min • Views: 12

¿Te fue útil?

Reemplazar un disco en ZFS debería sentirse como cambiar una rueda: metódico, un poco sucio y no una prueba de personalidad. Sin embargo, en producción a menudo se convierte en un ejercicio de improvisación grupal: alguien mira LEDs parpadeantes, otra persona está SSH’d en el host equivocado, y una tercera pregunta si “DEGRADED” es solo una sugerencia.

Esta guía es una estrategia práctica y validada en campo para hacer hot-swap de discos en ZFS sin inventar nuevas categorías de interrupción. Está escrita para quienes operan sistemas reales: les importa la disponibilidad, las pistas de auditoría y ese tablero ejecutivo que se pone rojo si la latencia sube más de cinco minutos.

1. La mentalidad: reemplazar discos es normal

ZFS se construyó con la asunción de que el almacenamiento falla. Los discos fallan. Los cables fallan. Los backplanes fallan. Los humanos fallan con entusiasmo. ZFS no exige que prevengas la falla; exige que respondas de forma predecible.

Una buena estrategia de hot-swap trata menos sobre “el comando correcto” y más sobre controlar la ambigüedad:

Sabe exactamente qué dispositivo vas a retirar. “Probablemente /dev/sdb” es la forma de crear un postmortem de outage con danza interpretativa.
Haz que ZFS vea nombres de dispositivo estables. Prefiere /dev/disk/by-id/ sobre los efímeros /dev/sdX.
Observa antes y después. Las líneas base, los logs y las comprobaciones deterministas convierten “creo que funciona” en “funciona”.
Respeta el resilver. No es magia; es I/O y CPU y a veces dolor.

Una verdad operativa: el hot-swap rara vez es la parte peligrosa. La parte peligrosa son los 45 minutos antes, cuando el equipo se convence de que tiene información perfecta. Spoiler: no la tienes. Construyes un procedimiento que funcione incluso cuando no la tienes.

Broma #1 (corta, relevante): Reemplazar un disco es como un simulacro de incendio: solo descubres que las salidas están bloqueadas cuando ya llevas el servidor por las escaleras.

2. Datos interesantes y contexto histórico

Un poco de contexto facilita justificar decisiones modernas de hot-swap en ZFS ante ingenieros y ante el público de “por qué está tardando tanto”.

ZFS fue diseñado con checksums de extremo a extremo para poder detectar corrupción silenciosa que los RAID clásicos sirven felizmente como “está bien”. Por eso los errores de checksum importan incluso cuando el sistema de archivos “parece normal”.
Los rebuilds de RAID solían ser mayormente secuenciales. Los discos grandes modernos y cargas aleatorias transformaron los rebuilds en eventos largos y ruidosos; el comportamiento de resilver de ZFS evolucionó para evitar leer espacio no asignado en muchos casos (según tipo de vdev y flags de funciones).
El problema del “write hole” en RAID5/6 tradicional (pérdida de energía a mitad de actualización de stripe) impulsó el movimiento hacia copy-on-write y actualizaciones transaccionales—ZFS hizo eso una suposición de primera clase.
La asignación de nombres de dispositivos en Unix siempre ha sido resbaladiza. Los nombres /dev/sdX son artefactos del orden de descubrimiento; en los primeros días del hotplug, el “mismo disco” podía volver con una letra distinta tras un reinicio. Por eso los IDs persistentes son la práctica estándar.
El soporte hardware para hot-swap precede a la madurez operativa común. Backplanes y expanders SAS facilitaron sacar discos; los playbooks operativos se quedaron atrás, por eso “arrancamos el equivocado” sigue siendo un género atemporal.
SMART nunca fue una garantía. Muchos discos mueren sin preámbulos dramáticos de SMART. SMART es un sistema probabilístico de alerta temprana, no una profecía.
“Discos más grandes, mismos bahías” cambió las matemáticas de fallos. Cuando los rebuilds tardan más, tu ventana de exposición aumenta. La estrategia de reemplazo de discos pasa a ser una estrategia de fiabilidad, no solo una tarea de mantenimiento.
La auto-reparación de ZFS necesita redundancia. ZFS puede detectar corrupción solo; solo puede repararla cuando tiene una copia buena (mirror/RAIDZ u otras características de redundancia).
Operativamente, el mayor riesgo son los humanos bajo presión de tiempo. La razón por la que muchos equipos usan rituales de “offline + localizar LED + confirmar serial” no es superstición; es tejido cicatricial ganado con dificultad.

3. Principios fundamentales de un hot-swap sin pánico

3.1 Prefiere identidad sobre ubicación, luego verifica la ubicación

Tu configuración de ZFS debe rastrear discos por IDs estables. Pero cuando el pool dice “el miembro X está mal”, aún necesitas mapear eso al slot físico y al número de serie real.

El patrón seguro es:

ZFS reporta un miembro de vdev en problemas (preferiblemente by-id).
Mapeas ese identificador al número de serie.
Mapeas el número de serie al slot (herramientas de enclosure o del controlador).
Enciendes el LED de localización y verificas por una segunda vía.

3.2 No te “optimices” hasta provocar pérdida de datos

Los procedimientos de hot-swap son deliberadamente aburridos. Si te tienta saltarte pasos porque “es solo un mirror”, recuerda: los mirrors también fallan, y el rebuild más rápido es el que no tienes que hacer dos veces.

Broma #2 (corta, relevante): Lo único más permanente que una solución temporal es un reemplazo “rápido” de disco hecho sin comprobar el serial.

3.3 Trata el resilver como un incidente, no como una tarea de fondo

El resilver compite con el I/O de producción y puede amplificar cuellos de botella existentes. Es normal ver picos de latencia, especialmente en pools HDD con escrituras aleatorias pequeñas. Planifícalo, monitorízalo y comunícalo.

3.4 Usa spares y reemplazos escalonados intencionalmente

Los hot spares pueden reducir el tiempo en degradado, pero también pueden ocultar un problema de hardware (por ejemplo, un backplane inestable o rutas de controlador defectuosas) al “arreglar” el síntoma. Decide si quieres:

Activación automática de spare para minimizar la ventana de riesgo, o
Uso manual del spare para mantener a los humanos en el bucle de verificación.

4. Preflight: qué revisar antes de tocar el hardware

Antes de sacar nada, quieres responder tres preguntas:

¿El pool está actualmente lo bastante seguro para sobrevivir esto? Si ya estás a un disco de perder el vdev, detente y piensa.
¿El “disco fallado” es realmente el disco? Podría ser un cable, un puerto del expander, un HBA o el slot del chasis.
¿Tienes un buen reemplazo y un plan de reversión? El medio de reemplazo puede venir DOA. La reversión suele ser “reinsertar el disco viejo”, lo que requiere que no lo destroces al sacarlo.

4.1 Instantánea de salud y captura de evidencias

Captura suficiente estado para poder comparar antes/después y defender tus decisiones más tarde.

cr0x@server:~$ zpool status -v
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:21:11 with 0 errors on Mon Dec 23 02:10:22 2025
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          raidz2-0                                DEGRADED     0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABC       ONLINE       0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABD       ONLINE       0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABE       FAULTED      0     0    23  too many errors
            ata-WDC_WD101KRYZ-01..._1SGH3ABF       ONLINE       0     0     0
            ata-WDC_WD101KRYZ-01..._1SGH3ABG       ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        /tank/vmstore/vm-102-disk-0

Interpretación: Esto no es “falta un disco”, es peor: una falla de dispositivo con errores de checksum y errores permanentes. Puede que necesites reparación a nivel de aplicación para archivos afectados. Aun así, reemplazar el disco es el primer paso.

4.2 Confirma el margen de redundancia

Conoce qué tolera tu vdev. Un RAIDZ2 puede sobrevivir a dos fallos por vdev; un mirror puede sobrevivir a uno por espejo; un RAIDZ1 vive un poco peligrosamente con discos grandes.

cr0x@server:~$ zpool status tank | sed -n '1,60p'
  pool: tank
 state: DEGRADED
  scan: scrub repaired 0B in 03:21:11 with 0 errors on Mon Dec 23 02:10:22 2025
config:

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

Interpretación: Identifica el tipo de vdev y cuántos miembros ya están fuera. Si estás al borde del precipicio (por ejemplo, RAIDZ1 ya degradado), planifica una ventana de mantenimiento diferente.

4.3 Revisa problemas sistémicos (HBA, cableado, chasis)

Si múltiples discos lanzan errores por la misma ruta de controlador, sustituir un solo disco a veces es “tratar el hematoma, no la fractura”.

cr0x@server:~$ dmesg -T | egrep -i 'ata|sas|scsi|reset|I/O error|timeout' | tail -n 30
[Mon Dec 23 11:04:18 2025] sd 3:0:12:0: [sdo] tag#71 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Mon Dec 23 11:04:18 2025] sd 3:0:12:0: [sdo] Sense Key : Medium Error [current]
[Mon Dec 23 11:04:18 2025] sd 3:0:12:0: [sdo] Add. Sense: Unrecovered read error
[Mon Dec 23 11:04:20 2025] mpt3sas_cm0: log_info(0x31111000): originator(PL), code(0x11), sub_code(0x1000)

Interpretación: “Medium Error” apunta a la superficie/medio del disco. Si ves resets de enlace, resets de PHY o timeouts en varios discos, sospecha cableado, expander o firmware/temperatura del HBA.

5. Identificación del disco: la parte que realmente rompe equipos

Los fallos en hot-swap rara vez son causados por sintaxis de ZFS. Son causados por alguien que tira del disco equivocado porque el esquema de nombres era descuidado. Los sistemas de producción castigan la ambigüedad.

5.1 Usa identificadores persistentes en ZFS

Al construir pools, usa rutas /dev/disk/by-id. Si tu pool ya usa /dev/sdX, aún puedes reemplazar especificando el disco antiguo tal como ZFS lo conoce, pero deberías planear una limpieza hacia nombres estables en el futuro.

5.2 Mapea el dispositivo ZFS al dispositivo OS y al slot físico

Empieza por lo que ZFS reporta (a menudo una cadena by-id). Luego mapea al dispositivo del kernel, después al serial y luego al slot del chasis.

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep 1SGH3ABE
lrwxrwxrwx 1 root root  9 Dec 23 10:55 ata-WDC_WD101KRYZ-01W..._1SGH3ABE -> ../../sdo

Interpretación: El by-id que falla apunta ahora a /dev/sdo. “Ahora” importa—los eventos de hotplug pueden reenumerar dispositivos. Por eso verificamos el serial también vía SMART.

cr0x@server:~$ sudo smartctl -a /dev/sdo | egrep -i 'Model|Serial|Capacity|Reallocated|Pending|Offline_Uncorrectable' 
Device Model:     WDC WD101KRYZ-01W
Serial Number:    1SGH3ABE
User Capacity:    10,000,831,348,736 bytes
  5 Reallocated_Sector_Ct   0x0033   001   001   140    Pre-fail  Always       -       2816
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       12
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       12

Interpretación: Este disco no está discutiendo filosóficamente su jubilación. Miles de reasignaciones más sectores pendientes es “reemplázame”. Captura el serial; ese es tu ancla de verdad.

5.3 Enciende el LED correcto (cuando puedas)

En servidores con gestión de chasis adecuada, puedes localizar la bahía del disco vía herramientas de SAS enclosure. La utilidad exacta difiere, pero el principio es: usa el serial para encontrar el slot, luego hazlo parpadear.

Si no tienes LEDs de localización: etiqueta tus bandejas, mantiene un mapa de bahías y no confíes en “el tercero desde la izquierda”. Esa frase ha causado outages.

6. Procedimientos paso a paso para hot-swap (mirror, RAIDZ, spares)

6.1 Flujo seguro general (funciona para la mayoría de topologías)

Confirma el estado del pool/vdev y el margen de redundancia.
Confirma la identidad del disco fallado por serial.
Opcionalmente pon el disco offline en ZFS (recomendado cuando sea posible).
Retira físicamente y reemplaza el disco.
Asegúrate de que el OS vea el disco nuevo y confirma que su serial coincide con la documentación de reemplazo.
Ejecuta zpool replace (o deja que autoreplace haga su trabajo si lo activaste deliberadamente).
Monitoriza el resilver hasta su finalización; verifica que no haya nuevos errores; ejecuta un scrub si procede.

6.2 Reemplazo en mirror

Los mirrors perdonan más y son rápidos de operar, pero no confundas “perdonan” con “invencibles.” Si sacas el lado equivocado, puedes tumbar el mirror y provocar un incidente de servicio, especialmente si el disco restante ya está al límite.

Enfoque recomendado:

Pon offline el miembro que piensas extraer.
Reemplázalo y conecta el disco nuevo.
Prefiere rutas explícitas de dispositivo by-id.

6.3 Reemplazo en RAIDZ

Los resilvers en RAIDZ pueden castigar más el rendimiento, especialmente en HDDs y con bloques pequeños. Si es una carga sensible a la latencia, planifica el reemplazo para una ventana más tranquila o limita el comportamiento del resilver (con cuidado) en lugar de confiar en la suerte.

6.4 Spares: calientes, fríos y “sorpresa, se activó”

ZFS soporta spares. Si un spare se ha activado, tu trabajo es: reemplazar el disco fallado y decidir si devuelves el spare al pool de spares o lo mantienes in situ. No dejes el spare permanentemente consumido sin registrarlo; dentro de seis meses alguien supondrá que aún tienes un spare y pasarás una noche muy educativa.

7. Tareas prácticas (con comandos e interpretación)

Abajo hay tareas prácticas que puedes incorporar a un runbook. Están escritas con mentalidad Linux + OpenZFS. Ajusta rutas para tu distribución y stack de hardware.

Tarea 1: Obtener un estado claro del pool para el ticket

cr0x@server:~$ zpool status -P -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:21:11 with 0 errors on Mon Dec 23 02:10:22 2025
config:

        NAME                                                STATE     READ WRITE CKSUM
        /tank                                               DEGRADED     0     0     0
          raidz2-0                                          DEGRADED     0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABC                 ONLINE       0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABD                 ONLINE       0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABE                 FAULTED      0     0    23  too many errors
            /dev/disk/by-id/ata-..._1SGH3ABF                 ONLINE       0     0     0
            /dev/disk/by-id/ata-..._1SGH3ABG                 ONLINE       0     0     0

Interpretación: -P fuerza rutas completas; -v incluye detalles de errores. Esta salida es lo que quieres en tu línea temporal del incidente.

Tarea 2: Verificar que las etiquetas en disco coinciden con lo esperado

cr0x@server:~$ sudo zdb -l /dev/sdo | sed -n '1,60p'
------------------------------------
LABEL 0
------------------------------------
    version: 5000
    name: 'tank'
    state: 0
    txg: 12345678
    pool_guid: 1234567890123456789
    vdev_guid: 9876543210987654321
    top_guid: 1111222233334444555

Interpretación: Confirma que el disco pertenece al pool que crees. Esto es especialmente útil en hosts con múltiples pools o cuando alguien “tomó prestadas” bahías.

Tarea 3: Mapear by-id al dispositivo kernel actual

cr0x@server:~$ readlink -f /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._1SGH3ABE
/dev/sdo

Interpretación: Ayuda a conectar el nombre de dispositivo de ZFS con SMART y logs del kernel.

Tarea 4: Comprobar SMART y contadores de error

cr0x@server:~$ sudo smartctl -H /dev/sdo
SMART overall-health self-assessment test result: FAILED!

Interpretación: Un SMART health fallido no es sutil. Incluso sin él, contadores altos de pending/uncorrectable son suficiente motivo para actuar.

Tarea 5: Comprobar si los errores se están extendiendo

cr0x@server:~$ zpool events -v | tail -n 20
TIME                           CLASS
Dec 23 2025 11:03:55.123456789 ereport.fs.zfs.checksum
    vdev_path=/dev/disk/by-id/ata-..._1SGH3ABE
    vdev_guid=9876543210987654321
    pool=tank

Interpretación: Si ves errores de checksum en varios discos, mira rutas de controlador y cableado, no solo el disco “más ruidoso”.

Tarea 6: Poner el disco offline limpiamente antes de sacarlo (recomendado)

cr0x@server:~$ sudo zpool offline tank /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._1SGH3ABE
cr0x@server:~$ zpool status tank | sed -n '1,40p'
  pool: tank
 state: DEGRADED
config:

        NAME                                          STATE     READ WRITE CKSUM
        tank                                          DEGRADED     0     0     0
          raidz2-0                                    DEGRADED     0     0     0
            ...                                       ...
            ata-WDC_WD101KRYZ-01W..._1SGH3ABE         OFFLINE      0     0     0

Interpretación: Poner offline reduce comportamientos sorpresa mientras sacas el disco. También hace más visible más pronto el escenario de “se sacó el disco equivocado”.

Tarea 7: Tras el swap físico, confirma que el OS ve el disco nuevo

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,WWN,TYPE
NAME   SIZE MODEL           SERIAL    WWN               TYPE
sdo    9.1T WDC WD101KRYZ   2JGH7XYZ  0x50014ee2abcd123 disk
...

Interpretación: Confirma que estás viendo el serial nuevo, no el viejo reapareciendo por una bandeja floja o rebote en el backplane.

Tarea 8: Reemplazar el disco en ZFS de forma explícita

cr0x@server:~$ sudo zpool replace tank \
  /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._1SGH3ABE \
  /dev/disk/by-id/ata-WDC_WD101KRYZ-01W..._2JGH7XYZ

Interpretación: Reemplazo explícito viejo->nuevo evita ambigüedad y que ZFS “adivine” qué disco nuevo pretendías.

Tarea 9: Vigilar el progreso del resilver de la forma correcta

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Mon Dec 23 11:22:01 2025
        1.23T scanned at 1.8G/s, 412G issued at 620M/s, 9.20T total
        82.3G resilvered, 4.36% done, 03:21:44 to go
config:
        ...

Interpretación: “Scanned” y “issued” importan. Si “issued” avanza lento mientras “scanned” es rápido, tu pool está ocupado sirviendo I/O real o estás limitado en otra parte.

Tarea 10: Comprobar I/O por vdev y detectar cuellos de botella

cr0x@server:~$ zpool iostat -v tank 5
                                   capacity     operations     bandwidth
pool                             alloc   free   read  write   read  write
-------------------------------  -----  -----  -----  -----  -----  -----
tank                             62.3T  28.7T   420   1900  86.4M   322M
  raidz2-0                       62.3T  28.7T   420   1900  86.4M   322M
    ata-..._1SGH3ABC                -      -     80    350  16.0M  64.0M
    ata-..._1SGH3ABD                -      -     82    360  16.2M  64.5M
    ata-..._2JGH7XYZ                -      -     96    520  20.5M  88.0M
    ata-..._1SGH3ABF                -      -     80    330  16.0M  62.0M
    ata-..._1SGH3ABG                -      -     82    340  16.2M  63.5M
-------------------------------  -----  -----  -----  -----  -----  -----

Interpretación: El disco de reemplazo a menudo trabaja más durante el resilver. Si un disco muestra ancho de banda/ops dramáticamente peor, sospecha un disco nuevo defectuoso, problema de velocidad negociada del enlace o un slot/bahía con problemas.

Tarea 11: Confirmar expectativas de TRIM / ashift (especialmente SSDs)

cr0x@server:~$ sudo zdb -C tank | egrep -i 'ashift|autotrim' | head
                ashift: 12
        autotrim: on

Interpretación: Suposiciones de tamaño de sector desajustadas pueden perjudicar el rendimiento. No puedes “arreglar ashift” en un miembro vdev existente sin reemplazar/re-escribir el vdev, así que verifica antes de escalar reemplazos de SSD.

Tarea 12: Validar que el pool vuelve a sano y se mantiene

cr0x@server:~$ zpool status -x
all pools are healthy

Interpretación: La mejor salida de estado es aburrida. Si no es aburrida, sigue investigando.

Tarea 13: Scrub tras el reemplazo (cuando proceda)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 15:01:12 2025
        2.10T scanned at 1.5G/s, 0B issued at 0B/s, 9.20T total

Interpretación: Un scrub es una pasada de confianza: lee y verifica. No lo ejecutes a ciegas durante pico de carga si tienes un presupuesto de latencia frágil, pero prográmalo pronto después.

Tarea 14: Si el pool reporta errores permanentes, identifica archivos afectados

cr0x@server:~$ zpool status -v tank | sed -n '/errors:/,$p'
errors: Permanent errors have been detected in the following files:
        /tank/vmstore/vm-102-disk-0

Interpretación: Reemplazar el disco detiene la hemorragia, pero no resucita datos ya corruptos. Ahora necesitas recuperación específica de la carga de trabajo: restaurar desde backup, regenerar artefactos o reparar imágenes VM.

8. Realidad del resilver: rendimiento, tiempo y cómo vigilarlo

Resilvering es ZFS copiando los datos necesarios para reconstruir la redundancia en el nuevo dispositivo. Los detalles varían con la topología y versión/funciones de ZFS, pero en producción te importan dos preguntas:

¿Cuánto tiempo estaremos degradados?
¿Cuánto dolor sentirán los usuarios mientras estamos degradados?

8.1 Por qué el tiempo de resilver es tan difícil de predecir

Datos asignados vs tamaño bruto: Un disco de 10 TB no significa 10 TB de resilver. Depende de cuán lleno esté el pool y cómo esté distribuida la data.
Interferencia de la carga de trabajo: ZFS sirve lecturas/escrituras mientras también resilveriza. Tus clientes son parte del benchmark.
Comportamiento del disco bajo estrés: Los HDD pueden entrar en recuperaciones profundas de errores; los SSD pueden thermal-throttle; los discos SMR pueden convertir un rebuild en una lenta carta de disculpa.
Límites del controlador: Expanders SAS, HBAs, carriles PCIe—tu cuello de botella puede estar corriente arriba de los discos.

8.2 Cómo se ve un resilver “bueno”

Un resilver sano es ruidoso pero estable: el progreso aumenta de forma constante, la latencia de I/O sube algo, y ZFS no acumula nuevos errores de checksum.

Cómo se ve “malo”:

El progreso del resilver se queda estancado largos periodos.
Aparecen nuevos errores de lectura en otros discos.
El disco de reemplazo muestra timeouts en dmesg.
La latencia de la aplicación se hace no lineal (colapso de colas).

8.3 El truco operativo: reducir sorpresas

Informa a la gente que hay un resilver en curso. Si tienes SLOs, trátalo como un periodo de riesgo conocido. Si tienes jobs batch o backups, considera pausarlos. El incidente de rendimiento más fácil de resolver es el que no provocas durante tu propio mantenimiento.

9. Playbook de diagnóstico rápido: caza de cuellos de botella bajo presión

Esta es la secuencia de “mi pager suena fuerte y la dirección está mirando”. El objetivo no es la causa raíz perfecta en cinco minutos. El objetivo es dejar de empeorar las cosas y encontrar rápidamente el cuello de botella dominante.

Paso 1: Confirma en qué estado ZFS cree que está

cr0x@server:~$ zpool status -v
cr0x@server:~$ zpool status -x

Mira: DEGRADED vs FAULTED, resilver en progreso, contadores de error en aumento, “too many errors” o un dispositivo faltante.

Paso 2: Revisa los logs del kernel por errores de transporte vs medio

cr0x@server:~$ dmesg -T | tail -n 200

Interpretación:

Errores de medio (“Unrecovered read error”) suelen implicar el disco.
Errores de transporte (resets de enlace, timeouts en varios dispositivos) implican cableado/HBA/expander/backplane/power.

Paso 3: Identifica si el cuello de botella es disco, CPU, presión de memoria o colas

cr0x@server:~$ uptime
cr0x@server:~$ vmstat 1 5
cr0x@server:~$ iostat -x 1 5

Interpretación:

Alto wa (iowait) más alta utilización de disco sugiere bound por almacenamiento.
Alta cola de ejecución con bajo iowait sugiere bound por CPU o contención de locks.
El await del disco que se dispara durante resilver puede ser esperado, pero si es extremo y concentrado en un dispositivo, sospecha ese miembro/slot.

Paso 4: Enfócate en la distribución de I/O a nivel ZFS

cr0x@server:~$ zpool iostat -v 5
cr0x@server:~$ zpool iostat -v tank 5

Mira: un disco mucho más lento que sus pares, o un vdev haciendo trabajo desproporcionado. En RAIDZ, un disco retrasado puede arrastrar todo el vdev a un infierno de latencia.

Paso 5: Revisa la presión del ARC y datos sucios (si la latencia sube)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep 'size|c_max|c_min|memory_throttle_count' | head -n 20
cr0x@server:~$ cat /proc/spl/kstat/zfs/vdev_cache_stats 2>/dev/null | head

Interpretación: Si estás memory-throttling o el ARC está bajo presión, ZFS puede estar haciendo trabajo extra. Esto suele ser “dolor de fondo” visible durante resilver.

Paso 6: Si se reporta corrupción, decide qué salvas primero

Si ZFS reporta errores permanentes, prioriza la integridad:

Estabiliza el pool (termina reemplazo/resilver).
Identifica datasets/archivos impactados.
Restaura/repara a nivel de aplicación.

El rendimiento puede ajustarse. La corrupción es una fecha límite.

10. Errores comunes (síntomas y soluciones)

Esta sección está escrita con la tinta de incidentes pasados. Si reconoces tu entorno en alguno, felicidades: eres normal. Ahora arréglalo.

Error 1: Usar /dev/sdX en configuraciones de pool

Síntoma: Tras un reboot o evento hotplug, ZFS muestra dispositivos faltantes o el disco equivocado aparece como miembro fallado; alguien jura que “antes era sdc”.

Solución: Usa rutas by-id para reemplazos, y cuando tengas una ventana de mantenimiento, migra configuraciones hacia identificadores estables. Como mínimo, siempre reemplaza usando by-id en lugar de sdX.

Error 2: Sacar un disco antes de ponerlo offline (en entornos ambiguos)

Síntoma: El pool pasa de DEGRADED a “missing device”, multipath se comporta raro, o se extrae la bandeja equivocada porque el equipo no tenía una señal clara de “este es seguro de sacar”.

Solución: Pon offline el miembro objetivo, confirma que el estado muestre OFFLINE para ese by-id específico, y luego extrae.

Error 3: Confundir un slot/backplane defectuoso con un disco malo

Síntoma: Reemplazas el disco y los errores continúan—a menudo en el nuevo disco—especialmente timeouts o resets de enlace.

Solución: Mueve el disco a otro slot (si es posible) para probar la bahía, inspecciona cables SAS/SATA, revisa logs del expander/HBA y examina la alimentación/temperaturas.

Error 4: Reemplazar múltiples discos “porque ya estamos aquí”

Síntoma: Un segundo disco se pone offline a mitad del resilver, o el rendimiento se colapsa. El equipo ahora está haciendo dos cosas estresantes a la vez.

Solución: Escalona los reemplazos. Termina un resilver antes de empezar el siguiente, a menos que tengas un plan muy controlado y margen de redundancia adecuado (y aun así, ten cautela).

Error 5: Suponer que la velocidad de resilver será “como la última vez”

Síntoma: Un resilver que antes tomaba horas ahora toma días; los stakeholders entran en pánico; los ingenieros empiezan a “tunear” knobs al azar.

Solución: Valida el llenado del pool, la intensidad de la carga y la clase de dispositivo (CMR vs SMR HDD, comportamiento de cache SSD, etc.). Usa iostat/zpool iostat para localizar el verdadero limitador antes de cambiar parámetros de ZFS.

Error 6: Ignorar errores de checksum porque el pool está ONLINE

Síntoma: Aparecen errores de checksum periódicamente; los scrubs a veces los “reparan”; meses después un segundo evento revela corrupción latente o un fallo de hardware más amplio.

Solución: Trata los errores de checksum como una señal. Correlaciónalos con SMART, cableado, resets de controlador y scrubs. Reemplaza componentes sospechosos de forma proactiva.

Error 7: Autoreplace habilitado sin disciplina de inventario

Síntoma: Un disco nuevo insertado desencadena un reemplazo automático, pero no estaba destinado a ese pool/vdev; en entornos multi-bahía es fácil consumir el disco equivocado.

Solución: Si usas autoreplace, combínalo con etiquetado estricto de slots, rastreo de seriales y control de cambios. Si no puedes garantizar disciplina operativa, prefiere reemplazos explícitos con zpool replace.

Error 8: No comprobar el disco nuevo antes de confiar en él

Síntoma: Comienza el resilver y el disco nuevo empieza a lanzar errores; vuelves a degradado, ahora con menos confianza.

Solución: Al menos confirma identidad SMART y salud básica. En entornos de mayor rigor, realiza pruebas de burn-in antes de poner discos en pools de producción.

11. Listas de verificación / plan paso a paso

11.1 La lista operacional “reemplazar un disco”

Abre un registro de incidente o cambio (aunque sea “menor”). Añade host, pool y hora.
Captura el estado base: zpool status -P -v, zpool events -v | tail y errores recientes del kernel.
Confirma el margen de redundancia: identifica tipo de vdev y miembros actualmente degradados.
Identifica el disco fallado por serial: mapea by-id → sdX → serial SMART.
Verifica el slot físico: mapa de enclosure/LED locate; verificación de segunda persona si está disponible.
Pon el disco offline: zpool offline, confirma que muestre OFFLINE.
Hot-swap del hardware: extrae el disco viejo, inserta el de reemplazo, espera a que el OS lo detecte.
Verifica serial y tamaño/clase del reemplazo: lsblk, smartctl.
Ejecuta el reemplazo: zpool replace pool old new.
Monitoriza el resilver: zpool status y zpool iostat -v.
Vigila daños colaterales: nuevos errores de checksum en otros discos sugiere problema sistémico.
Cierra el ciclo: confirma zpool status -x, programa scrub, actualiza inventario con seriales viejo/nuevo.

11.2 Lista “Encontramos errores permanentes”

Estabiliza el pool (completa reemplazo/resilver).
Lista archivos afectados: zpool status -v.
Identifica datasets y contexto de la aplicación.
Restaura desde backup o regenera datos.
Scrub tras la remediación para confirmar limpieza.

11.3 Lista “Sospechamos que no es el disco”

Comprueba si múltiples discos en la misma ruta de controlador muestran resets/timeouts.
Inspecciona cables, vuelve a asentar el HBA, revisa firmware y temperaturas.
Cambia el slot del disco (si es posible) para aislar fallos de bahía/backplane.
Considera reemplazo de controlador o diagnóstico del expander si los errores persisten.

12. Tres micro-historias corporativas desde las trincheras

12.1 Incidente causado por una suposición errónea: “El LED significa que ese disco es seguro de sacar”

El entorno era un cluster corporativo de virtualización bastante estándar: un par de hosts intensivos en almacenamiento, un pool ZFS compartido por host y suficientes dashboards como para hacer pensar que el sistema se pagaba por métrica. Un host marcó un disco como degradado. El on-call hizo lo correcto al principio: revisó zpool status y vio una ruta by-id que parecía familiar.

Entonces apareció la suposición equivocada: el equipo trató el LED del chasis como fuente de la verdad. El servidor tenía dos comportamientos de LED distintos—uno dirigido por el enclosure y otro por la función “locate” del controlador RAID. Alguien había probado previamente “locate” en otra bahía y nunca lo apagó. Así que ahora parpadeaban dos bahías: el disco fallado y uno perfectamente sano.

El on-call extrajo el disco equivocado. El pool pasó de DEGRADED a un estado mucho más enojado, y las latencias de almacenamiento de las VM del host se dispararon en el tipo de gráfico que hace que los ejecutivos descubran adjetivos. ZFS hizo lo que pudo, pero perder un miembro extra en el mismo vdev movió el sistema de “reparable mientras sirve tráfico” a “vas a tener que restaurar algunas cosas”.

La solución no fue heroica; fue procedimental. Reinsertaron el disco extraído por accidente (afortunadamente sano), pusieron offline el disco correcto por by-id y luego usaron un segundo método de confirmación: el número de serie vía SMART coincidía con el registro de activos y el mapa de bahías concordaba con la slot del enclosure. Tras el reemplazo, actualizaron el runbook: los LEDs son útiles, no autoritativos. La cadena autoritativa es identificador ZFS → dispositivo OS → serial SMART → bahía física.

La lección que quedó: a los humanos les encantan las luces parpadeantes porque se sienten ciertas. Los sistemas de producción castigan ese atajo emocional.

12.2 Optimización que salió mal: “Subamos la velocidad del resilver para terminar antes”

Otro equipo tenía una carga sensible a la latencia—piensa servicios internos que “no son de cara al cliente” hasta que se caen, momento en el que mágicamente son lo más visible del planeta. Tuvieron un disco fallado en un vdev RAIDZ. El equipo quería reducir la ventana degradada al mínimo, así que alguien propuso aumentar la agresividad: dejar que el resilver corra tan rápido como los discos pudieran.

Funcionó en un sentido estrecho: el throughput del resilver subió. Pero la carga no estaba inactiva y el pool no era mayoritariamente secuencial. La combinación de lecturas intensas para rebuild, cálculos de paridad y la carga normal de escrituras aleatorias empujó el sistema a un colapso por colas. La latencia se hinchó, los timeouts se encadenaron y los servicios aguas arriba comenzaron tormentas de reintentos. Ahora la infraestructura no solo estaba degradada—era un incidente de rendimiento.

Lo que empeoró la situación: durante ese evento otro disco empezó a registrar timeouts. No porque fallara, sino porque quedó hambriento y la cola del controlador se saturó. Eso desencadenó un “¿está fallando un segundo disco?” de pánico, y el equipo casi inicia un segundo reemplazo a mitad del resilver.

La estabilización eventual fue, otra vez, aburrida: redujeron la agresividad del rebuild (y disminuyeron I/O batch competidor), priorizaron la estabilidad del servicio y aceptaron una ventana degradada más larga. El resilver terminó después, pero el negocio dejó de notar cada vez que el almacenamiento parpadeaba.

La lección: un resilver más rápido no es automáticamente más seguro. El resilver más seguro es el que no provoca un outage intentando prevenir uno.

12.3 Una práctica aburrida pero correcta que salvó el día: inventario por serial y verificación por dos personas

Este equipo tenía reputación de ser casi ofensivamente metódico. Cada bahía de disco tenía una etiqueta. Cada disco tenía su serial registrado en la instalación. Cada vez que reemplazaban un disco, actualizaban el inventario interno y pegaban la salida previa/posterior de zpool status -P -v en el ticket de cambio. Era el tipo de proceso que hace que algunos ingenieros pongan los ojos en blanco—hasta que empieza a pagar alquiler.

Una tarde, un pool reportó errores en un disco que físicamente estaba en una bahía que, según la etiqueta, no debería haber sido parte de ese pool. Esa inconsistencia fue la alarma. En lugar de arrancar el “obvio” disco, pausaron. Verificaron el by-id de ZFS, lo mapearon a un serial y descubrieron que el disco se había movido meses antes durante un swap de chasis y el mapa de bahías nunca se actualizó.

Porque tenían inventario basado en seriales, pudieron reconciliar la discrepancia sin adivinar. Actualizaron el mapa de bahías, pusieron offline el disco correcto y lo reemplazaron limpiamente. No hubo extracciones accidentales, ni segundos fallos, ni downtime inesperado. El único “costo” fueron diez minutos extra de verificación.

En la revisión posterior, nadie celebró el proceso; apenas lo mencionaron. Así sabes que funcionó. Las mejores prácticas operativas no crean historias. Las previenen.

13. Preguntas frecuentes

Q1: ¿Siempre debo poner un disco offline antes de retirarlo físicamente?

En la mayoría de entornos de producción, sí. Poner offline hace explícita la intención y reduce la ambigüedad durante eventos hotplug. Las excepciones son cuando el disco ya ha desaparecido/no responde, o tu stack de hardware no tolera bien el offlining—pero esos son casos especiales que deben documentarse.

Q2: ¿Puedo reemplazar un disco por otro ligeramente más pequeño si “en la etiqueta pone el mismo tamaño”?

No confíes en los tamaños de marketing. ZFS se preocupa por sectores utilizables reales. Un reemplazo incluso ligeramente más pequeño puede fallar al adjuntarse. Verifica tamaños con lsblk o blockdev --getsize64 antes de empezar.

Q3: Mirror vs RAIDZ—¿difiere el procedimiento de hot-swap?

El flujo de comandos es similar, pero el perfil de riesgo difiere. Los mirrors suelen ser más simples y resilverizan más rápido; los resilvers en RAIDZ pueden ser más pesados y largos. La regla de “no reemplazar varios discos a la vez” importa más en RAIDZ porque el estrés del resilver puede revelar miembros débiles.

Q4: ¿Qué pasa si `zpool replace` dice que el dispositivo está ocupado o no se adjunta?

Causas comunes: el disco nuevo tiene particiones de un uso anterior, multipath presenta un nodo distinto al que esperabas, o estás especificando rutas inestables. Confirma la identidad del disco nuevo, limpia etiquetas antiguas si procede (con cuidado) y usa rutas by-id consistentemente.

Q5: ¿Debería habilitar autoreplace?

Autoreplace puede ser genial en entornos controlados con mapeo consistente de slots y un inventario disciplinado. En entornos mixtos (múltiples pools, chasis compartidos, humanos intercambiando “cualquier disco que entre”), puede crear comportamientos sorprendentes. Si no puedes garantizar disciplina operativa, prefiere reemplazos explícitos.

Q6: ¿Cómo sé si los errores de checksum significan que perdí datos?

Errores de checksum indican que ZFS detectó una discrepancia. Si la redundancia permitió la reparación, ZFS puede haberlo corregido de forma transparente (verás “repaired” durante el scrub). Si ZFS reporta “permanent errors”, significa que no pudo reparar algunos bloques; entonces identificas archivos impactados y restauras/reparas a nivel de aplicación.

Q7: ¿Es seguro ejecutar un scrub durante un resilver?

Usualmente no es lo deseable. Ambos son operaciones de lectura intensas que compiten por los mismos spindles/controladores. Termina el resilver primero y luego haz el scrub pronto después (o prográmalo cuando la carga sea aceptable). Hay casos excepcionales para hacer un scrub para confirmar problemas de integridad más amplios, pero debe ser una decisión intencional.

Q8: ¿Por qué a veces el resilver de ZFS parece más lento que los rebuilds “tradicionales”?

A veces no es más lento; es solo honesto sobre el trabajo. ZFS puede hacer verificación extra, y a menudo comparte ancho de banda con I/O de producción. Además, las cargas modernas son aleatorias y los discos modernos son enormes. La inflación del tiempo de rebuild es un impuesto de la física, no un bug de software.

Q9: Tras el reemplazo, ¿debo conservar el disco viejo para análisis?

Si tu entorno tiene fallos recurrentes, sí—al menos lo suficiente para confirmar si el modo de fallo es desgaste de medio, problemas de transporte o ambientales (calor/vibración/energía). Si es claramente medio fallando (pending/uncorrectable explotando), normalmente puedes RMA y seguir, pero conserva evidencia suficiente (salida SMART, serial, timestamps) para detectar patrones.

14. Conclusión

Los hot-swap en ZFS no tienen por qué ser deportes de adrenalina. El sistema te da las herramientas para reemplazar discos de forma segura—si tratas la identidad como sagrada, mantienes estable el nombrado de dispositivos y respetas el resilver como un evento operativo real.

La estrategia ganadora es deliberadamente poco sexy: confirma por serial, pon offline antes de extraer, reemplaza explícitamente, vigila el resilver como si importara y sigue con comprobaciones de integridad y actualizaciones de inventario. Así es como reemplazas discos sin pánico—eliminando la sorpresa del proceso, una verificación aburrida a la vez.