RAID con ZFS: RAIDZ1, RAIDZ2, RAIDZ3 y Mirror
Por el Equipo Técnico HD Doctor
Respuesta directa
El RAID en ZFS no es RAID tradicional. No existe write hole, cada bloque lleva checksum de punta a punta y el resilver copia solo los datos usados, no el disco entero. A cambio, la unidad de fallo es el vdev: perder un vdev tumba el pool completo, incluso con todos los demás perfectos. Esa regla decide la topología correcta.
Vdev, pool y por qué la topología importa más que la marca del disco
Un pool ZFS es un stripe de vdevs, y cada vdev tiene su propia redundancia. El mirror duplica (o triplica) los datos; RAIDZ1, RAIDZ2 y RAIDZ3 distribuyen 1, 2 o 3 bloques de paridad. La tolerancia es por vdev: un pool con cuatro vdevs RAIDZ2 aguanta dos fallos en cada uno, pero el tercer fallo dentro de cualquiera de ellos se lleva el pool entero. Tres diferencias prácticas frente al RAID de controladora. Primera: ZFS necesita ver los discos directamente, vía HBA en modo IT — una controladora RAID con caché propia esconde el SMART, miente sobre la escritura completada y corrompe el pool en corte de energía. Segunda: el resilver de ZFS lee solo los bloques asignados, así que un pool al 20% de uso reconstruye mucho más rápido que un RAID 5 equivalente; a cambio es una carga aleatoria pesada, y es justo durante ella cuando un segundo disco del mismo lote suele fallar. Tercera: hasta OpenZFS 2.3 (2025, que llegó a los usuarios con TrueNAS SCALE 24.10 Electric Eel) no había forma de añadir un disco a un RAIDZ existente — hoy la expansión existe, pero los datos antiguos mantienen la proporción de paridad original hasta ser reescritos. Un detalle que casi nadie planifica: los vdevs de apoyo no son iguales en riesgo. Perder el L2ARC no cuesta nada y perder el SLOG rara vez cuesta; perder un vdev special, que guarda los metadatos, destruye el pool entero. El special siempre en mirror.
Comparativo por topología: cuándo usar cada una
- 1.Mirror (2 o 3 vías). Tolera 1 disco por vdev (o 2 en el triple). Mejor IOPS y el resilver más rápido y liviano de todos. Cuesta 50% de la capacidad. Opción por defecto para VMs, bases de datos y cualquier carga aleatoria — y para quien quiere crecer el pool de dos en dos discos.
- 2.RAIDZ1. Tolera 1 disco por vdev. Aceptable solo con discos pequeños (hasta ~4 TB) y backup real en otro lugar. Con discos de 12, 16 o 20 TB el resilver dura días, y la probabilidad de que un segundo disco del mismo lote falle en ese intervalo es alta como para desaconsejarlo.
- 3.RAIDZ2. Tolera 2 discos por vdev. Es el estándar sensato para archivo y backup con 6 a 12 discos por vdev. Sobrevive al fallo de un segundo disco durante el resilver, que es justamente el escenario que más destruye pools RAIDZ1.
- 4.RAIDZ3. Tolera 3 discos por vdev. Tiene sentido en vdevs anchos (12+ discos), discos muy grandes o cuando la reposición demora semanas. Costo de paridad alto, desempeño de escritura bajo.
- 5.dRAID. Distribuye los discos de repuesto dentro del propio vdev, lo que reduce el resilver de días a horas en arreglos grandes. Compensa a partir de algunas decenas de discos; por debajo, es complejidad sin retorno.
- 6.Stripe sin redundancia. Tolerancia cero: un disco fuera y se pierde el pool entero. Solo para scratch descartable. Es también el efecto colateral de añadir por error un disco suelto a un pool RAIDZ — error que no tiene deshacer.
Qué hacer cuando un pool ZFS queda degradado, en 6 pasos
El momento de mayor riesgo de un pool ZFS no es el fallo del primer disco: es el resilver que viene después. Esta es la secuencia segura.
- 1
Confirme qué falló realmente
zpool status -v muestra el vdev afectado y el tipo de error. Errores CRC/UDMA en varios discos a la vez apuntan a cable, backplane, expander o fuente — cambiar disco en ese escenario no resuelve y encima gasta la redundancia que quedaba.
- 2
Haga backup antes del resilver, no después
Con el pool degradado pero aún montable, la prioridad absoluta es copiar los datos críticos hacia afuera, preferentemente con zfs send. Un pool RAIDZ1 con un disco caído está sin red de protección: cualquier error de lectura durante la reconstrucción se convierte en pérdida.
- 3
Verifique la salud de los discos restantes antes de reconstruir
smartctl -a en todos los miembros, no solo en el que falló. Si otro disco ya muestra pending sectors, el resilver probablemente lo va a tumbar. En ese caso el camino seguro es imagen de los discos y reconstrucción en laboratorio, no sustitución en el equipo.
- 4
Sustituya con el pool lo más quieto posible
Detenga servicios, snapshots programados, replicación y scrub durante el resilver. Cuanta menos competencia de I/O, más rápido termina y menor la probabilidad de que salga un segundo miembro. Use zpool replace con el disco nuevo ya conectado, sin retirar el antiguo si todavía responde.
- 5
No ejecute scrub para 'probar' un pool degradado
El scrub lee todos los bloques de todos los discos a carga máxima. En pool sano es mantenimiento obligatorio, mensual. En pool degradado es el empujón que le faltaba al disco marginal para morir. Scrub después del resilver concluido, nunca durante ni antes.
- 6
Si el pool ya no importa, detenga todo
Cuando la redundancia se acabó y el pool no monta, cada intento nuevo de import con -f o -F consume los uberblocks antiguos que permitirían un rewind. Apague, preserve los discos en el orden original y trátelo como caso de laboratorio: con imagen de cada miembro, todavía hay camino de reconstrucción.
Preguntas frecuentes
¿RAIDZ2 o mirror: cuál elegir?
Elija por la carga, no por el espacio. RAIDZ entrega el IOPS de un solo disco por vdev, así que es excelente para archivo, medios y backup, y malo para VM y base de datos. El mirror entrega mucho más IOPS, resilver más rápido y crecimiento de dos en dos discos, al costo de la mitad de la capacidad. Storage de virtualización: mirror. Repositorio de archivos: RAIDZ2.
¿Cuántos discos por vdev RAIDZ es lo ideal?
En la práctica, 6 a 10 discos por vdev RAIDZ2 es el rango cómodo. Un vdev muy ancho aumenta el tiempo de resilver y el riesgo acumulado; uno muy estrecho desperdicia capacidad en paridad. Con muchos discos, prefiera varios vdevs de 8 antes que sumar todo en un vdev único gigante.
¿Puedo añadir un disco a un RAIDZ existente?
Sí, desde OpenZFS 2.3 (2025), que llegó a los usuarios con TrueNAS SCALE 24.10. La expansión añade un disco por vez y preserva los datos, pero los bloques antiguos mantienen la proporción de paridad que tenían — el espacio solo se aprovecha plenamente en los datos reescritos después. Antes de esa versión, la única salida era crear un vdev nuevo.
¿El RAID ZFS elimina la necesidad de backup?
No. El RAID protege contra fallo de disco, no contra ransomware, borrado accidental, error de administrador, incendio o destrucción del pool. El snapshot ZFS vive dentro del mismo pool y cae con él. Backup es replicación a otro sistema, preferentemente con una copia inmutable.
¿Realmente necesito RAM ECC en ZFS?
ZFS funciona sin ECC, pero su modelo de integridad asume que la memoria es confiable: un bit corrompido en RAM entra en el checksum como si fuera dato bueno y se graba así. Para storage de producción, ECC es muy recomendable. Para homelab, es una decisión de riesgo consciente.
Perdí dos discos en un RAIDZ1. ¿Todavía se puede recuperar?
Con frecuencia sí, en laboratorio. Los dos discos rara vez mueren por completo en el mismo instante: suele haber un disco marginal con pocos sectores malos y otro que se cayó por cable, firmware o controladora. Con imagen de cada miembro y reconstrucción del stripe fuera del equipo, la tasa de recuperación es alta. Lo que mata el caso es insistir en importaciones forzadas antes de imaginar los discos.
¿Qué pasa si pierdo el vdev special?
Se pierde el pool entero. El vdev special guarda los metadatos: sin él, ZFS no sabe dónde están los bloques, incluso con todos los discos de datos intactos. Por eso debe ir siempre en mirror, con el mismo nivel de redundancia que los vdevs de datos — regla que muchas instalaciones con SSD 'solo para acelerar metadatos' ignoran.
¿Pool ZFS degradado o que ya no importa?
Reconstrucción de RAIDZ y mirror en laboratorio, con imagen de cada miembro. Diagnóstico en 24h.