ZFS RAIDZ1: el cálculo de riesgo que la mayoría nunca hace

enero 15, 2026 • febrero 3, 2026 • Lectura: 27 min • Views: 9

¿Te fue útil?

RAIDZ1 es el equivalente en almacenamiento de conducir con una rueda de repuesto y convencerte de que es una jaula antivuelco. Funciona—hasta el día en que necesitas que funcione bajo estrés, a velocidad, con mal tiempo y pasajeros que no les importa que “pasó la última prueba”.

La mayoría de las conversaciones sobre RAIDZ1 se detienen en “puede fallar un disco”. Eso es cierto, y también peligrosamente incompleto. La verdadera pregunta es: ¿cuál es la probabilidad de que ocurra un segundo problema mientras estás reconstruyendo, y cuánto tiempo estás expuesto? Esa es la matemática que la gente no hace, porque obliga a tomar una decisión: RAIDZ2, mirrors, discos más pequeños, más repuestos, mejor monitorización, reemplazos más rápidos, o aceptación del riesgo—consciente, no por defecto.

Lo que realmente protege RAIDZ1 (y lo que no)

RAIDZ1 es RAID de paridad simple en ZFS: puedes perder un dispositivo en un vdev y seguir operando. Esa afirmación es cierta en el mismo sentido en que “tu paracaídas puede fallar una vez” es cierta—técnicamente exacta, emocionalmente poco útil.

Para qué sirve RAIDZ1

Protege contra una única falla completa de dispositivo dentro de un vdev, siempre que los dispositivos restantes sean lo bastante legibles para reconstruir los datos faltantes. En la práctica, RAIDZ1 es más cómodo cuando:

los discos son más pequeños (menos datos que leer durante el rebuild),
la carga de IO es moderada,
tienes hot spares o manos rápidas,
haces scrub regularmente y reemplazas discos temprano.

Contra qué no protege RAIDZ1

No te protege de un segundo problema durante el resilver. Ese segundo problema no siempre es “otro disco muere”. Más a menudo, es uno de estos:

Unrecoverable read errors (URE) en los discos restantes mientras se lee para reconstruir.
Errores de sector latentes que solo aparecen cuando fuerzas una lectura exhaustiva del vdev.
Retrasos en el tiempo de reemplazo (procurement, aprobaciones, el repuesto está en otra región).
Problemas de controlador/HBA/cableado que aparecen en el peor momento.
Colapso inducido por la carga donde la carga del resilver más la producción provocan timeouts y fallas en cascada.

Un chiste corto, porque te lo has ganado: RAIDZ1 es como un cinturón de seguridad hecho de esperanza—bien hasta que realmente lo necesitas.

El cálculo de riesgo que la mayoría nunca hace

Aquí está la verdad incómoda: con RAIDZ1, tu riesgo está dominado por lo que ocurre durante la ventana de resilver. Así que el cálculo no es “probabilidad de que falle un disco”, sino:

Probabilidad de que falle un disco × probabilidad de otra falla/URE durante el resilver × duración de la exposición al resilver × realidad operacional (alertas, repuestos, carga, respuesta del personal).

Paso 1: define tus modos de fallo

Para un vdev RAIDZ1 de N discos:

Primer evento: un disco falla (o queda marcado como faulted, o empieza a lanzar errores que no puedes ignorar).
Segundo evento: otro disco falla antes de que termine el resilver, o encuentras lecturas no recuperables en discos restantes al leer bloques necesarios para la reconstrucción.

Las discusiones clásicas sobre RAID se obsesionan con las tasas de URE de las hojas de especificaciones. Eso importa, pero en ZFS también tienes:

Verificación por checksum que detectará corrupción,
self-healing si existe redundancia (no existe en RAIDZ1 una vez degradado),
copy-on-write que cambia patrones de escritura y fragmentación.

Paso 2: calcula tu ventana de exposición (tiempo de resilver)

Cuanto más tiempo dure el resilver, más tiempo vives sin paridad. Si el resilver tarda 6 horas, quizá aceptes RAIDZ1. Si tarda 6 días, has programado efectivamente una semana de “por favor, que nadie estornude”.

El tiempo de resilver no es “tamaño del disco / velocidad secuencial”. En producción real es:

bytes realmente asignados (ZFS resilvers bloques asignados, no el disco entero, salvo que se fuerce),
fragmentación del pool,
carga concurrente,
layout del vdev y ashift,
recordsize y amplificación de IO,
reintentos de error del dispositivo y timeouts.

Paso 3: modela el riesgo URE/errores latentes en lenguaje llano

