ZFS RAIDZ3: cuándo la triple paridad compensa los discos

enero 9, 2026 • febrero 3, 2026 • Lectura: 32 min • Views: 10

¿Te fue útil?

RAIDZ3 es el “tercer cinturón de seguridad” de ZFS: paridad triple dentro de un vdev RAIDZ. Te cuesta la capacidad equivalente a un disco extra frente a RAIDZ2, y te compra un margen de seguridad mayor exactamente cuando estás más expuesto: durante reconstrucciones largas en discos grandes, bajo carga real, con el tipo de errores de sector latentes que solo aparecen cuando ya estás teniendo un mal día.

Si nunca has perdido un pool durante un resilver, RAIDZ3 puede parecer exagerado. Si lo has perdido, RAIDZ3 se siente como la única vez que finanzas aprueba una póliza de seguro que realmente paga. Este texto trata de tomar esa decisión sin dogmas, con números razonables y con comandos que puedes ejecutar a las 3 a.m. cuando el pager suena más fuerte que tu confianza.

Qué es realmente RAIDZ3 (y qué no)

En términos de ZFS, RAIDZ es RAID con paridad implementado a nivel de vdev. Un vdev RAIDZ3 puede perder cualquier tres discos en ese vdev y seguir sirviendo datos. Lo hace almacenando tres bloques de paridad independientes por cada franja RAIDZ (conceptualmente similar a variantes de RAID-7/RAID-6, pero ZFS lo implementa con ancho de franja variable y semántica copy-on-write).

Qué es:

Protección con triple paridad por vdev. Pierdes tres discos en el mismo vdev RAIDZ3 y sigues online. Pierdes cuatro, recuperas desde backups y practicas la humildad.
Diseñado para ventanas de reconstrucción largas y modos de fallo del mundo real: segundos (y terceros) fallos de disco durante el resilver, y errores de medios latentes descubiertos por lecturas completas del disco.
Operativamente simple comparado con diseños más exóticos. El on-call obtiene un conjunto familiar de comandos y comportamiento ante fallos.

Qué no es:

No sustituye a las copias de seguridad. RAIDZ3 reduce la probabilidad de perder un pool por fallos múltiples; no te protege contra borrados, ransomware, bugs de aplicación o “pensé que estaba en staging”.
No es una panacea de rendimiento. Puede ser rápido para lecturas/escrituras secuenciales, pero las escrituras aleatorias pequeñas pagan un impuesto de paridad. Ese impuesto no es teórico; es el sonido de tus SLOs de latencia tosiendo.
No es “configúralo y olvídalo”. Aún necesitas scrubs, monitorización SMART, burn-in y procedimientos de reemplazo sensatos.

Un chiste, porque la gente de almacenamiento también merece alegría: RAIDZ3 es como llevar casco en un carril bici: pareces paranoico hasta la única vez que no lo estás.

Hechos e historia que importan

Aquí hay algunos puntos breves y concretos que realmente influyen en cómo planificas un pool RAIDZ3:

ZFS se construyó alrededor de sumas de comprobación de extremo a extremo (datos + metadata), haciendo que la corrupción silenciosa sea detectable y reparable cuando existe redundancia.
RAIDZ se creó para evitar el “write hole” común en controladoras RAID5/6 clásicas ante pérdida de energía, usando semántica copy-on-write transaccional.
Las capacidades de disco han crecido más rápido que las IOPS durante dos décadas. Tu ventana de reconstrucción está limitada en gran parte por I/O, no por cuánto deseas con más ganas.
Existen tasas de URE aunque los fabricantes no quieran hablar. En discos grandes, la probabilidad de encontrar un sector ilegible durante una lectura completa no es fantasía; es aritmética.
Los scrubs se volvieron operacionalmente “obligatorios” en la cultura ZFS porque sacan a la luz errores latentes antes de que un resilver te obligue a leer todo en el peor momento posible.
Advanced Format (4K) cambió el coste del desalineamiento. Un ashift incorrecto puede convertir “bien” en “¿por qué va tan lento?” para siempre.
Los discos SMR llegaron a la corriente principal y volvieron a poner el comportamiento de reconstrucción como criterio de compra. Un resilver que tarda una eternidad no es un resilver; es un ensayo extendido de outage.
La empresa abrazó “dominios de fallo” (rack, bandeja, expander, HBA) y dejó de pensar en “fallo de disco” como un evento aislado. La triple paridad trata en parte de fallos correlacionados.

Por qué existe la triple paridad: matemáticas de fallo que se sienten

La gente a veces enmarca RAIDZ3 como “para personas que no confían en los discos”. No es del todo eso. RAIDZ3 es para personas que entienden que el tiempo es el enemigo.

El pool está más seguro justo después de que un scrub termina y todos los discos están sanos. El pool está más vulnerable durante un resilver, cuando:

Cada disco está siendo leído intensamente (o al menos más de lo habitual), que es cuando los discos marginales muestran su verdadera personalidad.
Estás funcionando degradado—lo que significa que tu presupuesto de redundancia ya está gastado.
Suele mantenerse carga de producción, así que los picos de latencia aparecen, las colas se forman y el “I/O de fondo” se convierte en “dolor de primer plano”.

Con RAIDZ1, un segundo fallo durante el resilver mata el vdev. Con RAIDZ2, un tercer fallo puede hacerlo. Con RAIDZ3, puedes sobrevivir ese tercer fallo y mantener el pool vivo el tiempo suficiente para reemplazar hardware sin una fiesta de restauración a medianoche.

