ZFS offline/online: usar el modo mantenimiento sin romper la redundancia

Offline/online sin superstición: el modelo mental

ZFS no hace “RAID” como lo hacía tu controlador hardware en 2012. Hace vdevs (dispositivos virtuales), y la redundancia vive a nivel de vdev.
Un pool es tan sano como su vdev menos redundante, porque cualquier pérdida de un vdev es pérdida del pool. Ese es el titular.

Cuando ejecutas zpool offline, no estás eliminando un disco del historial del pool. Le dices a ZFS:
“Deja de confiar en este dispositivo hoja para I/O ahora mismo.” Es un cambio de estado operativo, no un cambio estructural.
Contrástalo con zpool detach (solo mirror), que cambia la topología al quitar un dispositivo de un vdev mirror.

Qué significa realmente “offline”

• Offline: el dispositivo está intencionalmente no disponible. ZFS no lo usará. El vdev/pool puede volverse DEGRADED.
• Faulted: ZFS decidió que el dispositivo está malo (demasiados errores, timeouts, etc.). Puede que necesites limpiar/reemplazar.
• Removed: el dispositivo desapareció (cable, enclosure, ruta, HBA, multipath). A veces vuelve; a veces está mintiendo.
• Unavailable: ZFS no puede abrir la ruta del dispositivo. Esto incluye renombrados, falta de by-id o problemas con el enclosure.

Offline vs replace vs detach: elegir el verbo correcto

Aquí está la regla que aplico en producción: usa el martillo más pequeño que te lleve de forma fiable al siguiente estado seguro.

• Usa zpool offline para sacar un disco de servicio temporalmente, especialmente antes de trabajos físicos.
• Usa zpool replace cuando vas a intercambiar medios y quieres que ZFS trate el nuevo disco como sucesor.
• Usa zpool detach solo en mirrors, y solo cuando realmente quieras reducir el ancho del mirror.
• Evita “arrancar” sin offlining primero a menos que ya estés en modo emergencia (el disco está muerto o el bus está en llamas).

La redundancia no es un concepto filosófico. Es aritmética: cuántos dispositivos pueden faltar en el mismo vdev antes de perder datos.
Los mirrors generalmente sobreviven a la falta de un disco (por mirror). RAIDZ1 sobrevive a uno. RAIDZ2 a dos. RAIDZ3 a tres.
Pero el mantenimiento a menudo crea un segundo fallo: pones un disco en offline y luego descubres que otro estaba muriéndose silenciosamente. Felicidades, acabas de inventar un postmortem.

Una cita útil para mantener en tu terminal: “La esperanza no es una estrategia.” — General Gordon R. Sullivan.
A los equipos de almacenamiento les encanta la esperanza. ZFS la castiga.

Broma #1: Si nunca has offlined el disco equivocado, o bien etiquetas perfectamente —o no has hecho suficiente mantenimiento todavía.

Hechos e historia interesantes que realmente importan

1. ZFS se originó en Sun Microsystems a mediados de los 2000 como reacción a pilas de almacenamiento con split-brain (volume manager + filesystem) que no podían coordinar la integridad.
2. El nombre “pool” fue un cambio deliberado de mentalidad: no administras sistemas de archivos en discos; administras capacidad y redundancia como recurso compartido.
3. ZFS suma sumas de verificación a todo (metadata y datos). Por eso un pool degradado no es lo mismo que un pool arriesgado—hasta que pierdes la última copia buena.
4. Scrub existía para combatir la “descomposición de bits” antes de que fuera tendencia. En ZFS, scrub es lectura/verificación/reparación proactiva usando redundancia; no es un “fsck” de sistema de archivos.
5. Resilver no es un scrub. Resilver es la reconstrucción de réplicas faltantes tras replacement/offline/online; scrub es la verificación completa del pool.
6. Los nombres by-id se volvieron una táctica de supervivencia cuando la denominación de dispositivos en Linux (/dev/sdX) resultó demasiado fluida con hotplug, multipath y reseteos de HBA.
7. Los administradores tempranos aprendieron por las malas sobre caches de escritura: discos que mienten sobre flushes pueden derrotar a un sistema de archivos, incluso uno con semántica transaccional.
8. El comportamiento de rebuild de RAIDZ difiere del RAID5/6 tradicional: ZFS resilver solo copia bloques asignados (más metadata), lo que puede ser mucho más rápido—a menos que tu pool esté muy lleno.
9. Los estados “REMOVED” de dispositivos aumentaron con SAS expanders y JBODs: un fallo transitorio del enclosure puede parecer un fallo de disco, y tratarlo como tal puede aumentar el riesgo.