Los fabricantes de discos citan URE como algo así como 1 error por 10^14 bits (consumidor), o 10^15 bits (mejor), a veces 10^16 en papel en equipos enterprise. Traduce eso:

10^14 bits ≈ 12.5 TB leídos por cada URE esperada
10^15 bits ≈ 125 TB leídos por cada URE esperada

Durante una reconstrucción degradada en RAIDZ1, puedes necesitar leer mucha información de los discos supervivientes. ZFS no tiene magia aquí: si un sector no se puede leer y no tienes redundancia, puedes perder datos. Dependiendo del bloque y de los metadatos implicados, podría ser un archivo, un dataset o una falla a nivel de pool en el peor de los casos.

La trampa: la gente multiplica “tasa de URE” por “tamaño del disco” y lo da por zanjado. Pero el número correcto es “cuánto dato hay que leer de los discos restantes para reconstruir lo que falta”, que puede acercarse al tamaño de los datos asignados del vdev, más la sobrecarga por reintentos y metadatos.

Un enfoque práctico que cambia decisiones

En lugar de pretender que podemos calcular exactamente la probabilidad, los equipos operacionales mejoran con umbrales:

Si el resilver termina rutinariamente en horas, y puedes reemplazar discos inmediatamente, RAIDZ1 puede ser aceptable para pools no críticos.
Si el resilver suele tardar varios días, RAIDZ1 se convierte en una decisión de negocio que deberías documentar como cualquier otra aceptación de riesgo.
Si no puedes garantizar un reemplazo rápido, o ejecutas alta utilización, RAIDZ1 frecuentemente es una falsa economía.

El segundo chiste corto (y aquí lo dejamos)

Comprar discos más grandes para “reducir el número de puntos de fallo” es la forma de acabar con menos discos y más fallo.

Por qué los discos modernos lo cambian todo

RAIDZ1 nació en un mundo donde “disco grande” significaba cientos de gigabytes, no decenas de terabytes. Entonces, las ventanas de rebuild eran más cortas y la probabilidad de encontrar un error de lectura durante el rebuild era materialmente menor simplemente porque no tenías que leer tanto.

El crecimiento de capacidad superó la velocidad de rebuild

La capacidad explotó; el throughput secuencial mejoró, pero no al mismo ritmo—y el IO aleatorio no se volvió barato. Mientras tanto, el resilver rara vez es IO puramente secuencial. A menudo es “lecturas con muchos seeks + cálculo de paridad + recorridos de metadatos”, especialmente en pools ocupados.

Las cargas se volvieron más ruidosas

Virtualización, contenedores, pipelines de CI y sistemas generadores de logs crean patrones de IO que son lo opuesto a “agradables”. ZFS puede manejar mucho, pero un RAIDZ1 degradado bajo IO aleatorio mixto es donde descubres la diferencia entre “funciona en un benchmark” y “funciona a las 2 a.m. un martes”.

Los discos Helium y SMR complican las suposiciones

Los discos modernos pueden ser excelentes, pero también son más diversos. Los discos SMR en particular pueden convertir un resilver en un proceso de varios días si tienes mala suerte o estás mal informado. Incluso con discos CMR, el comportamiento del firmware bajo condiciones de error puede llevar a timeouts largos.

ZFS es resiliente, pero no hace milagros

ZFS te da checksums de extremo a extremo y self-healing—cuando existe redundancia. En RAIDZ1 degradado, has cambiado temporalmente “self-healing” por “por favor, lee perfectamente”. Es un intercambio razonable para ventanas cortas. Es un mal intercambio para ventanas largas.

Hechos históricos interesantes y contexto

Los argumentos sobre almacenamiento son más viejos que la mayoría de los datos que protegemos. Algunos puntos concretos que importan para cómo se percibe RAIDZ1 hoy:

ZFS fue diseñado en Sun Microsystems con el objetivo explícito de arreglar la corrupción silenciosa de datos usando checksums y copy-on-write, no solo “mantener discos girando”.
Los problemas del write hole en RAID-5 (pérdida de energía a mitad de stripe) fueron una preocupación histórica en RAID tradicional; ZFS evita muchas de esas trampas con semántica transaccional, pero la paridad aún tiene riesgo en rebuild.
“RAID no es un backup” se volvió un cliché porque demasiadas organizaciones trataron la paridad como recuperación, no disponibilidad. El cliché existe porque sigue siendo verdad.
Las tasas de URE se hicieron famosas cuando los discos multi-terabyte convirtieron “leer todo el array durante rebuild” en un suceso normal en lugar de raro.
Las matrices enterprise cambiaron silenciosamente hacia defaults de doble paridad conforme crecieron los discos, aun cuando el marketing hablaba de “eficiencia”.
Los scrubs de ZFS son un artefacto cultural del almacenamiento basado en checksums: la idea de verificar periódicamente que el universo está íntegro, no solo esperar a que la corrupción te sorprenda.
Alineación de sector 4K (ashift) se volvió no negociable cuando los discos se alejaron de los sectores físicos de 512B; la desalineación puede quemar rendimiento y aumentar desgaste.
La expansión de RAIDZ no estuvo disponible durante años, lo que obligó a operadores a planear el ancho de vdev cuidadosamente; hoy la expansión existe en algunas implementaciones, pero aún no es “redimensionar sin consecuencias”.
Los mirrors siguieron siendo populares en entornos de alto IO porque los rebuilds son más simples y a menudo más rápidos; la paridad gana en capacidad, los mirrors ganan en indulgencia operativa.

Tres micro-historias del mundo corporativo

1) Incidente causado por una suposición errónea: “Degradado está bien, lo reemplazamos la próxima semana”

Una compañía mediana ejecutaba un pool ZFS que almacenaba artefactos de build y plantillas de VM. No era visible al cliente, así que el almacenamiento se trataba como una utilidad: importante, pero no urgente. El pool era un único vdev RAIDZ1 de HDDs grandes, dimensionado para capacidad. Funcionaba a alta utilización porque “almacenamiento sin usar es presupuesto desperdiciado”.

Un disco falló un viernes por la tarde. Saltaron las alertas, se abrió un ticket y alguien escribió la clásica nota: “Pool degradado pero funcional; reemplazo programado”. La pieza de repuesto no estaba en casa. Procurement hizo lo que hace procurement.

Durante el fin de semana, el pool siguió ocupado porque los jobs de CI no respetan tu modelo de personal. El lunes, un segundo disco no falló del todo—empezó a lanzar errores de lectura intermitentes. ZFS hizo lo posible, pero en RAIDZ1 degradado, los errores de lectura intermitentes pueden ser tan letales como una falla limpia porque el pool necesita lecturas limpias para reconstruir bloques faltantes.

El síntoma no fue dramático al principio: algunas builds empezaron a fallar de maneras raras. Algunas VMs no pudieron arrancar desde plantillas. Luego ZFS reportó errores permanentes. El equipo perdió un subconjunto de artefactos y tuvo que reconstruir plantillas desde fuentes más antiguas. El impacto no fue existencial, pero sí una semana de atención de ingeniería costosa.

La suposición equivocada no fue “los discos fallan”. La suposición equivocada fue que un pool RAIDZ1 degradado es lo bastante estable como para posponer la acción. En realidad, degradado es un estado de emergencia cuya severidad es proporcional al tiempo de resilver y a la latencia de reemplazo.

2) Optimización que salió mal: “Hagamos RAIDZ1 más ancho para mejor eficiencia”

Otra organización—más grande y con más procesos—quiso reducir el número de racks. Alguien propuso vdevs más grandes: grupos RAIDZ1 anchos para maximizar capacidad usable. En papel se veía elegante: menos vdevs, layout más simple, menos overhead.

En producción descubrieron dos problemas. Primero, la ventana de resilver se infló. Los vdevs más anchos significaban más datos totales en el vdev, más metadatos y más oportunidades para que dispositivos lentos arrastraran al grupo entero. Segundo, el rendimiento durante el resilver se desplomó con cargas mixtas; el pool permaneció en línea, pero los servicios experimentaron picos de latencia que parecían bugs de aplicación.

El problema llegó cuando un disco fue reemplazado y el resilver duró días. Durante ese tiempo, otro disco en el mismo vdev empezó a registrar muchos errores de lectura. No murió por completo, pero los reintentos hicieron que el resilver fuera aún más lento, estirando la ventana de exposición. La organización evitó la pérdida total, pero la respuesta consumió equipos múltiples y provocó un rediseño doloroso de capacidad.

Aprendieron una lección que no aparece en la matemática simple de capacidad: la eficiencia operativa vence a la eficiencia de capacidad cruda. El terabyte más barato es el que no arrastra a tu equipo on-call a una investigación de una semana.

3) Práctica aburrida pero correcta que salvó el día: scrubs, spares y reemplazo rápido

Una tercera compañía usaba ZFS para una plataforma interna moderadamente crítica: las bases de datos tenían su propia replicación, pero el pool ZFS aún importaba. Usaban RAIDZ2 para la mayoría de los pools, pero tenían un pool RAIDZ1 para workloads efímeros. La diferencia no fue heroica; fue disciplina.