Pero el verdadero impulsor no es solo “otro disco falla”. Es “algo se vuelve ilegible cuando debemos leerlo”. ZFS es muy bueno detectando datos malos. La redundancia es lo que convierte “detectar” en “reparar”. La triple paridad te da más margen para que esa reparación tenga éxito cuando el resilver está leyendo todo el mundo.

Los verdaderos compromisos: capacidad, rendimiento, coste operativo

Capacidad: el coste obvio

En un vdev RAIDZ3 único con N discos del mismo tamaño, la capacidad utilizable es aproximadamente (N − 3) discos equivalentes (menos un poco para metadata de ZFS y espacio libre). Eso significa:

8 discos en RAIDZ3: utilizable ≈ capacidad de 5 discos
12 discos en RAIDZ3: utilizable ≈ capacidad de 9 discos
16 discos en RAIDZ3: utilizable ≈ capacidad de 13 discos

RAIDZ3 se vuelve más fácil de justificar conforme crece el ancho del vdev—porque la sobrecarga de paridad es una fracción menor del total. La trampa: vdevs RAIDZ más anchos aumentan el tiempo de reconstrucción y pueden aumentar el radio de impacto de problemas correlacionados si tu chasis/ruta HBA es un único dominio de fallo. La ingeniería nunca es comida gratis; es más bien un buffet donde todo tiene sodio oculto.

Rendimiento: impuesto de paridad, pero no uniforme

La carga importa más que el nivel de paridad. RAIDZ3 tiende a ser:

Excelente en lecturas secuenciales (muchos discos participan).
Buena en escrituras secuenciales cuando los registros están bien alineados y no hay comportamiento síncrono patológico.
No muy buena en escrituras aleatorias pequeñas, porque RAID de paridad requiere leer/modificar/escribir franjas a menos que hagas escrituras de franja completa.

La paridad triple puede aumentar un poco la sobrecarga de CPU (cálculo de paridad), pero en sistemas modernos las limitaciones dominantes suelen ser los discos, la profundidad de cola y la amplificación de escritura—no la aritmética XOR. Aún así, no construyas un pool RAIDZ3 en una CPU infra-potenciada y luego te sorprendas cuando las sumas de comprobación y la compresión compitan con la paridad a alto rendimiento.

Coste operacional: la parte que nadie presupuestó

RAIDZ3 cambia cómo operas porque cambia lo que parece “riesgo aceptable”. En la práctica puede permitirte:

Resilver durante horas de trabajo sin aguantar la respiración tanto.
Usar discos más grandes sin fingir que las reconstrucciones siguen siendo de 6 horas como en 2012.
Ejecutar vdevs más anchos sin vivir con miedo constante al tercer fallo.

Pero también puede tentar a los equipos a comportarse de forma descuidada: posponer scrubs, ignorar advertencias SMART o funcionar demasiado lleno porque “tenemos RAIDZ3”. Así es como los diseños robustos se vuelven frágiles en producción: no porque las matemáticas estuvieran mal, sino porque los humanos se acomodaron.

Cuándo RAIDZ3 merece los discos

RAIDZ3 es buena idea cuando el coste del downtime o de la restauración es alto, y la probabilidad de “múltiples problemas durante la reconstrucción” no es trivial. Aquí situaciones donde lo he visto acertar:

1) Discos muy grandes y ventanas de resilver largas

Si tus resilvers tardan días, no horas, tu ventana de exposición es lo bastante larga como para que “dos cosas salen mal” deje de ser un evento raro. RAIDZ3 está básicamente comprando un margen más amplio para la dimensión temporal.

2) Repositorios de archivo o backup de alta capacidad

Irónicamente, el almacenamiento de backups a menudo necesita más redundancia que el primario. ¿Por qué? Porque los sistemas de backup se someten a muchísima presión durante las restauraciones—justo cuando no te puedes permitir que el pool colapse. Además, los backups suelen construirse con discos enormes y vdevs anchos para optimizar $/TB, lo que incrementa el tiempo de reconstrucción.

3) Pools con riesgo conocido de fallos correlacionados

Ejemplos: una bandeja JBOD única, un expander único, un lote de discos del mismo periodo de fabricación, o entornos con vibración/temperatura problemática. RAIDZ3 no arregla fallos correlacionados, pero te da margen para manejarlos sin convertir el incidente en desastre.

4) Entornos “sin manos” donde el reemplazo no es inmediato

Sitios remotos, laboratorios, despliegues edge o cualquier cosa donde un humano no puede cambiar un disco en una hora. Si tu tiempo medio para reemplazo se mide en días, la paridad es barata comparada con la realidad operativa.

5) Objetivos de durabilidad impulsados por cumplimiento

Si tienes requisitos internos como “dos fallos concurrentes más un error latente no deben causar pérdida de datos”, RAIDZ3 es una de las formas más sencillas de lograrlo sin construir esquemas complejos de replicación entre pools (que quizá igualmente hagas, pero al menos el pool local no estará a una mala semana de una restauración).

Cuándo RAIDZ3 es la respuesta equivocada

La triple paridad no es una insignia de honor. Es un intercambio. Evita RAIDZ3 cuando:

Necesitas IOPS de escritura aleatoria pequeñas más que eficiencia de capacidad