Esto no son preguntas de trivial. Cada uno cambia cómo respondes cuando un disco desaparece y alguien pregunta,
“¿Podemos simplemente offlinearlo y seguir?”

Tareas prácticas: comandos, salidas y decisiones

A continuación hay tareas concretas que harás durante una ventana de mantenimiento. Para cada una: el comando, qué significa la salida y qué decisión tomar después.
Los ejemplos asumen un pool llamado tank. Cambia nombres según corresponda.

Tarea 1: Confirmar la topología del pool antes de tocar nada

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: Some supported and requested features are enabled on the pool.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    ONLINE       0     0     0
          raidz2-0                              ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF    ONLINE       0     0     0

errors: No known data errors

Significado: Tienes un único vdev RAIDZ2. Puedes tolerar dos discos faltantes en este vdev; una tercera pérdida mata el pool.
Los nombres by-id parecen estables y específicos. Bien.

Decisión: Si planeas poner un disco en offline, estás consumiendo una “vida” de redundancia. Verifica que no haya miembros ya degradados/faulted primero.

Tarea 2: Verificar que no estés ya degradado (no apiles fallos)

cr0x@server:~$ zpool list -o name,size,alloc,free,health tank
NAME  SIZE  ALLOC   FREE  HEALTH
tank  43.5T  34.9T  8.6T  ONLINE

Significado: HEALTH está ONLINE. Alloc está algo alto. Alta ocupación hace que los resilver sean más lentos y arriesgados (menos espacio libre, más fragmentación).

Decisión: Si HEALTH está DEGRADED o ALLOC está cerca del lleno, trata el mantenimiento como cirugía: minimiza el tiempo degradado y considera posponer trabajos no críticos.

Tarea 3: Identificar el disco físico detrás de una hoja ZFS

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep VKJ0A1AD
lrwxrwxrwx 1 root root  9 Dec 25 03:10 ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD -> ../../sdg

Significado: El dispositivo hoja ZFS se mapea a /dev/sdg ahora mismo. Eso puede cambiar tras reinicios; by-id es la referencia estable.

Decisión: Usa nombres by-id en ZFS siempre que sea posible. Usa /dev/sdX solo para comprobaciones OS transitorias.

Tarea 4: Revisar SMART antes de decidir que es “solo un cable”

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i 'Serial Number|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count'
Serial Number:    VKJ0A1AD
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       8
197 Current_Pending_Sector  0x0012   200   200     0    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   200   200     0    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200     0    Old_age   Always       -       0

Significado: Reallocated y pending sectors existen. Eso es problema de media, no solo un cable inestable (los CRC indicarían cableado).

Decisión: Planea reemplazo, no “reseat and pray”. Offline primero, reemplaza, resilver, luego scrub más tarde.

Tarea 5: Poner el disco objetivo en offline (modo mantenimiento, intencional)

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    DEGRADED     0     0     0
          raidz2-0                              DEGRADED     0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD    OFFLINE      0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF    ONLINE       0     0     0

errors: No known data errors

Significado: El pool está DEGRADED por acción administrativa, no por fallos. Ese es el tipo de degradado más seguro: estás en control.

Decisión: Procede con el trabajo físico. Además: congela otros cambios riesgosos. No es el momento para actualizaciones de kernel o experimentos de firmware de HBA.

Tarea 6: Confirmar que el disco realmente no está en uso (evitar I/O sorpresa)

cr0x@server:~$ sudo zpool iostat -v tank 1 3
                                          capacity     operations     bandwidth
pool                                    alloc   free   read  write   read  write
--------------------------------------  -----  -----  -----  -----  -----  -----
tank                                    34.9T  8.6T     45     30  4.20M  2.10M
  raidz2-0                               34.9T  8.6T     45     30  4.20M  2.10M
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA        -      -      8      5   710K   380K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB        -      -      7      5   690K   370K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC        -      -      9      5   740K   400K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD        -      -      0      0      0      0
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE        -      -      6      5   670K   360K
    ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF        -      -      6      5   690K   380K
--------------------------------------  -----  -----  -----  -----  -----  -----

Significado: El dispositivo offlined no muestra ops/bandwidth. Esperado. Si ves I/O en una hoja “offline”, algo anda mal (aliases, multipath, nombre equivocado).

Decisión: Si hay actividad inesperada, detente y vuelve a verificar la identidad del dispositivo antes de sacar nada.