Programaban scrubs y leían realmente los informes de scrub. Monitorizaban SMART, y los discos con conteos de sectores reasignados en aumento se reemplazaban temprano—antes de fallar totalmente. También mantenían spares fríos en el mismo data center, etiquetados y probados.

Cuando un disco falló, fue reemplazado en una hora, no en una semana. El resilver empezó inmediatamente, y la carga se limitó temporalmente (pausando jobs no esenciales) para acortar la ventana de resilver. El pool pasó mínimo tiempo degradado.

Ese incidente no se convirtió en historia de guerra porque fue diseñado para ser aburrido. En términos SRE, redujeron el riesgo con procesos predecibles: aviso temprano, manos rápidas y limitar el radio de impacto. No es emocionante, pero así es la “fiabilidad”.

Tareas prácticas: comandos, salidas y qué significan

A continuación hay tareas prácticas ejecutables en un sistema ZFS. Los comandos asumen OpenZFS en Linux con un pool llamado tank. Ajusta los nombres para tu entorno.

Tarea 1: Identificar layout de vdev y confirmar que realmente eres RAIDZ1

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Dec 22 03:10:12 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz1-0                  ONLINE       0     0     0
            ata-ST16000NM001G-1     ONLINE       0     0     0
            ata-ST16000NM001G-2     ONLINE       0     0     0
            ata-ST16000NM001G-3     ONLINE       0     0     0
            ata-ST16000NM001G-4     ONLINE       0     0     0

errors: No known data errors

Interpretación: Tienes un único vdev RAIDZ1 con cuatro discos. Puede fallar un disco. En modo degradado tienes margen de paridad cero.

Tarea 2: Comprobar cuánto está lleno el pool (alta utilización empeora todo)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME        USED  AVAIL  REFER  MOUNTPOINT
tank       38.2T  4.10T   192K  /tank
tank/vm    25.6T  4.10T  25.6T  /tank/vm
tank/logs  12.6T  4.10T  12.6T  /tank/logs

Interpretación: Estás cerca del 90%+ usado. Espera asignaciones más lentas, más fragmentación y resilvers más largos. Si usas RAIDZ1 tan lleno, te estás postulando voluntario para drama.

Tarea 3: Ver scrubs y resilvers recientes

cr0x@server:~$ zpool status tank | sed -n '1,12p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Dec 22 03:10:12 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0

Interpretación: El scrub completó con cero errores. Bien. Si nunca haces scrub, la primera vez que encuentres un sector malo podría ser durante el resilver—cuando RAIDZ1 no puede salvarte.

Tarea 4: Hacer scrub al pool (y entender el coste)

cr0x@server:~$ sudo zpool scrub tank

Interpretación: Los scrubs leen y verifican datos. Prográmarlos cuando el IO pueda tolerarlo. Si los scrubs consistentemente encuentran errores, eso no es “ZFS siendo quisquilloso”; es ZFS detectando lo que de otro modo sería corrupción silenciosa.

Tarea 5: Monitorizar el progreso de scrub/resilver

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Tue Dec 24 01:12:10 2025
        7.24T scanned at 1.21G/s, 3.89T issued at 664M/s, 38.2T total
        0B repaired, 10.18% done, 0 days 15:42:11 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz1-0                  ONLINE       0     0     0
            ata-ST16000NM001G-1     ONLINE       0     0     0
            ata-ST16000NM001G-2     ONLINE       0     0     0
            ata-ST16000NM001G-3     ONLINE       0     0     0
            ata-ST16000NM001G-4     ONLINE       0     0     0

Interpretación: ZFS da un ETA, pero trátalo como pronóstico del tiempo. Si la velocidad “issued” baja drásticamente en horario laboral, tu workload está compitiendo con el IO del scrub.

Tarea 6: Identificar discos y rutas persistentes de dispositivo

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'ST16000NM001G|wwn' | head
lrwxrwxrwx 1 root root  9 Dec 24 00:40 wwn-0x5000c500abcd0001 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 24 00:40 wwn-0x5000c500abcd0002 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 24 00:40 wwn-0x5000c500abcd0003 -> ../../sdd
lrwxrwxrwx 1 root root  9 Dec 24 00:40 wwn-0x5000c500abcd0004 -> ../../sde

Interpretación: Usa by-id o rutas wwn en ZFS, no /dev/sdX, que pueden cambiar entre reinicios.

Tarea 7: Reemplazar un disco fallado correctamente (no adivines nombres de dispositivo)

cr0x@server:~$ sudo zpool replace tank wwn-0x5000c500abcd0003 /dev/disk/by-id/wwn-0x5000c500beef0009