Bases de datos, almacenamiento de VM y sistemas sensibles a latencia suelen preferir mirrors (y a veces vdevs especiales) en lugar de RAIDZ ancho. RAIDZ3 funcionará, pero a menudo será la opción más lenta aceptable y a veces inaceptable.

Puedes reducir tu riesgo mejor con replicación

Si ya tienes replicación rápida y probada a otro sistema y puedes tolerar perder un pool sin perder datos, gastar tres discos en paridad puede ser menos valioso que usar esos discos para un segundo pool o un destino de réplica. La frase clave es “probada”. La replicación no probada es un cuento para dormir, no un plan de recuperación ante desastres.

Te tientas a construir un vdev único y masivo porque RAIDZ3 da seguridad

Un vdev enorme puede estar bien, pero concentra riesgo en un dominio de fallo. RAIDZ3 lo hace más sobrevivible, no invencible. Si estás construyendo “el pool que lo controla todo”, considera si varios vdevs o varios pools con replicación encajan mejor con tu modelo de fallo.

Ancho de vdev, ashift, recordsize: decisiones de diseño que deciden resultados

Ancho de vdev: 8–16 discos es donde los argumentos se vuelven reales

RAIDZ3 suele aparecer en anchos como 10, 11, 12, 14, 16 discos. Vdevs más anchos significan:

Más capacidad utilizable por disco de paridad (la fracción de sobrecarga de paridad baja).
Mayor potencial de throughput secuencial (más spindles participan).
Resilvers y scrubs más largos (más datos que leer, más discos involucrados).

Una heurística práctica: si eliges RAIDZ3, ya estás señalando que el riesgo de resilver importa. No elijas luego un ancho extremo que haga los resilvers insoportablemente largos a menos que tengas una razón operacional fuerte (y una historia de monitorización).

ashift: configúralo bien una vez, o arrepiéntete para siempre

ashift controla la alineación de sectores del pool. Los discos modernos son efectivamente de 4K incluso si fingen lo contrario. La mayoría de los pools de producción deberían usar ashift=12 (4K). Algunos entornos usan dispositivos con sectores de 8K o 16K, pero la clave es: elige correctamente según tu hardware y no dejes que ZFS adivine en un entorno mixto.

No puedes cambiar ashift tras la creación. Solo puedes migrar.

recordsize y volblocksize: ajusta al workload

Para datasets de archivos, recordsize afecta cómo ZFS trocea los datos. Recordsize mayor ayuda a cargas secuenciales y reduce la sobrecarga de metadata. Para zvols (dispositivos de bloque), volblocksize debe elegirse en la creación y alinearse con la aplicación (a menudo 8K–64K según patrones DB/VM).

Las penalizaciones de paridad en RAIDZ son peores cuando fuerzas escrituras parciales de franja repetidamente. Puedes mitigar eso mediante:

Usar tamaños de registro apropiados para tu carga.
Habilitar compresión para reducir escrituras físicas (a menudo una ganancia neta).
Evitar escrituras sync patológicas a menos que lo hayas diseñado (SLOG, presupuesto de latencia).

Operaciones prácticas: comandos, interpretaciones y qué significa “bueno”

Abajo hay tareas prácticas que espero que un SRE on-call o ingeniero de almacenamiento pueda ejecutar en un pool RAIDZ3. Cada comando aquí es algo que puedes ejecutar. Las interpretaciones son la parte que evita “corrí comandos y sigo confundido”.

Tarea 1: Confirmar el layout del pool (y verificar que sea realmente RAIDZ3)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 04:12:33 with 0 errors on Mon Dec 23 02:11:10 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz3-0                  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d5  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d6  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d7  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d8  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d9  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3da  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3db  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3dc  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3dd  ONLINE       0     0     0

errors: No known data errors

Interpretación: Busca la línea raidz3-0. Si dice raidz2-0 o raidz-0, no tienes triple paridad, sin importar lo que diga la wiki. También nota los identificadores de dispositivo: usar wwn-* es buena práctica; evita sorpresas por renumeración de dispositivos.

Tarea 2: Mostrar salud de un vistazo (vigila degradación silenciosa)

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,capacity,health
NAME  SIZE   ALLOC  FREE  FRAG  CAPACITY  HEALTH
tank  145T   92.1T  52.9T  21%  63%       ONLINE

Interpretación: Capacidad y fragmentación importan. Pools RAIDZ que funcionan llenos (80–90%) suelen sufrir ineficiencia de asignación y acantilados de rendimiento. RAIDZ3 no cambia esa física. Si estás por encima de ~80%, espera que las escrituras sean más explosivas y los scrubs tarden más.

Tarea 3: Comprobar ashift (alineación) en el vdev

cr0x@server:~$ zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
56:        vdev_tree:
88:            ashift: 12

Interpretación: ashift: 12 suele indicar alineación a 4K. Si ves ashift: 9 en discos 4K modernos, puedes estar pagando una penalización permanente. Arreglarlo implica reconstruir el pool y migrar datos.

Tarea 4: Iniciar un scrub (y confirmar que avanza)

cr0x@server:~$ sudo zpool scrub tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Tue Dec 24 01:02:18 2025
        3.21T / 92.1T scanned at 1.10G/s, 1.02T / 92.1T issued at 350M/s, 78.90T total
        0B repaired, 1.11% done, 3 days 01:20:11 to go
config:
...