Tarea 7: Reemplazar el disco y decírselo a ZFS explícitamente (no confíes en autodetect)

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep VKJ0A1AD
lrwxrwxrwx 1 root root  9 Dec 25 03:10 ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD -> ../../sdg

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep NEWDRIVE
lrwxrwxrwx 1 root root  9 Dec 25 03:42 ata-WDC_WD80EFZX-68UW8N0_NEWDRIVE -> ../../sdg

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD ata-WDC_WD80EFZX-68UW8N0_NEWDRIVE

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    DEGRADED     0     0     0
          raidz2-0                              DEGRADED     0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AA    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AB    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AC    ONLINE       0     0     0
            replacing-3                         DEGRADED     0     0     0
              ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD  OFFLINE      0     0     0
              ata-WDC_WD80EFZX-68UW8N0_NEWDRIVE  ONLINE       0     0     0  (resilvering)
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AE    ONLINE       0     0     0
            ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AF    ONLINE       0     0     0

scan: resilver in progress since Thu Dec 25 03:43:11 2025
        1.26T scanned at 1.45G/s, 312G issued at 360M/s, 34.9T total
        52.0G resilvered, 0.86% done, 1 days 02:13:08 to go
errors: No known data errors

Significado: ZFS creó un subárbol “replacing”, rastreando viejo vs nuevo. La estimación suele ser pesimista al principio.

Decisión: No pongas otro disco en offline “por seguridad”. Ya estás en margen reducido hasta que termine el resilver.

Tarea 8: Monitorear progreso de resilver y decidir si debes limitar cargas

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

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
scan: resilver in progress since Thu Dec 25 03:43:11 2025
        9.80T scanned at 1.12G/s, 2.01T issued at 235M/s, 34.9T total
        1.62T resilvered, 5.76% done, 0 days 19:04:55 to go

Significado: “scanned” es lo que ZFS examinó; “issued” es lo que realmente tuvo que reconstruir/copiar. Issued es lo que estresa discos.

Decisión: Si la latencia de la aplicación sube, considera reducir temporalmente trabajos pesados de escritura, backups o tareas de compactación. Tu objetivo es “terminar el resilver sin un segundo fallo”, no “ganar benchmarks”.

Tarea 9: Volver a poner en online un disco previamente offlined (cuando fue un problema transitorio)

cr0x@server:~$ sudo zpool online tank ata-WDC_WD80EFZX-68UW8N0_VKJ0A1AD

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
status: One or more devices has been brought online.
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    ONLINE       0     0     0
          mirror-0                              ONLINE       0     0     0
            ata-SAMSUNG_MZ7KM960_ABC123          ONLINE       0     0     0
            ata-SAMSUNG_MZ7KM960_DEF456          ONLINE       0     0     0

errors: No known data errors

Significado: Online vuelve a integrar la hoja en servicio. Dependiendo de lo ocurrido, ZFS puede resilver para re-sincronizar.

Decisión: Si el disco fue offlined por sospecha de errores de media, no lo pongas online “para ver qué pasa”. Reemplázalo. La curiosidad sale cara en almacenamiento.

Tarea 10: Limpiar errores transitorios después de arreglar la causa (no antes)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
  see: http://zfsonlinux.org/msg/ZFS-8000-8A
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    DEGRADED     0     0     0
          mirror-0                              DEGRADED     0     0     0
            ata-SAMSUNG_MZ7KM960_ABC123          ONLINE       0     0     7
            ata-SAMSUNG_MZ7KM960_DEF456          ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/data/app.db

cr0x@server:~$ sudo zpool clear tank

Significado: zpool clear limpia contadores de error y estados de fault, pero no repara mágicamente datos corruptos de aplicaciones.

Decisión: Limpia solo después de arreglar la causa subyacente y después de haber manejado cualquier “Permanent errors” a nivel de dataset/aplicación.

Tarea 11: Confirmar identidad del dispositivo con labels ZFS (cuando by-id miente o duplica)

cr0x@server:~$ sudo zdb -l /dev/sdg | egrep 'name:|pool_guid|vdev_tree|guid'
    name: 'tank'
    pool_guid: 17219319428190311341
    guid: 1329582641194012239

Significado: zdb -l lee la etiqueta ZFS en disco y te dice a qué pool pertenece. Es tu herramienta forense cuando las rutas confunden.

Decisión: Si un disco no etiqueta como esperabas, detente. Podrías estar mirando el disco de otro pool o un spare obsoleto.

Tarea 12: Asegúrate de no estar por resilver desde una ruta más lenta (multipath/sas)

cr0x@server:~$ lsblk -o NAME,HCTL,SIZE,MODEL,SERIAL,TRAN
NAME HCTL       SIZE MODEL            SERIAL   TRAN
sdg  2:0:6:0    7.3T WDC WD80EFZX-68U NEWDRIVE sas