Interpretación: El primer argumento es el miembro antiguo (como ZFS lo conoce). El segundo es la ruta del disco nuevo. Después de esto, comienza el resilver. Si reemplazas el disco equivocado en RAIDZ1, puedes convertir “degradado” en “perdido”.

Tarea 8: Confirmar que el resilver arrancó y vigilar errores

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Tue Dec 24 02:02:41 2025
        1.78T scanned at 412M/s, 612G issued at 141M/s, 25.6T total
        0B resilvered, 2.34% done, 2 days 01:15:09 to go
config:

        NAME                              STATE     READ WRITE CKSUM
        tank                              DEGRADED     0     0     0
          raidz1-0                        DEGRADED     0     0     0
            ata-ST16000NM001G-1           ONLINE       0     0     0
            ata-ST16000NM001G-2           ONLINE       0     0     0
            replacing-2                   DEGRADED     0     0     0
              wwn-0x5000c500abcd0003      FAULTED      0     0     0  too many errors
              wwn-0x5000c500beef0009      ONLINE       0     0     0  (resilvering)
            ata-ST16000NM001G-4           ONLINE       0     0     0

errors: No known data errors

Interpretación: El ETA del resilver es 2 días. Esa es tu ventana de exposición. Si otro disco empieza a lanzar errores ahora, puedes perder datos. Este es el momento de reducir la carga y vigilar alertas estrechamente.

Tarea 9: Comprobar contadores de error por disco y timeouts

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

        NAME                                         STATE     READ WRITE CKSUM
        tank                                         DEGRADED     0     0     0
          raidz1-0                                   DEGRADED     0     0     0
            /dev/disk/by-id/wwn-0x5000c500abcd0001   ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500abcd0002   ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c500beef0009   ONLINE       3     0     0  (resilvering)
            /dev/disk/by-id/wwn-0x5000c500abcd0004   ONLINE       0     0     0

Interpretación: READ no cero en un disco superviviente durante el resilver es una señal roja. A veces es transitorio (cable/HBA), otras veces es un disco muriendo. Investiga inmediatamente; RAIDZ1 no perdona la demora.

Tarea 10: Obtener SMART y log de errores (Linux)