Interpretación: Fíjate en el throughput issued, no solo en scanned. Si issued es bajo, ZFS probablemente esté limitado por contención de carga, errores de dispositivo o discos lentos. Un ETA de scrub de días es normal en pools grandes, pero cambios repentinos en la tasa pueden señalar un problema.

Tarea 5: Encontrar qué discos están lanzando errores

cr0x@server:~$ zpool status -v tank
...
            wwn-0x5000c500a1b2c3d8  ONLINE       0     2     0
            wwn-0x5000c500a1b2c3dc  ONLINE       4     0     0
...

Interpretación: Contadores READ/WRITE/CKSUM no cero no son “están bien” solo porque el pool esté ONLINE. Para RAIDZ, pueden ocurrir algunos errores transitorios (cables, fallos de expander), pero errores repetidos en un disco son una advertencia temprana. Correlaciona con SMART y logs del kernel antes de decidir si es medio, ruta o controlador.

Tarea 6: Correlacionar errores ZFS con logs del kernel

cr0x@server:~$ sudo dmesg -T | egrep -i 'sd[a-z]|sas|ata|reset|abort|I/O error' | tail -n 30
[Mon Dec 23 21:44:02 2025] sd 6:0:12:0: [sdl] tag#211 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK
[Mon Dec 23 21:44:02 2025] sd 6:0:12:0: [sdl] tag#211 CDB: Read(16) 88 00 00 00 00 00 1a 2b 3c 40 00 00 00 80 00 00
[Mon Dec 23 21:44:02 2025] blk_update_request: I/O error, dev sdl, sector 439041088

Interpretación: “Soft errors” y resets pueden ser un enlace inestable. Los errores de medio suelen mostrarse como fallos consistentes de LBA en el mismo disco. Si varios discos en la misma línea HBA muestran resets, sospecha cableado, expander o firmware.

Tarea 7: Comprobar SMART en un disco sospechoso

cr0x@server:~$ sudo smartctl -a /dev/sdl | egrep -i 'Model|Serial|Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|SMART overall'
Model Family:     Seagate Exos
Device Model:     ST16000NM000J
Serial Number:    ZL0ABC12
SMART overall-health self-assessment test result: PASSED
Reallocated_Sector_Ct     0
Current_Pending_Sector    3
Offline_Uncorrectable     3
UDMA_CRC_Error_Count      0

Interpretación: “PASSED” no es un certificado de salud limpio. Sectores pendientes y offline-uncorrectable son señales rojas, especialmente durante scrub/resilver. Si los errores CRC aumentan, sospecha cableado/backplane. Si pending/offline son distintos de cero y están aumentando, planifica un reemplazo.

Tarea 8: Reemplazar un disco fallado usando identificadores estables

cr0x@server:~$ zpool status tank | grep -E 'DEGRADED|FAULTED|OFFLINE|UNAVAIL'
 state: DEGRADED

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

Interpretación: Usa rutas /dev/disk/by-id (WWN) en lugar de /dev/sdX. Después de emitir zpool replace, observa el progreso del resilver. Si cambiaste en la bahía equivocada y reemplazaste un disco bueno, RAIDZ3 puede salvarte—pero no lo trates como una característica.

Tarea 9: Monitorizar resilver y confirmar que no se está atascando silenciosamente

cr0x@server:~$ watch -n 10 'zpool status tank | sed -n "1,25p"'
Every 10.0s: zpool status tank

  pool: tank
 state: DEGRADED
  scan: resilver in progress since Tue Dec 24 03:18:11 2025
        12.4T scanned at 780M/s, 3.10T issued at 196M/s, 92.1T total
        3.09T resilvered, 3.37% done, 1 day 19:02:10 to go
...

Interpretación: Un resilver que muestra progreso en scanned pero apenas aumenta issued puede significar contención o errores. Si la ETA empieza a crecer sin cambios de carga, investiga espera de I/O, discos lentos o un dispositivo que se resetea repetidamente.

Tarea 10: Identificar los principales contribuyentes de latencia a nivel de bloque