Significado: HCTL te da el controlador:target:lun. Útil para mapear a puertos HBA y bahías del expander.

Decisión: Si el “nuevo disco” aparece en un HCTL inesperado, puede que lo hayas insertado en la bahía equivocada. Arréglalo ahora, no después de 12 horas de resilver.

Tarea 13: Comprobar si hay scrub/resilver en curso antes de empezar mantenimiento (no apiles)

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
scan: scrub in progress since Thu Dec 25 01:12:04 2025
        18.3T scanned at 710M/s, 18.3T issued at 710M/s, 34.9T total
        0B repaired, 52.4% done, 0 days 05:22:19 to go

Significado: Un scrub ya está estresando todos los discos. Offlinear un disco a mitad de scrub fuerza a ZFS a trabajar más en los miembros restantes.

Decisión: Prefiere pausar/terminar scrub antes del mantenimiento planificado si la política lo permite. Si debes proceder, acepta mayor riesgo y duraciones más largas.

Tarea 14: Detener un scrub (con intención) para reducir carga durante un resilver crítico

cr0x@server:~$ sudo zpool scrub -s tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
scan: scrub canceled on Thu Dec 25 03:55:10 2025

Significado: Scrub fue cancelado. No arreglaste integridad; redujiste carga. Eso está bien cuando estás triageando riesgo.

Decisión: Reprograma scrub después del resilver y fuera de horas de negocio. No dejes el pool sin scrub indefinidamente porque te ocupaste.

Tarea 15: Export/import como reinicio controlado (cuando un estado de dispositivo está atascado)

cr0x@server:~$ sudo zpool export tank

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
errors: No known data errors

Significado: Export/import puede limpiar ciertos problemas de rutas estancadas y fuerza un rescan. Es disruptivo: los datasets desaparecen brevemente.

Decisión: Usa durante ventanas de mantenimiento, no en pico de tráfico. Si tu problema es de hardware, export/import no lo curará.

Tarea 16: Establecer una política temporal de spares (si tienes spares configurados)

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME                                STATE     READ WRITE CKSUM
        tank                                DEGRADED     0     0     0
          mirror-0                          DEGRADED     0     0     0
            ata-HGST_HUH721010ALE604_AAA111  OFFLINE      0     0     0
            ata-HGST_HUH721010ALE604_BBB222  ONLINE       0     0     0
        spares
          ata-HGST_HUH721010ALE604_SPARE33   AVAIL

cr0x@server:~$ sudo zpool replace tank ata-HGST_HUH721010ALE604_AAA111 ata-HGST_HUH721010ALE604_SPARE33

Significado: Puedes reemplazar activamente un disco offline/faulted con un hot spare disponible. ZFS resilverará en el spare.

Decisión: Usa spares para comprar tiempo, no para evitar un reemplazo adecuado. Los spares deben volver a AVAIL después de instalar un disco real.

Patrones de modo mantenimiento (mirror, RAIDZ, spares)

Patrón A: vdev mirror — el lugar más seguro para practicar

Los mirrors son indulgentes durante el mantenimiento porque la aritmética de redundancia es simple: un lado puede desaparecer y todavía tienes una copia completa.
Eso no significa que debas volverte presumido. Los mirrors fallan de formas aburridas: ambos dispositivos se compraron juntos, recibieron la misma carga y envejecen igual.

Para mirrors, normalmente tienes tres flujos sensatos:

• Offline → replace → resilver (preferido para intercambio físico).
• Offline → online (para problemas de ruta/cable sospechados después de arreglar).
• Detach (solo cuando reduces intencionalmente el ancho del mirror, o cuando separas un mirror para migración/pruebas y aceptas el riesgo).

Evita mezclar “detach” en rotinas de arreglo. Detach es para siempre. Offline es el botón de pausa.

Patrón B: RAIDZ — el mantenimiento es un ejercicio de presupuesto de riesgo

RAIDZ es donde la gente hace movimientos “razonables” que se vuelven irracionales cuando la segunda variable cambia.
En RAIDZ2, offlinear un disco para trabajo planificado suele estar bien. Pero tu riesgo ahora está concentrado:
cualquier otro fallo de disco o un enclosure inestable que caiga dos rutas a la vez puede empujarte a un estado irrecuperable.

Orientación práctica:

• Minimiza el tiempo degradado. Ten el disco de reemplazo preprobado, etiquetado y listo.
• No hagas experimentos de firmware mientras estás degradado. El reset del HBA que “nunca viste antes” aparecerá justo entonces.
• Vigila la ocupación del pool. Alta asignación tiende a aumentar el tiempo de resilver y la carga, lo que incrementa la probabilidad de un segundo fallo.
• Prefiere resilvers en horario laboral. La forma más rápida de conseguir ayuda es empezar mientras la gente está despierta y Slack hace ruido.