cr0x@server:~$ sudo smartctl -a /dev/sdd | sed -n '1,40p'
smartctl 7.4 2023-08-01 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     ST16000NM001G
Serial Number:    ZR123ABC
LU WWN Device Id: 5 000c50 0abcd0003
Firmware Version: SN03
User Capacity:    16,000,900,169,728 bytes [16.0 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!

Interpretación: Si SMART dice FAILED, trátalo como “expulsa este disco”. Algunos discos cojean por meses; otros caen en picada. Tu ventana de rebuild no es el momento para debatir optimismo.

Tarea 11: Ver propiedades del dataset que afectan resilver y rendimiento

cr0x@server:~$ zfs get -o name,property,value -s local,default recordsize,compression,atime,sync tank/vm
NAME     PROPERTY     VALUE
tank/vm  recordsize   128K
tank/vm  compression  lz4
tank/vm  atime        off
tank/vm  sync         standard

Interpretación: lz4 suele ayudar (menos IO físico). atime=off reduce ruido de escrituras. Recordsize influye en patrones de IO; desajustes pueden amplificar IO aleatorio en RAIDZ.

Tarea 12: Comprobar I/O y latencias del pool con iostat

cr0x@server:~$ zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        38.2T  4.10T    210   1200  92.1M   410M
  raidz1-0                  38.2T  4.10T    210   1200  92.1M   410M
    wwn-0x5000c500abcd0001      -      -     55    310  24.0M   110M
    wwn-0x5000c500abcd0002      -      -     48    295  21.2M   105M
    wwn-0x5000c500beef0009      -      -     60    300  25.1M   100M
    wwn-0x5000c500abcd0004      -      -     47    295  21.8M    95M
--------------------------  -----  -----  -----  -----  -----  -----

Interpretación: Muestra la distribución entre discos. Si uno muestra mucho menor ancho de banda o ops muy altas, puede estar lento, reintentando o comportándose mal. Durante resilver verás asimetría; la asimetría extrema es una pista.

Tarea 13: Detectar si haces suposiciones inseguras de cacheo de escritura

cr0x@server:~$ sudo hdparm -W /dev/sdb | head -n 2
/dev/sdb:
 write-caching =  1 (on)

Interpretación: Write cache activado en HDDs es normal, pero sin protección contra pérdida de energía puede convertir un evento de energía en un desastre. ZFS mitiga algunos problemas, pero el hardware puede fallar bajo estrés. Si necesitas garantías estrictas, diseña para ellas.

Tarea 14: Comprobar ashift (alineación de sectores) del pool

cr0x@server:~$ sudo zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
38:        vdev_tree:
57:            ashift: 12

Interpretación: ashift=12 significa sectores 4K. Si creaste un pool con ashift=9 en discos 4K, puedes sufrir caídas de rendimiento y amplificación extra de escritura. Arreglarlo suele significar reconstruir el pool.

Tarea 15: Buscar errores de datos tras un evento preocupante

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: resilvered 25.6T in 2 days 03:12:44 with 0 errors on Thu Dec 26 05:15:25 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz1-0                  ONLINE       0     0     0
            ata-ST16000NM001G-1     ONLINE       0     0     0
            ata-ST16000NM001G-2     ONLINE       0     0     0
            ata-ST16000NM001G-NEW   ONLINE       0     0     0
            ata-ST16000NM001G-4     ONLINE       0     0     0

errors: No known data errors

Interpretación: “0 errors” es lo que quieres ver. Si ves “permanent errors”, no lo minimices—lista los ficheros afectados, evalúa el radio de impacto y restaura desde backup si es necesario.

Playbook de diagnóstico rápido (encuentra el cuello de botella)

Este es el playbook que uso cuando alguien pregunta: “El resilver va lento” o “el pool RAIDZ1 está lento”. El objetivo no es volverse un poeta del rendimiento; es encontrar el factor limitante en minutos.

Primero: confirma el estado del pool y qué está haciendo ZFS

cr0x@server:~$ zpool status -v tank

Mira: DEGRADED, resilver in progress, errores read/write/cksum por dispositivo y mensajes de “too many errors”.

Segundo: identifica si el cuello de botella es un dispositivo malo o contención general

cr0x@server:~$ zpool iostat -v tank 1 10

Interpretación: Si un disco es dramáticamente más lento o muestra errores, probablemente tengas un problema de dispositivo/cable/HBA. Si todos los discos están ocupados y el throughput es bajo, puede que estés dominado por IO aleatorio o overhead de paridad bajo carga.

Tercero: comprueba la presión de IO a nivel sistema y colas

cr0x@server:~$ iostat -x 1 10

Mira: alto %util, alto await, colas grandes. Si la latencia explota durante el resilver, limita cargas o ajusta prioridades—RAIDZ1 degradado no es momento de “full send”.

Cuarto: comprueba presión de memoria obvia (thrash del ARC) y saturación de CPU

cr0x@server:~$ free -h
cr0x@server:~$ top -b -n 1 | head -n 20

Interpretación: Si estás haciendo swap, ZFS se sentirá mal. Si la CPU está al 100%, la aritmética de paridad más compresión y checksumming bajo carga pueden ser el limitante.

Quinto: confirma que el “disco lento” no está negociando mal

cr0x@server:~$ sudo dmesg | grep -Ei 'ata|sas|reset|link|error|timeout' | tail -n 30

Interpretación: Resets de enlace, timeouts y abortos de comando suelen aparecer aquí antes de ver un fallo completo. En modo degradado trata esto como alarma de incendio, no como vibra.

Sexto: si aún no está claro, mide workload real vs resilver

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

Interpretación: El desglose por tamaño de petición puede revelar que estás atascado haciendo lecturas pequeñas aleatorias (fragmentación, cargas VM) en vez de streaming.

Errores comunes con síntomas específicos y soluciones

Error 1: Tratar RAIDZ1 degradado como “suficientemente estable”

Síntomas: Un disco falla, se abre ticket, reemplazo retrasado; días después aparecen errores en el segundo disco; el resilver ni siquiera ha empezado; aparecen errores de datos durante la reconstrucción eventual.

Solución: Define un SLA de reemplazo (horas, no días). Mantén spares probados. Automatiza paging para DEGRADED. Reduce la carga inmediatamente cuando estés degradado.

Error 2: Ejecutar pools demasiado llenos

Síntomas: Scrubs/resilvers tardan mucho más conforme sube la utilización; picos de latencia; fallos de asignación; “todo está lento” sin un culpable claro.

Solución: Planifica capacidad con margen (práctico: mantén bien por debajo del precipicio). Si debes correr caliente, no uses RAIDZ1; elige redundancia que tolere estrés.

Error 3: No hacer scrubs (o ignorar los scrubs)

Síntomas: El primer scrub en meses encuentra checksum errors; un resilver posterior falla con permanent errors; “pero el pool estaba ONLINE ayer”.

Solución: Programa scrubs. Alerta sobre errores de scrub. Reemplaza discos que muestren tendencias de error en aumento aunque “siguen online”.

Error 4: Mezclar tipos de disco sin pensar (sorpresas SMR)

Síntomas: La velocidad de resilver va bien al principio y luego colapsa; discos muestran tiempos de comando largos; rebuild tarda mucho más de lo esperado.

Solución: Evita SMR en RAIDZ a menos que hayas validado específicamente su comportamiento en resilver. Estandariza modelos de disco y firmware en un vdev.

Error 5: Usar nombres de dispositivo inestables

Síntomas: Tras un reboot, ZFS importa con diferente mapeo /dev/sdX; el operador reemplaza “sdc” pero no es el disco previsto; el pool empeora.

Solución: Construye y opera siempre usando /dev/disk/by-id o identificadores WWN. Verifica números de serie físicamente y vía SMART.

Error 6: Sobre-optimizar recordsize/sync sin pruebas de workload

Síntomas: Cambios de tuning parecen mejorar benchmarks, pero en producción hay más latencia, más fragmentación, resilvers más lentos.

Solución: Trata el tuning como experimento con rollback. Mantén defaults a menos que puedas explicar por qué tu workload es distinto—y mide antes/después.

Error 7: Creer que la paridad equivale a backup

Síntomas: El pool sobrevive a una pérdida de disco, el equipo se relaja; más tarde ransomware/eliminación accidental; no existe una copia limpia.

Solución: Mantén backups reales o snapshots replicados fuera del sitio. RAIDZ es disponibilidad, no recuperación ante errores humanos.

Listas de verificación / plan paso a paso

Checklist A: ¿Deberías usar RAIDZ1 en absoluto?

Clasifica los datos. Si perderlos desencadena pérdida de ingresos, incumplimiento contractual o recuperación de varios días, descarta RAIDZ1 por defecto.
Estima el tiempo de resilver desde la realidad. Mira tu última duración de scrub; resilvers bajo carga no serán más rápidos.
Confirma la logística de reemplazo. ¿Tienes un repuesto on-site? ¿Alguien autorizado para cambiarlo inmediatamente?
Evalúa la utilización. Si vas caliente, RAIDZ1 no es la elección “eficiente”; es la elección “frágil”.
Decide tu ventana de exposición tolerable. Si tu organización no tolera varios días de “un error más y estamos fritos”, no elijas RAIDZ1.

Checklist B: Cuando un disco falla en RAIDZ1 (minuto a minuto)

Confirma que es un problema real del dispositivo.
```
cr0x@server:~$ zpool status -v tank
cr0x@server:~$ sudo dmesg | tail -n 80
```
Decisión: Si ves timeouts/resets, revisa cableado/HBA también—reemplazar un disco sano no arreglará un enlace malo.
Reduce la carga. Pausa jobs por lotes, reduce churn de VM y detén escrituras pesadas si es posible. El objetivo es acortar el resilver y evitar errores inducidos por estrés.
Identifica el disco físico.
```
cr0x@server:~$ sudo smartctl -a /dev/disk/by-id/wwn-0x5000c500abcd0003 | grep -E 'Serial|SMART overall|Reallocated|Pending'
```
Decisión: Empareja números de serie con etiquetas del chasis. No confíes en folklore de “slot 3” a menos que lo hayas validado.

Reemplaza inmediatamente usando IDs estables.

cr0x@server:~$ sudo zpool replace tank wwn-0x5000c500abcd0003 /dev/disk/by-id/wwn-0x5000c500beef0009

Monitoriza resilver y errores continuamente.
```
cr0x@server:~$ watch -n 10 'zpool status -v tank'
```
Decisión: Si otro disco empieza a fallar, prepárate para escalar: reemplaza discos sospechosos, revisa HBA y considera mover la carga fuera del pool.
Después de la finalización, haz scrub pronto.
```
cr0x@server:~$ sudo zpool scrub tank
```
Decisión: Verifica que el pool esté limpio y que no se introdujeron errores permanentes.

Checklist C: Prácticas “aburridas” de fiabilidad que hacen RAIDZ1 menos aterrador

Programación de scrub alineada con la carga del negocio y el tamaño del pool; alerta sobre bytes reparados o checksum errors.
Monitorización SMART con umbrales para sectores reasignados/pending y logs de error.
Repuestos on-site que estén quemados y etiquetados.
Runbook documentado de reemplazo incluyendo identificación de dispositivo y pasos de rollback.
Política de margen (no operar pools al borde).
Pruebas de restauración desde backups/snapshots. RAID no es tu plan de recuperación.

FAQ

1) ¿Es RAIDZ1 “inseguro”?