cr0x@server:~$ iostat -x 5 3
Linux 6.8.0 (server)   12/24/2025  _x86_64_  (32 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          12.1  0.0    4.3     21.7     0.0    61.9

Device            r/s   w/s   rkB/s   wkB/s  await  svctm  %util
sda              1.2   12.3   44.1    981.2   8.9    0.9    15.2
sdl             84.0   10.1  9032.0   1048.0  94.7    1.2    99.8
sdm             79.2    9.8  8900.0   1002.0  11.1    1.1    86.7

Interpretación: %util cerca del 100% con await alto en un solo disco (aquí sdl) es un síntoma clásico de “un disco está ralentizando el vdev”. El rendimiento RAIDZ está limitado por el participante más lento durante operaciones de paridad. Investiga SMART y la estabilidad del enlace de ese disco.

Tarea 11: Comprobar propiedades de datasets ZFS que afectan el comportamiento RAIDZ

cr0x@server:~$ zfs get -o name,property,value -s local,received recordsize,compression,atime,sync,logbias tank/data
NAME       PROPERTY     VALUE
tank/data  recordsize   1M
tank/data  compression  zstd
tank/data  atime        off
tank/data  sync         standard
tank/data  logbias      latency

Interpretación: Un recordsize de 1M puede ser excelente para cargas de medios/backup. La compresión a menudo ayuda en RAID de paridad al reducir escrituras físicas. sync=standard suele ser correcto; forzar sync=always sin un SLOG diseñado puede hacer que la latencia de escrituras explote.

Tarea 12: Ver comportamiento I/O de ZFS en tiempo real (y detectar workloads limitados por paridad)

cr0x@server:~$ sudo zpool iostat -v tank 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        92.1T  52.9T    420   1200  1.8G   310M
  raidz3-0                  92.1T  52.9T    420   1200  1.8G   310M
    wwn-...c3d4                 -      -     42    118   180M   31.0M
    wwn-...c3d5                 -      -     41    120   176M   30.8M
    wwn-...c3d6                 -      -     43    117   182M   31.1M
    wwn-...c3d7                 -      -     40    121   171M   30.9M
    wwn-...c3d8                 -      -     38    125   160M   31.5M
    wwn-...c3d9                 -      -     44    119   186M   30.7M
    wwn-...c3da                 -      -     42    120   180M   31.0M
    wwn-...c3db                 -      -     43    118   183M   30.9M
    wwn-...c3dc                 -      -     44    121   185M   31.2M
    wwn-...c3dd                 -      -     43    121   182M   31.2M
--------------------------  -----  -----  -----  -----  -----  -----

Interpretación: Un balance de ancho por disco es lo que quieres. Si unos pocos discos muestran mucho menor throughput (o latencia mucho mayor en iostat -x), tu queja de “RAIDZ3 es lento” puede ser en realidad “un disco está mal y el vdev espera educadamente por él”.

Tarea 13: Verificar que autotrim hace lo que piensas (para vdevs SSD)

cr0x@server:~$ zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  on        local

Interpretación: Para pools basados en SSD, autotrim suele ayudar a mantener rendimiento estable. En HDD RAIDZ3 es irrelevante, pero existen pools mixtos y la gente hace cosas sorprendentes por presión de presupuesto.

Tarea 14: Comprobar dependencia de “special vdev” antes de celebrar redundancia

cr0x@server:~$ zpool status tank | sed -n '1,120p'
  pool: tank
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          raidz3-0                   ONLINE       0     0     0
            ...
        special
          mirror-1                   ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX040T8  ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX040T9  ONLINE       0     0     0

Interpretación: Si tienes un special vdev, has creado una nueva dependencia: perderlo puede hacer el pool inutilizable incluso si RAIDZ3 está bien. Replica tu special vdev correctamente, monitorízalo agresivamente y entiende qué metadata/clases colocaste allí.

Tarea 15: Confirmar que no estás a un reboot de “¿por qué no se importó?”

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 12345678901234567890
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          raidz3-0  ONLINE
            ...

Interpretación: Esto es una comprobación de cordura durante ventanas de mantenimiento o tras cambios de hardware. Si zpool import muestra dispositivos faltantes inesperados, arregla cableado/rutas antes de necesitar reiniciar por una actualización del kernel.

Guion de diagnóstico rápido (caza de cuellos de botella)

Cuando RAIDZ3 “va lento”, necesitas un camino rápido a la verdad. Aquí está el orden que uso para no perderme en folklore de afinado.

Paso 1: ¿Es un disco o ruta mala?

Ejecuta zpool status -v: busca cualquier disco con errores, estado DEGRADED o actividad de resilver/scrub.
Ejecuta iostat -x 5: busca un dispositivo con await mucho mayor o %util al máximo.
Revisa dmesg -T por resets/timeouts en el mismo dispositivo o bus.

Decisión: Si un solo disco está lento o reseteando, deja de afinar ZFS y empieza a arreglar hardware. RAIDZ es un deporte de equipo; un jugador cojo arruina el juego.

Paso 2: ¿Está el pool ocupado con mantenimiento?

Revisa zpool status por scrub/resilver.
Usa zpool iostat -v 5 para ver si el ancho de banda es devorado por lecturas de fondo.

Decisión: Si hay un resilver en curso, tu queja de rendimiento puede ser “estamos reconstruyendo un disco mientras servimos producción”. Eso no es un misterio; es una elección. Considera programar scrubs y reemplazos de forma más estratégica.

Paso 3: ¿Es comportamiento de escrituras sync?

Comprueba la propiedad del dataset: zfs get sync,logbias.
Confirma si la carga realmente emite escrituras sync (bases de datos, NFS, almacenamiento VM a menudo lo hacen).

Decisión: Si los picos de latencia coinciden con escrituras sync y no tienes un SLOG bien diseñado (o forzaste sync=always), has encontrado al culpable.

Paso 4: ¿Es un desajuste recordsize/volblocksize causando churn de franjas parciales?

Para ficheros: comprueba recordsize y patrones de tamaño de I/O del workload.
Para zvols: verifica volblocksize (no se puede cambiar tras creación sin recrear).

Decisión: Si tu carga son escrituras aleatorias de 8K en un RAIDZ3 ancho, la sobrecarga de paridad dominará. Considera mirrors, special vdev o rediseño.

Paso 5: ¿Está el pool demasiado lleno o fragmentado?

Comprueba capacidad y frag con zpool list.
Revisa cuotas/reservas y si una condición “casi lleno” está escondida por snapshots.

Decisión: Si estás por encima de ~80–85% usado, la medida de afinado más efectiva puede ser añadir capacidad o reducir utilización. Considera cuotas, reservas y retención de snapshots. “Ajustar ZFS” rara vez es la mejor primera respuesta a “nos quedamos sin espacio”.

Tres mini-historias del mundo corporativo

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

La compañía tenía un nuevo repositorio de backups: discos grandes, un vdev RAIDZ2 ancho y una diapositiva alegre que decía “redundancia de dos discos”. La suposición—dicha y luego repetida hasta convertirse en política—era que RAIDZ2 significaba “podemos perder dos discos en cualquier momento y estaremos bien”. Esa frase solo es verdadera si tratas el “tiempo” como un punto, no como un intervalo.

El primer disco falló un martes por la mañana. Se abrió ticket, se pidió reemplazo, sin verdadera urgencia porque “todavía estamos protegidos”. El reemplazo llegó tarde el miércoles. Durante el resilver, el rendimiento bajó y la ingestión de backups empezó a atrasarse. Alguien vio la latencia, asumió que era tunning y limitó el resilver para “ayudar a producción”. Ahora el pool estaba degradado por más tiempo—exactamente lo que no quieres.

El jueves por la noche, un segundo disco lanzó algunos errores de lectura. ZFS corrigió lo que pudo, pero los contadores siguieron subiendo. El equipo todavía se sentía tranquilo: “RAIDZ2, ¿no?” El viernes por la mañana, el segundo disco se puso offline. Ahora estaban sin redundancia durante el resilver aún en curso.

Entonces ocurrió el tercer evento: un error latente en otro disco surgió bajo lecturas de franja completa. Con RAIDZ2 y dos discos ya fuera del juego (uno fallado, otro en problemas), el pool no tenía suficientes miembros sanos para reconstruir la franja. El resultado no fue un momento limpio y dramático de “el pool está muerto”. Fue peor: metadata parcial se volvió ilegible, servicios empezaron a fallar de formas extrañas y el plan de restauración tuvo que ejecutarse bajo presión.

Después, la lección no fue “RAIDZ2 es malo”. La lección fue que la suposición era incorrecta. La redundancia no es un número estático; es un presupuesto que gastas durante incidentes. RAIDZ3 no hubiese evitado el primer fallo. Habría dado al equipo más tiempo para ser humano sin pagar por ello con datos.

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

Otra organización intentó exprimir más TB utilizables de su hardware. Tenían planeado RAIDZ3, pero tres discos de paridad “se sentían caros”. Alguien propuso un compromiso: usar RAIDZ2, mantener el mismo ancho de vdev y “compensar seguridad” ejecutando scrubs más a menudo.

En el papel sonaba ingenioso: los scrubs detectan errores latentes temprano, así reduces la probabilidad de toparte con UREs durante un resilver. El problema vino de los detalles. Los scrubs se programaron en horas de trabajo porque las noches estaban reservadas para pipelines de datos, y el equipo no quería “competir con batch”. Así que los scrubs corrían mientras el pool servía cargas interactivas.

La latencia subió, alguien se quejó y la respuesta fue predecible: limitar scrubs, luego saltarse scrubs, y eventualmente ignorar las alertas porque “siempre termina eventualmente”. Mientras tanto, el pool seguía llenándose y la amplificación de escritura aumentaba sigilosamente. Meses después, cuando un disco falló y comenzó el resilver, el pool estaba caliente (alta utilización), fragmentado y sin un scrub limpio desde hacía mucho.

Durante ese resilver sucedieron dos cosas: el disco de reemplazo era más lento que el resto (no defectuoso, solo un modelo distinto con comportamiento sostenido diferente), y otro disco empezó a mostrar sectores pendientes. RAIDZ2 sobrevivió, pero apenas—y el impacto en rendimiento se convirtió en un incidente de producción por sí mismo. Tuvieron suerte. La suerte no es un control de ingeniería.

La decisión final fue irónicamente más cara: añadieron capacidad para reducir llenado, reequilibraron la programación de cargas y finalmente migraron a RAIDZ3 en la siguiente renovación. La “optimización” no estaba mal por intentar ser eficiente. Estuvo mal porque asumió que la disciplina operacional permanecería perfecta con el tiempo, aun cuando el equipo y las cargas cambiaban.

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

Mis historias de fiabilidad favoritas son dolorosamente poco sexys. Un equipo ejecutaba un pool RAIDZ3 para una gran canalización de medios. Nada especial: scrubs periódicos, comprobaciones SMART y reglas estrictas sobre burn-in y etiquetado de discos. Las reglas eran lo suficientemente molestas como para que los nuevos empleados pusieran los ojos en blanco. Esas reglas también fueron por qué el pool sobrevivió a una semana genuinamente fea.

Empezó con un disco que empezó a registrar errores CRC. En lugar de reemplazar inmediatamente el disco, el on-call lo trató primero como un problema de ruta—porque ya les habían quemado reemplazos innecesarios antes. Reasentaron un cable, movieron el disco a otra bahía y observaron los contadores. Los errores se detuvieron. Ese disco siguió en servicio y el incidente terminó como una tarea de mantenimiento de una hora, no un pool degradado.

Dos semanas después, un disco realmente falló (offline, SMART horrible, toda la ópera trágica). Lo reemplazaron el mismo día, porque los repuestos ya estaban en sitio y el procedimiento estaba guionado. El resilver comenzó y durante el resilver otro disco empezó a lanzar un pequeño número de errores de lectura. RAIDZ3 se encogió de hombros; el pool permaneció online y reparable.

Esto fue lo que les salvó: tenían un calendario de scrubs y no lo cancelaron “porque estamos ocupados”. El último scrub había completado hace poco y los errores latentes eran raros. Así que cuando ese segundo disco empezó a fallar durante el resilver, no traía una larga cola de sectores ilegibles al peor momento posible.

El postmortem fue aburrido en el mejor sentido: reemplazar el disco fallado, monitorizar el que estaba inestable, planear un reemplazo proactivo y seguir adelante. Nadie fue ascendido por heroísmos. Pero nadie fue despedido por pérdida de datos tampoco. En producción, lo aburrido es una característica.

Errores comunes: síntomas y soluciones

Esta es la sección que lees cuando heredas un pool construido por alguien que desde entonces “pasó a nuevas oportunidades”.

Error 1: Construir RAIDZ3 y luego crear un special vdev de un solo disco

Síntoma: El pool es RAIDZ3 pero se siente “frágil”. La falla de un único SSD amenaza el pool entero.

Por qué ocurre: El special vdev aloja metadata (y opcionalmente bloques pequeños). Si no es redundante, se convierte en un punto único de fallo.

Solución: Haz espejo del special vdev (al menos). Si ya lo construiste de un solo disco, migra datos y reconstruye; ZFS no convierte mágicamente puntos únicos en seguros.

Error 2: Asumir que RAIDZ3 hace opcionales los scrubs

Síntoma: El primer resilver tras meses conduce a errores de checksums inesperados, reconstrucción lenta o bloques irrecuperables.

Solución: Programa scrubs con una frecuencia acorde al tamaño de tus discos y carga, y convierte la finalización en un SLO monitorizado. Los scrubs no son “mantenimiento”; son detección temprana.

Error 3: Usar rutas /dev/sdX y luego “misteriosamente” reemplazar el disco equivocado

Síntoma: El comando de reemplazo apunta al dispositivo equivocado tras reinicio o reordenado del controlador.

Solución: Usa siempre IDs estables: /dev/disk/by-id/wwn-*. Además etiqueta físicamente las bahías y coteja números de serie antes de sacar un disco.

Error 4: Forzar escrituras sync sin diseño (mitos del SLOG)

Síntoma: Picos de latencia, colapso de throughput, especialmente para cargas NFS/VM.

Solución: Mantén sync=standard a menos que tengas una razón. Si necesitas rendimiento sync, diseña un SLOG apropiado (protegido contra pérdida de energía, espejado si tu modelo de riesgo lo requiere) y mide.

Error 5: Mezclar discos SMR en un pool RAIDZ3 sin saberlo

Síntoma: Resilver/scrub tarda una eternidad, el pool se vuelve lento bajo carga de escritura, el throughput sostenido colapsa de forma impredecible.

Solución: Verifica modelos de disco; evita DM-SMR en vdevs RAIDZ a menos que entiendas la carga y aceptes el comportamiento de reconstrucción. Si ya los tienes, planifica migración.

Error 6: Ejecutar el pool demasiado lleno y culpar a RAIDZ3 por la lentitud

Síntoma: Latencia de escritura se vuelve explosiva alrededor del 80–90% de capacidad; scrubs se ralentizan; las asignaciones se fragmentan.

Solución: Añade capacidad o reduce la utilización. Considera cuotas, reservas y retención de snapshots. “Afinar ZFS” rara vez es la mejor primera respuesta a “nos quedamos sin espacio”.

Error 7: Elegir recordsize/volblocksize por intuición

Síntoma: La sobrecarga de paridad domina; las cargas de escritura aleatoria sufren; CPU y disco se agitan.

Solución: Ajusta recordsize al workload. Para zvols, elige volblocksize cuidadosamente en la creación y benchmárcalo con I/O realista.

Listas de verificación / plan paso a paso

Checklist de planificación: decidir si RAIDZ3 está justificado

Mide tu ventana de reconstrucción hoy (duración de scrub es un proxy; resilver será similar o peor bajo carga).
Define la realidad operacional: ¿qué tan rápido puedes reemplazar un disco (horas vs días)?
Identifica dominios de fallo correlacionados: misma bandeja, mismo expander, mismo lote, mismo firmware.
Cuantifica el dolor de restauración: tiempo de restauración, impacto de negocio, coste humano.
Elige el ancho de vdev intencionalmente, no porque “esa es la cantidad de bahías que tenemos”.
Decide si los espejos servirían mejor la carga (especialmente para I/O aleatorio).

Checklist de construcción: crear un pool RAIDZ3 sensato

Ejemplo de creación (ajusta dispositivos a tu entorno). Esto no es religión de copiar-pegar; es un patrón.

cr0x@server:~$ sudo zpool create -o ashift=12 tank raidz3 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d4 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d5 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d6 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d7 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d8 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3d9 \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3da \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3db \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3dc \
  /dev/disk/by-id/wwn-0x5000c500a1b2c3dd

Interpretación: ashift explícito, IDs estables explícitos. Si no haces nada más, haz esto.

Checklist operativo: mantener RAIDZ3 fiable de la forma aburrida

Programar scrubs, y alertar en scrubs fallidos/no completados.
Monitorizar atributos SMART (pending/offline uncorrectable, CRC, sectores reallocados).
Mantener repuestos fríos o rutas de reemplazo rápidas que coincidan con tu tolerancia al riesgo.
Seguir el llenado del pool y el crecimiento de snapshots como una métrica de primera clase (porque lo es).
Probar el procedimiento de reemplazo cuando estés calmado, no cuando estés degradado.
Documentar el mapeo de dispositivos (bahía-a-WWN/serial) y actualizarlo tras swaps.

Segundo chiste, porque nos lo hemos ganado: La forma más rápida de aprender ZFS es saltarte los scrubs—ZFS entonces te enseña personalmente, con laboratorios interactivos a las 2 a.m.

Preguntas frecuentes

1) ¿RAIDZ3 es “más seguro” que espejos?