Patrón C: Hot spares — útiles, pero fáciles de malusar

Los hot spares son una herramienta para reducir el tiempo medio degradado, no un sustituto del mantenimiento de hardware.
El patrón común de fallo: el spare se activa, todos se relajan, pasan semanas y ahora el spare es “parte del pool” sin spare disponible.
El siguiente fallo no se impresiona.

Qué no hacer: “modo mantenimiento” arrancando discos

Aún hay gente que lo hace porque es rápido y a veces funciona.
El costo es que pierdes la oportunidad de confirmar identidad, arriesgas un evento a nivel de bus y creas estados ambiguos (“REMOVED,” “UNAVAIL”) que complican la recuperación.
Offline es una orden de una línea. Úsala.

Broma #2: La forma más rápida de descubrir que tu proceso de etiquetado es malo es hacer swaps de discos a las 2 a.m. con una linterna.

Guía de diagnóstico rápido (encuentra el cuello de botella)

Cuando un pool se vuelve DEGRADED o un resilver va lento, no tienes tiempo para leer cada post del foro jamás escrito.
Necesitas un orden de triage que encuentre el factor limitante rápido.

Primero: confirma qué piensa ZFS que está pasando

• Comando: zpool status -v
• Mira: OFFLINE vs FAULTED vs REMOVED, subárbol “replacing”, sección “scan:”, contadores de error.
• Decisión: Si un dispositivo está FAULTED con errores read/write/cksum, planifica reemplazo. Si está REMOVED/UNAVAIL, investiga ruta/HBA/enclosure primero.

Segundo: verifica si estás luchando contra el sistema (scrub, escrituras pesadas, cuotas, snapshots)

• Comando: zpool status para scrub/resilver; zpool iostat -v 1 para la forma de carga
• Mira: scrub en progreso, ancho de banda de escritura masivo, un disco al 100%, muy baja tasa “issued”
• Decisión: Si el resilver está lento y el pool está ocupado, o bien limita cargas o acepta más tiempo degradado. El tiempo degradado es tiempo de riesgo.

Tercero: aislar problemas de ruta hardware

• Comandos: smartctl -a, lsblk -o NAME,HCTL,SERIAL,TRAN, y logs del kernel con dmesg -T
• Mira: resets de enlace, SAS phy flaps, timeouts, errores CRC, fallos de comandos en cola
• Decisión: Si múltiples discos muestran errores a nivel de transporte, deja de reemplazar “discos malos” y empieza a revisar HBA, expander, alimentación del enclosure y cableado.

Cuarto: verifica que no te hayas quedado sin presupuesto de redundancia

• Comando: zpool status y calcula mentalmente: ¿cuántas fallas puede tolerar este vdev ahora mismo?
• Mira: RAIDZ1 con uno offline = sin margen; mirror con un lado fallando = sin margen
• Decisión: Si el margen se fue, detén el trabajo electivo. Tu objetivo pasa a ser “volver a redundante lo antes posible”, aunque eso signifique pausar cargas.

Quinto: revisa ocupación y fragmentación del pool como multiplicador de resilver

• Comando: zpool list
• Mira: ALLOC alto, FREE bajo, scrubs históricamente lentos
• Decisión: Si el resilver es lento por ocupación, no puedes arreglarlo en vuelo. Úsalo para justificar margen de capacidad en el próximo ciclo presupuestario.

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

1) Síntoma: el pool está DEGRADED tras un mantenimiento “simple”; nadie sabe por qué

Causa raíz: El disco fue arrancado sin offlining, y los nombres de dispositivo cambiaron tras un rescan/reboot.

Solución: Usa zpool status para identificar la hoja faltante por by-id, confirma con zdb -l, re-inserta en la bahía correcta y luego zpool online o zpool replace según corresponda.

2) Síntoma: resilver “atascado” en 0% o progresa dolorosamente lento

Causa raíz: El pool está saturado por escrituras de la aplicación o por otro scrub; o el disco de reemplazo es SMR/lento; o hay un problema de transporte causando reintentos.

Solución: Confirma con zpool iostat -v qué dispositivo es el cuello de botella. Revisa smartctl y dmesg -T por errores/timeouts. Reduce carga, detén scrub si es necesario, y considera reemplazar el disco de reemplazo si rinde claramente menos.

3) Síntoma: pusiste en offline un disco y un segundo disco de repente muestra errores