No inherentemente. Es menos indulgente. Si puedes mantener ventanas de resilver cortas y reemplazos rápidos, puede ser razonable para datos no críticos. Si tu ventana de resilver se mide en días, RAIDZ1 es un riesgo que deberías tratar como cualquier otra exposición operacional de alto impacto.

2) ¿Por qué el riesgo de RAIDZ1 aumenta con discos más grandes?

Porque las reconstrucciones requieren leer mucha información de los discos supervivientes, y discos más grandes implican más datos que leer y más tiempo degradado. Más tiempo y más lecturas aumentan la probabilidad de encontrar un segundo modo de fallo (otro disco, errores de lectura, timeouts).

3) ¿RAIDZ2 siempre es mejor?

Para fiabilidad durante el estrés del rebuild, sí: la doble paridad te da margen durante un resilver. Pero “mejor” incluye trade-offs: más overhead de paridad, diferentes características de rendimiento y a veces planificación de capacidad más compleja. Para muchos pools de producción, RAIDZ2 es el default porque los resultados operacionales importan más que los TB utilizables crudos.

4) Mirrors vs RAIDZ: ¿cuál es más seguro?

Los mirrors suelen ser operativamente más seguros porque los rebuilds pueden ser más simples y rápidos, y el rendimiento bajo IO aleatorio suele ser mejor. RAIDZ puede ser excelente para workloads orientados a capacidad y throughput. Si ejecutas IO aleatorio de VM en discos giratorios, los mirrors frecuentemente se comportan mejor bajo estrés.