Son seguros de formas diferentes. Los espejos ofrecen IOPS aleatorios fuertes y reconstrucciones rápidas (copiar desde el lado sano del espejo). RAIDZ3 ofrece eficiencia de capacidad a alta redundancia para vdevs anchos y mejor tolerancia a fallos concurrentes dentro de un vdev. Para bases de datos/VMs, los espejos suelen ganar operacionalmente; para cargas secuenciales/grandes/backup, RAIDZ3 suele encajar mejor.

2) ¿Cuántos discos debería tener un vdev RAIDZ3?

No hay un número único correcto, pero RAIDZ3 suele justificarse en vdevs más anchos donde el tiempo de reconstrucción y los fallos correlacionados se vuelven riesgos reales. Prácticamente, 10–16 discos es común. Demasiado estrecho y pagas una fracción de paridad alta; demasiado ancho y los resilvers/scrubs se alargan y el dominio de fallo crece.

3) ¿RAIDZ3 reduce la probabilidad de corrupción de datos?

ZFS usa sumas de comprobación para detectar corrupción independientemente del nivel de paridad. La redundancia determina si ZFS puede repararla automáticamente. RAIDZ3 aumenta la probabilidad de que ZFS pueda reconstruir datos correctos incluso cuando múltiples discos tienen problemas durante scrub/resilver.