Causa raíz: Quitaste redundancia, aumentando la presión de lectura en los discos restantes; errores sectoriales latentes surgieron bajo carga.

Solución: No pongas online el disco malo solo para recuperar margen. Reemplaza los discos que fallen en el orden más seguro, considera usar un spare y mantén cargas conservadoras hasta restaurar redundancia.

4) Síntoma: “cksum errors” en un disco pero SMART parece bien

Causa raíz: Cableado, HBA, expander o backplane que corrompen datos en tránsito; a veces memoria, pero usualmente transporte.

Solución: Revisa errores CRC/transporte y los logs. Reseat/reemplaza el cable, mueve bahías, valida estabilidad de firmware del HBA. Limpia errores solo después de arreglar transporte y hacer scrub para confirmar que no hay nueva corrupción.

5) Síntoma: disco reemplazado, pero ZFS sigue referenciando el viejo nombre by-id

Causa raíz: El reemplazo se hizo sin zpool replace, o el OS presentó una ruta diferente; ZFS está rastreando la vieja identidad de la hoja.

Solución: Usa zpool status para ver el árbol “replacing”. Si hace falta, ejecuta explícitamente zpool replace viejo_leaf con el nuevo by-id. Confirma con zpool status que el resilver está corriendo.

6) Síntoma: el pool pasa a UNAVAIL tras export/import durante un swap de disco

Causa raíz: Faltan demasiados dispositivos para un vdev, o la importación fue intentada sin rutas correctas (by-id faltante), o un disco pertenece a otro pool.

Solución: Usa zpool import sin argumentos para listar pools, añade -d /dev/disk/by-id, confirma etiquetas con zdb -l. No fuerces import a menos que entiendas las consecuencias.

7) Síntoma: tras poner un disco online, ZFS no resilverea y temes divergencia silenciosa

Causa raíz: El dispositivo volvió sin cambios necesarios (estuvo offline brevemente), o ZFS cree que está al día por el estado de transaction group.

Solución: Confirma con zpool status (no resilver no es automáticamente malo). Ejecuta un scrub tras el mantenimiento para validar integridad end-to-end.

8) Síntoma: “demasiados errores” y ZFS marca un disco como faulted que pasa diagnósticos del proveedor

Causa raíz: Timeouts intermitentes bajo carga, firmware inestable, o reseteos de HBA/enclosure que las pruebas del proveedor no reproducen.

Solución: Trata los timeouts como reales. Correlaciona con logs del sistema, reemplaza componentes cuestionables y prefiere HBAs/enclosures estables sobre “pasó una prueba rápida”.

Tres mini-historias del mundo corporativo

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

Una compañía SaaS mediana usaba ZFS en Linux para un object store multi-tenant. El pool era RAIDZ2, JBOD denso, nada exótico.
Tenían la rutina: si un disco mostraba algunos errores de checksum, lo offlineaban, programaban reemplazo y seguían.

Una noche, un disco empezó a registrar timeouts. El on-call lo offlineó y abrió un ticket para swap a la mañana siguiente.
La suposición fue que “offline significa seguro” y que el resto del vdev silenciosamente cargaría con la carga.

Lo que no vieron: el pool ya estaba muy ocupado y los jobs batch nocturnos habían empezado—lecturas y escrituras masivas.
Con un disco en offline, ZFS tenía menos paralelismo y más trabajo de reconstrucción por lectura. La latencia subió. Los clientes reintentaron. La tormenta de reintentos aumentó la carga.

Dos horas después, un segundo disco (mismo modelo, mismo lote de compra) empezó a devolver sectores ilegibles bajo la carga incrementada.
Ese disco no estaba “repentinamente malo”. Fue repentinamente probado. El pool pasó de “degradado planeado” a “falla activa.”

Se recuperaron, pero la ventana de reparación se alargó: discos de reemplazo, resilver y luego un scrub que encontró un puñado de errores permanentes en objetos fríos.
El postmortem no fue sobre ZFS. Fue sobre la suposición de que el modo degradado es un punto de operación estable. No lo es; es un carril de emergencia.

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

Un equipo financiero quiso rebuilds más rápidos. Alguien propuso una “mejora simple”: programar scrubs semanales en horario laboral porque “los scrubs mantienen todo sano”
y “es mejor encontrar errores temprano”. Suena razonable.

El pool servía VMs. La carga era sensible a latencia: escrituras sincrónicas pequeñas, ráfagas de lecturas. Scrub corría, caches se calentaban y el rendimiento parecía bien—al principio.
En unas semanas emergió un patrón: cada día de scrub incluía algunas pausas de VM y alertas de almacenamiento. Sin outage, pero una fuga lenta de confianza.