5) ¿ZFS resilveriza todo el disco?

Usualmente resilveriza solo bloques asignados (lo cual es bueno), pero pools fragmentados y ciertos escenarios aún pueden crear rebuilds largos y con mucha IO. El consejo práctico sigue siendo: mide tu tiempo real de resilver en tu workload, no en teoría.

6) Si hago scrubs regularmente, ¿eso elimina el riesgo de rebuild en RAIDZ1?

No, pero lo reduce. Los scrubs sacan a la luz errores latentes temprano, cuando todavía tienes paridad. Eso significa que puedes arreglar problemas antes de estar degradado. Los scrubs no evitan que un segundo disco falle durante el resilver, ni hacen desaparecer timeouts/cableado.

7) ¿Cuál es la forma más sencilla de reducir riesgo de RAIDZ1 sin rediseñar todo?

Acorta la ventana de exposición y mejora la respuesta: ten spares probados on-site, alerta fuerte en DEGRADED, y un procedimiento de reemplazo ensayado. Además, mantén margen; pools muy llenos resilverizan más lento y son más frágiles bajo carga.

8) ¿Cómo sé si mi pool está a un error de pérdida de datos?

Si es RAIDZ1 y el pool está degradado, ya estás allí. Revisa con zpool status -v. Cualquier error de lectura adicional en discos restantes durante el resilver es una escalada seria—investiga hardware y considera reemplazar proactivamente discos cuestionables.

9) ¿Puedo “convertir” RAIDZ1 a RAIDZ2 in-place?

En muchas implementaciones, no de la forma que la gente espera. Algunas características de expansión existen en ecosistemas modernos de OpenZFS, pero cambiar el nivel de paridad típicamente no es un flip trivial. La ruta operativa común es migrar datos a un pool nuevo con la topología deseada.

10) ¿Cuál es un caso de uso realista para RAIDZ1 hoy?

Datos no críticos, reproducibles o bien replicados; entornos con manos rápidas y repuestos; tamaños de disco más pequeños; o cuando el pool es una capa de cache y no la fuente de la verdad. Si el pool es tu única copia de datos importantes, RAIDZ1 debería ponerte incómodo—y eso es una señal útil.

Conclusión: elegir RAIDZ1 con los ojos abiertos

La reputación de RAIDZ1 oscila entre “totalmente bien” y “nunca lo uses”, y ambos extremos fallan en el punto. La verdadera historia es la ventana de rebuild: cuánto tiempo estás degradado, cuánto debes leer para recuperar y cuán probable es que el entorno genere un segundo modo de fallo mientras estás expuesto.

Si haces el cálculo—de verdad lo haces, con tus tiempos reales de scrub, tu utilización real, tu proceso real de reemplazo—RAIDZ1 a menudo deja de ser un valor por defecto y se convierte en una elección deliberada. A veces sigue siendo la elección correcta. Pero cuando no lo es, lo sabrás antes de que el pager te lo enseñe a las 3 a.m.