4) ¿RAIDZ3 es más lento que RAIDZ2?

Suele ser algo más lento, especialmente para escrituras aleatorias pequeñas debido a la paridad adicional. Para cargas secuenciales la diferencia puede ser modesta. En la práctica, “más lento” a menudo está dominado por otros factores: un disco lento, llenado del pool, comportamiento de escrituras sync o desajuste de recordsize.

5) ¿Puedo convertir RAIDZ2 a RAIDZ3 in situ?

No en el sentido directo de “cambiar un interruptor”. ZFS soporta añadir vdevs, reemplazar discos por otros mayores y varias expansiones en implementaciones recientes, pero cambiar el nivel de paridad de un vdev no es una operación simple in-place en práctica productiva. Planifica una migración si el nivel de paridad es incorrecto.

6) ¿RAIDZ3 me salvará de perder un pool durante un resilver?

Mejora significativamente tus probabilidades, especialmente cuando un segundo/tercer disco falla o tiene errores de lectura durante la reconstrucción. No garantiza supervivencia frente a fallos catastróficos correlacionados (derrumbe del expander, actualización de firmware errónea, error humano que extrae múltiples discos, etc.). Backups y replicación siguen siendo esenciales.

7) ¿Debería usar RAIDZ3 para almacenamiento de VM?