Luego un disco falló durante un scrub. El equipo lo reemplazó rápido, pero ahora tenían carga de scrub más resilver más carga del día laboral.
El resilver se estiró. El pool permaneció degradado mucho más tiempo de lo habitual. La “optimización” había extendido la ventana de riesgo.

La solución fue aburrida: mover scrubs a ventanas de baja carga, imponer throttles de carga durante resilver y tratar la programación de scrub como un cambio de producción con impacto en SLO.
Sus rebuilds no se volvieron más rápidos. Sus incidentes se hicieron más raros.

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

Una plataforma de salud tenía control de cambios estricto. Molestaba a todos, lo que es indicador de que funcionaba.
Su runbook de almacenamiento requería: nombres by-id por todas partes, mapas de bahías impresos actualizados con cada cambio de chasis y verificación de dos personas antes de cualquier extracción de disco.

Durante un reemplazo planificado, el técnico en sitio encontró que la etiqueta de la bahía no coincidía con el mapeo del OS. La acción fácil hubiera sido “sacar el que parece correcto”.
En cambio, siguieron el proceso: offline la hoja objetivo por by-id, confirmar cero I/O a ese dispositivo con zpool iostat -v, luego comparar números de serie con smartctl.

La discrepancia resultó ser un swap de backplane meses antes, con numeración de bahías invertida por el firmware del enclosure.
Si hubieran sacado según la etiqueta física, habrían retirado un disco sano dejando el que fallaba online—exactamente el tipo de caos que hace que RAIDZ parezca frágil.

Actualizaron el mapa de bahías, reemplazaron el disco correcto, resilverearon, scrubearon y siguieron. Sin incidente. Sin llamada al puente.
La única víctima fue la creencia de alguien de que el proceso es “papelero”. El proceso es cómo evitas aprender la misma lección dos veces.

Listas de verificación / plan paso a paso

Mantenimiento planificado de disco (un solo disco) — flujo seguro

1. Confirma redundancia y salud actual
   Ejecuta zpool status -v y zpool list. Si ya está DEGRADED, detente y reevalúa. No apiles riesgo.
2. Identifica el disco sin ambigüedades
   Usa by-id, luego mapea a /dev/sdX con ls -l /dev/disk/by-id. Verifica serial con smartctl -a.
3. Comprueba si es media o transporte
   Pending/reallocated sectors sugieren media. CRC/link resets sugieren transporte. Decide si reemplazas disco o arreglas ruta.
4. Pon el disco en offline
   zpool offline tank <by-id>. Confirma que aparece OFFLINE y sin I/O.
5. Realiza el swap físico
   Usa mapas de bahías. No confíes en “probablemente el que parpadea” a menos que uses una función de locate validada.
6. Confirma la identidad del nuevo disco
   Revisa by-id y serial. Asegura que no insertaste capacidad/modelo incorrecto por accidente.
7. Reemplaza explícitamente
   zpool replace tank <old-by-id> <new-by-id>. Confirma “replacing” y que el resilver empezó.
8. Monitorea resilver y salud del sistema
   Observa zpool status y zpool iostat -v. Revisa logs del kernel por resets/timeouts.
9. Vuelve a ONLINE y restaura postura de spares
   Cuando termine el resilver, asegura que el pool esté ONLINE y que tengas un spare AVAIL si tu política lo exige.
10. Scrub después de que todo calme
    Programa un scrub en una ventana segura para validar integridad end-to-end tras el evento.

Evento de disco de emergencia (FAULTED/REMOVED inesperado) — flujo de contención

1. Detén la hemorragia: captura la salida de zpool status -v para el ticket y el registro del incidente.
2. Determina el tipo de estado: FAULTED sugiere reemplazo; REMOVED/UNAVAIL sugiere investigación de ruta primero.
3. Busca problemas sistémicos: si múltiples discos reportan errores, sospecha HBA/enclosure/cableado/energía.
4. Reduce carga: pausa scrubs, difiere jobs batch, reduce operaciones con muchas escrituras si es posible.
5. Restaura redundancia ASAP: reemplaza el disco o restaura la ruta. Usa un hot spare si necesitas ganar tiempo.
6. Valida: finalización de resilver, luego scrub después y revisar contadores de error.

Reglas que aplico (porque me gusta dormir)

• Nunca pongas un disco en offline en RAIDZ1 a menos que estés preparado para un reemplazo ese mismo día y vigilancia cuidadosa.
• Nunca hagas múltiples swaps de discos concurrentes en el mismo vdev a menos que tengas un procedimiento probado y documentado y una razón más allá de la impaciencia.
• Nunca borres errores para “hacer desaparecer la alerta” hasta que entiendas la causa.
• Siempre guarda un registro de: leaf by-id, bahía física, número de serie, lote de compra si se conoce y fecha del último scrub.