A veces, pero desconfía. El almacenamiento de VM tiende a ser intensivo en I/O aleatorio y sensible a latencia; los espejos suelen rendir mejor y son más fáciles de razonar. Si debes usar RAIDZ3 para VMs, invierte en dimensionado cuidadoso de bloques, considera un special vdev para metadata/bloques pequeños (¡espejado!), y realiza pruebas con cargas reales.

8) ¿Con qué frecuencia debería hacer scrub a un pool RAIDZ3?

Con la suficiente frecuencia como para encontrar errores latentes antes de que un fallo de disco obligue a una lectura completa en condiciones degradadas. El intervalo “correcto” depende del tamaño del pool, comportamiento de los discos y workload. Operacionalmente: elige un calendario que puedas mantener, asegura que los scrubs terminen y alerta cuando no lo hagan.

9) ¿La triple paridad es excesiva si tengo replicación?

No necesariamente. La replicación ayuda con recuperación ante desastres y escenarios de corrupción lógica, pero no siempre te salva del downtime o de ventanas de restauración largas cuando falla un pool local. RAIDZ3 puede marcar la diferencia entre “reemplazar un disco y seguir” y “restaurar 100+ TB mientras el negocio mira”. La respuesta depende de tus RTO/RPO y de cuán probado esté tu proceso de recuperación.

10) ¿Cuál es el mayor “pero” con RAIDZ3 en la vida real?

La gente confía demasiado y no invierte lo suficiente en operaciones: scrubs, monitorización, IDs de dispositivo correctos y evitar puntos únicos como un special vdev no espejado. RAIDZ3 es robusto, pero no sustituto de la disciplina.

Conclusión

RAIDZ3 no es para todos. Es una respuesta específica a un problema moderno: discos grandes, reconstrucciones largas y modos de fallo que vienen en racimos, no en eventos independientes ordenados. Si perder un pool sería un incidente que limita carreras, y tus ventanas de reconstrucción son lo bastante largas como para que “otra cosa puede salir mal” sea realista, la triple paridad a menudo vale los discos.

Las mejores implantaciones de RAIDZ3 que he visto no parecen heroicas. Parecen aburridas: IDs de dispositivo estables, ashift sensato, scrubs que realmente terminan, alertas SMART que alguien respeta y procedimientos de reemplazo que no dependen del conocimiento tribal. RAIDZ3 te da margen. Las operaciones deciden si gastas ese margen con sensatez.