Preguntas frecuentes

1) ¿Reduce zpool offline la redundancia?

Sí, de la única forma que importa: quita un miembro participante de réplica/paridad de un vdev.
El pool puede seguir sirviendo datos, pero tienes menos tolerancia a fallos hasta que el dispositivo vuelva o sea reemplazado y resilvered.

2) ¿Debería poner offline un disco antes de retirarlo físicamente?

Para mantenimiento planificado, sí. Offlining es un cambio de estado intencional que previene I/O sorpresa y te ayuda a confirmar que apuntaste el dispositivo correcto.
Si el disco ya está muerto/inaccesible, puede que no puedas offlinearlo de manera significativa—pero aún puedes proceder con el reemplazo.

3) ¿Cuál es la diferencia entre offline y detach?

offline es temporal y no cambia la topología. detach elimina un dispositivo de un vdev mirror y cambia la topología permanentemente.
Usa detach cuando lo quieras realmente, no como atajo de mantenimiento.

4) ¿Puedo poner offline un disco en RAIDZ2 y seguir ejecutando producción?

Usualmente, sí. Pero “puedes” no es “deberías sin cambios”. Espera mayor latencia bajo carga, resilvers más largos y mayor riesgo por fallos latentes.
Reduce carga durante la ventana degradada si quieres que el mantenimiento sea aburrido.

5) ¿Por qué mi estimación de tiempo de resilver saltó?

Las estimaciones de ZFS se basan en el throughput observado y el trabajo descubierto hasta ahora. Temprano en un resilver puede no haber mapeado la cantidad real de datos a reconstruir.
Observa “issued” y el ancho de banda real; trata los ETAs como pistas, no como contratos.

6) ¿Debería hacer un scrub justo después de reemplazar un disco?

No inmediatamente si el pool está ocupado y te importan las latencias. Primero: termina el resilver y vuelve a redundante.
Luego haz scrub en una ventana controlada para validar integridad en todo el pool.

7) Veo errores de checksum, pero no errores de lectura/escritura. ¿Es problema de disco?

No siempre. Los errores de checksum a menudo implican transporte (cableado/backplane/HBA) porque los datos llegaron corruptos.
Verifica con SMART (contadores CRC), logs del sistema y si múltiples discos muestran síntomas similares.

8) ¿Es seguro poner online un disco que fue offlined por errores?

Si fue offlined por trabajo de ruta transitorio y arreglaste la ruta, ponerlo online está bien y puede disparar resilver.
Si fue offlined porque la media fallaba (pending sectors, uncorrectables), ponerlo online es apostar con datos de producción.

9) ¿Y si acidentalmente offlinie el disco equivocado?

Primero: detente. Confirma el margen de redundancia. Si aún tienes margen, inmediatamente zpool online el disco equivocado y verifica que se reincorpore limpiamente.
Luego re-identifica el disco correcto usando números de serie y mappings by-id antes de continuar.

10) ¿Cómo interactúan los hot spares con offline/online?

Un spare puede usarse como objetivo de reemplazo vía zpool replace, reduciendo tiempo degradado.
Pero una vez que un spare está en uso activo, efectivamente no tienes spare. Reemplaza el disco fallado prontamente y devuelve el spare a AVAIL.

Conclusión: próximos pasos prácticos

ZFS te da las herramientas para tratar el trabajo con discos como una operación controlada en vez de una pelea en un chasis de servidor.
La diferencia entre “modo mantenimiento” y “modo incidente” suele ser una cosa: si cambiaste el estado intencionalmente y lo verificaste.

1. Estandariza en nombres by-id para pools y runbooks. Si tus comandos dependen de /dev/sdX, estás construyendo sobre arena.
2. Mide el tiempo degradado. Rastrea cuánto tiempo los pools pasan sin redundancia completa; optimiza para más corto, no para más rápido.
3. Escribe el paso de verificación de dos personas en la política para swaps físicos: mapear by-id → serial → bahía, luego offline.
4. Programa scrubs como cambios de producción, no como tareas. Alinea con ventanas de baja carga y cobertura de respuesta a incidentes.
5. Practica el flujo en un pool mirror no crítico. Es más barato que practicar durante un outage.

En la próxima ventana de mantenimiento, apunta a un solo resultado: que puedas explicar cada estado de dispositivo en zpool status y por qué cambió.
Si puedes hacer eso, no estás adivinando—estás operando.