ZFS: ECC vs sin ECC — matemáticas del riesgo para despliegues reales

Si usas ZFS el tiempo suficiente, tarde o temprano te enfrentarás a la misma pregunta incómoda: “¿Realmente necesito memoria ECC, o es sólo folklore de quienes prefieren placas base caras?”
La respuesta honesta es aburrida y tajante: depende de tu presupuesto de riesgo, del valor de tus datos y de cómo se usa realmente tu pool ZFS —no de sensaciones, dogmas de foros ni de una captura de pantalla alarmante.

ZFS es excelente detectando corrupción. No es mágico para prevenir corrupción que ocurre antes de calcular la suma de comprobación, ni para corrupción que sucede en el lugar equivocado en el momento equivocado.
Este artículo es la matemática, los modos de fallo y el plan operativo—para que puedas tomar una decisión que puedas defender en una revisión de incidentes.

Qué cambia ECC (y qué no)

La memoria ECC (Error-Correcting Code) no es “más rápida” ni es un talismán. Es un control: detecta y corrige ciertas clases de errores de RAM (típicamente errores de un bit) y detecta (pero puede no corregir) algunos errores de múltiples bits.
Reduce la probabilidad de que una falla transitoria de memoria se convierta en basura persistente escrita al disco.

La memoria sin ECC no es “corrupción garantizada.” Es únicamente riesgo no gestionado. La mayoría de los sistemas funcionan largos periodos sin incidencias visibles.
Luego, un día, durante un scrub, un resilver, alta rotación del ARC, actualizaciones de metadata o un periodo de memoria ajustada, obtienes un error de checksum que no puedes explicar —o peor, no lo obtienes porque se checksummó lo equivocado.

Aquí está el encuadre práctico:

• ECC reduce la incertidumbre. Aún necesitas redundancia, scrubs, backups, monitorización y restauraciones probadas.
• ECC es más valiosa donde ZFS está más estresado. Workloads con mucha metadata, dedup, alta rotación del ARC, special vdevs y pools grandes que scrubean durante días.
• ECC no arregla una planificación deficiente. Si tu única copia está en un solo pool, tu problema real es “sin backups,” no “sin ECC.”

Una idea para grapar a toda decisión de almacenamiento: “La esperanza no es una estrategia.” — atribuido en la cultura de operaciones a Vince Lombardi, pero trátalo como un proverbio.

Hechos y contexto histórico (útil para operar)

1. Los errores suaves son cosa conocida. “Los rayos cósmicos voltean bits” suena a ciencia ficción, pero se ha medido en flotas de producción durante décadas.
2. La densidad de DRAM volvió los errores más relevantes. Al achicar las celdas, el margen para ruido y fuga de carga se redujo; las tasas de error se hicieron más visibles a escala.
3. ECC se volvió estándar en servidores porque el tiempo de actividad cuesta dinero. No porque los servidores sean moralmente superiores, sino porque las fallas tienen facturas asociadas.
4. ZFS popularizó checksums de extremo a extremo para admins mainstream. Las sumas de comprobación de datos y metadata no son exclusivas de ZFS, pero ZFS las hizo operativamente accesibles.
5. Los scrubs son un cambio cultural. RAID tradicional a menudo descubría la degradación sólo durante un rebuild; ZFS normaliza “leer todo periódicamente y verificar”.
6. Copy-on-write cambia el radio de daño. ZFS no sobrescribe en el lugar, lo que reduce algunos patrones de corrupción pero introduce otros (especialmente alrededor de las actualizaciones de metadata).
7. Dedup fue una lección de humildad. La dedup de ZFS puede funcionar, pero es una característica que consume mucha memoria y convierte pequeños errores en grandes caídas.
8. El “NAS de consumo” creció. Laboratorios domésticos y PYMEs empezaron a ejecutar pools ZFS con expectativas empresariales, a menudo sobre RAM y placas de consumo.

Dónde los errores de memoria afectan a ZFS: un modelo de fallo

1) El problema del tiempo del checksum

ZFS protege bloques con checksums almacenados por separado. Bien. Pero existe una ventana temporal: la suma se calcula sobre datos en memoria.
Si los datos están corruptos antes de calcular la suma, ZFS calcula fielmente la suma de comprobación de los bytes corruptos y escribe ambos. Eso no es “corrupción silenciosa dentro de ZFS”; es “datos incorrectos válidamente checksummados.”

ECC ayuda reduciendo la probabilidad de que los bytes que alimentan la suma estén equivocados.
Sin ECC estás apostando a que los errores transitorios no caerán en esa ventana con demasiada frecuencia.

2) La metadata es donde se arruina tu día

La corrupción de datos es dolorosa. La corrupción de metadata es existencial. La metadata de ZFS incluye punteros de bloque, spacemaps, metadata de asignación, estructuras MOS, dnodes y más.
Un bit malo en la metadata puede significar:

• un problema de importación del pool irrecuperable
• un dataset que no monta
• un objeto que apunta al bloque equivocado
• un resilver que se comporta “raro” porque sigue punteros dañados

ZFS es resistente, pero no inmune. Tu redundancia (mirror/RAIDZ) ayuda si la corrupción está en disco y es detectable.
Si se escribe la metadata equivocada, la redundancia puede replicar el error porque es una escritura lógicamente consistente.

3) ARC, rotación por expulsión y “la RAM como multiplicador de fallos”

ARC es la caché en memoria de ZFS. Es una característica de rendimiento, pero también un lugar donde un bit volteado puede amplificarse:
los datos cacheados erróneos pueden servirse, reescribirse o usarse para construir estado derivado.

Bajo presión de memoria, ARC expulsa agresivamente. Esa rotación aumenta la cantidad de transacciones de memoria y la cantidad de datos tocados.
Más datos tocados significa más oportunidades para que una falla importe.

4) Special vdevs y aceleración de bloques pequeños de metadata

Los special vdevs (a menudo mirrors SSD que alojan metadata y bloques pequeños) son un cohete de rendimiento y una trampa de fiabilidad.
Si pierdes ese vdev y no tienes redundancia, puedes perder el pool. Si se corrompe lo que va allí y la corrupción está válidamente checksummada, puedes perder integridad en las estructuras más importantes.

5) Scrub, resilver y las fases de “alta lectura”

Scrubs y resilvers leen mucho. También estresan la tubería: CPU, memoria, HBA, cableado, discos.
Son cuando salen a la luz problemas latentes.
Si ejecutas sin ECC, estas operaciones son tu sorteo de lotería, porque pasan volúmenes masivos de datos a través de la RAM.

Broma #1: Si tu calendario de scrub es “cuando me acuerdo”, felicitaciones—has inventado el bit rot de Schrödinger.

Matemática del riesgo aplicada a despliegues reales

La mayoría de los debates sobre ECC se atascan en absolutos: “Debes tenerlo” frente a “Nunca he tenido un problema.”
Las decisiones de producción viven en probabilidades y costes. Así que modelemos de forma útil.

La ecuación central: tasa × exposición × consecuencia

No necesitas la tasa exacta de volteo de bits por rayos cósmicos de tus DIMMs para hacer matemáticas útiles. Necesitas:

• Tasa de error (R): con qué frecuencia ocurren errores de memoria (corregibles o no). Varía por hardware, antigüedad, temperatura y calidad del DIMM.
• Exposición (E): cuánta data y metadata pasa por la memoria de forma “peligrosa” (escrituras, actualizaciones de metadata, ventanas de checksum, pipelines de scrub/resilver).
• Consecuencia (C): cuánto cuesta cuando algo sale mal (desde “un archivo incorrecto” hasta “pool que no importa”).

Tu riesgo no es “R.” Tu riesgo es R × E × C.

El riesgo no se distribuye igual entre workloads

Un archivo de medios que es mayormente de sólo lectura tras la ingestión tiene un perfil de exposición distinto a:

• un datastore de VM con churn constante
• una base de datos con latencia estricta y escrituras síncronas
• un destino de backups que procesa flujos secuenciales grandes y poda frecuente
• un entorno con mucha dedup que convierte la metadata en tus datos más calientes

Define tu “unidad de pérdida”

Deja de discutir en abstracto. Decide qué significa pérdida para ti:

• Unidad A: un archivo corrupto que se restaura desde backup (molesto)
• Unidad B: una VM con corrupción de sistema de ficheros (doloroso)
• Unidad C: fallo de importación del pool, restauración de varios días y un postmortem con directivos (consecuencias profesionales)

ECC reduce sobre todo la probabilidad de eventos Unidad B/C. No se trata de tu colección de MP3; se trata del radio de daño.

Los backups reducen la consecuencia, no la probabilidad

Backups sólidos reducen C. ECC reduce R.
Si tienes ambos, obtienes un beneficio multiplicativo: menos incidentes y más baratos.

Por qué “checksums de ZFS hacen innecesario ECC” es un atajo erróneo pero común

Los checksums de ZFS te protegen cuando:

• el disco devuelve datos equivocados
• fallos en el cableado/HBA corrompen bits en tránsito desde el disco
• ocurre degradación de sectores en disco

Los checksums de ZFS no garantizan protección cuando:

• datos malos son checksummados y escritos
• punteros de metadata se corrompen antes del checksum
• tu aplicación escribe basura y ZFS la preserva fielmente

ECC es un control aguas arriba que reduce la probabilidad de que “datos malos se vuelvan verdad.”

Entonces, ¿cuál es la recomendación real?

Si tu pool contiene datos empresariales, datos irremplazables o datos cuya corrupción es difícil de detectar a nivel de aplicación, ECC es la opción predeterminada correcta.
Sin ECC puede ser defendible para:

• caches desechables
• réplicas secundarias donde la integridad primaria está protegida
• laboratorios domésticos donde el tiempo de inactividad es aceptable y los backups son reales (probados)
• almacenamiento frío donde la ingestión está controlada y verificada

Si tu plan es “me daré cuenta de la corrupción”, estás asumiendo que la corrupción es ruidosa. A menudo no lo es.

Cuándo sin ECC es aceptable (y cuándo es temerario)

Aceptable: puedes tolerar datos incorrectos y restaurar rápidamente

Sin ECC puede estar bien cuando:

• tus datos están replicados en otro lugar (y verificas las réplicas)
• puedes destruir y reconstruir el pool desde la fuente de verdad
• tu host ZFS no realiza trabajo intensivo en metadata (sin dedup, sin special vdevs)
• scrubeas regularmente y monitorizas tendencias de error

Temerario: el pool es la fuente de verdad

Sin ECC es una mala apuesta cuando:

• tienes un pool con la única copia de datos de producción
• usas ZFS para almacenamiento de VM con escrituras constantes y snapshots
• habilitaste dedup porque “ahorra espacio”
• estás cerca de los límites de memoria y ARC está constantemente bajo presión
• ejecutes special vdevs sin redundancia, o con SSDs de consumo sin protección contra pérdida de energía

En esos escenarios, ECC es barato comparado con el primer incidente donde tengas que explicar por qué los datos son “consistentes pero equivocados.”

Tres microhistorias corporativas desde la trinchera

Microhistoria 1: El incidente causado por una suposición equivocada

Una compañía mediana ejecutaba un clúster de VM respaldado por ZFS para servicios internos. Los hosts eran máquinas de escritorio reutilizadas: muchos núcleos, mucha RAM, sin ECC.
El ingeniero de almacenamiento había pedido placas de servidor, pero compras oyó “ZFS tiene checksums” y lo tradujo por “ECC es opcional.”

Todo parecía bien hasta una ventana de mantenimiento rutinaria: una actualización del kernel, reinicio y luego un scrub programado se lanzó automáticamente.
A mitad del scrub, un host empezó a registrar errores de checksum. No muchos. Lo suficiente para inquietar. El pool siguió en línea, el scrub terminó y el equipo lo archivó como “un disco inestable.”

En las dos semanas siguientes aparecieron problemas esporádicos en aplicaciones: la base de datos SQLite de un servicio empezó a devolver errores de “malformado”. El sistema de archivos de otra VM necesitó reparaciones tras un apagado no limpio.
El equipo persiguió pistas falsas: latencia de almacenamiento, fallos de red, un SSD sospechoso.

El punto de quiebre fue cuando compararon backups: restaurar la misma imagen de VM desde dos snapshots distintos produjo checksums diferentes en algunos bloques.
Eso no es “degradación de disco”; es “algo escribió verdades inconsistentes en momentos diferentes.”

Tras un análisis doloroso, hallaron un patrón: los errores de checksum aparecían durante actividad intensa de memoria. Los logs mostraron síntomas tipo MCE en una máquina, pero nada concluyente porque la plataforma no exponía bien la telemetría de memoria.
Reemplazar los DIMMs redujo los errores, pero no reconstruyó la confianza. Cambiaron la plataforma por sistemas con ECC y añadieron pruebas mensuales de restauración.

La suposición equivocada no fue “sin ECC siempre corrompe.” Fue “los checksums hacen irrelevante la corrección aguas arriba.”
Los checksums detectan mentiras. No impiden que las escribas.

Microhistoria 2: La optimización que salió mal

Otro equipo usaba ZFS para un repositorio de backups. La presión de espacio era real, así que alguien sugirió dedup + compresión. En teoría era genial: los backups son repetitivos, la dedup debería destacar y ZFS lo trae incorporado.
Habilitaron dedup en un dataset grande y vieron crecer el ahorro. Todos se sintieron inteligentes.

Luego llegaron las quejas de rendimiento. Las ventanas de ingestión se alargaron. La caja empezó a intercambiar (swap) bajo carga.
El equipo reaccionó ajustando ARC y añadiendo un SSD rápido para L2ARC, intentando “cachear la salida.” También aumentaron recordsize buscando throughput.

Lo que no internalizaron: dedup empuja una enorme cantidad de metadata a memoria. La DDT (tabla de dedup) es voraz. Bajo estrés de memoria, todo se vuelve más lento y el sistema más vulnerable a casos límite.
Ejecutaban sin ECC porque “son sólo backups” y porque la plataforma era un appliance optimizado por coste.

La falla no fue inmediata, por eso fue tan didáctica. Tras unos meses, un scrub encontró errores de checksum en bloques de metadata.
Las restauraciones empezaron a fallar para subconjuntos de backups—el peor tipo de falla, porque los backups existían pero no eran fiables.

El rollback tomó semanas: deshabilitar dedup para datos nuevos, migrar backups críticos a un pool nuevo y ejecutar verificación completa de restauración en los conjuntos más importantes.
La optimización no era malvada; estaba mal emparejada con el hardware y la madurez operacional.

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

Un grupo financiero ejecutaba ZFS en un par de servidores de almacenamiento con RAM ECC, special vdevs espejados y un calendario que nadie discutía: scrub semanal, pruebas SMART extendidas mensuales y simulacros de restauración trimestrales.
La configuración era casi ofensivamente poco glamorosa. Sin dedup. Sin tunables exóticos. Sólo mirrors y disciplina.

Un trimestre, durante un simulacro, notaron que una restauración fue más lenta de lo esperado y el host receptor registró un puñado de errores de memoria corregidos.
Nada se cayó. No se perdió datos. Pero existía la telemetría, y el simulacro obligó al equipo a revisarla mientras nadie tenía un incendio real.

Cambiaron el DIMM proactivamente, luego hicieron otro simulacro y un scrub. Limpio.
Dos semanas después, el DIMM gemelo (mismo lote) empezó a reportar errores corregidos en otro servidor. Lo reemplazaron también.

Lo divertido es lo que no ocurrió: ningún incidente de cliente, ninguna corrupción de pool, ninguna reunión de “¿cuánto tiempo ha pasado esto?”
ECC no “salvó el día” solo. La práctica aburrida sí: observar errores corregidos, tratarlos como señal de degradación de hardware y validar restauraciones mientras era un evento de calendario, no una crisis.

Guía rápida de diagnóstico: encuentra el cuello de botella

Cuando ZFS empieza a comportarse mal—errores de checksum, scrubs lentos, bloqueos aleatorios—puedes perder días discutiendo sobre ECC como si fuera teología.
Esta guía es para el momento en que necesitas respuestas rápidas.

Primero: confirma qué tipo de fallo es

• Fallo de integridad: errores de checksum, archivos corruptos, aumento de errores del pool.
• Fallo de disponibilidad/rendimiento: bloqueos de I/O, scrub que tarda una eternidad, latencia alta, timeouts.
• Presión de recursos: swapping, OOM kills, thrash del ARC, saturación de CPU.

Segundo: aisla “camino de disco” vs “camino de memoria/CPU”

• Si zpool status muestra errores de checksum en un dispositivo específico, sospecha disco/cable/HBA primero.
• Si los errores aparecen en múltiples dispositivos a la vez, sospecha HBA, backplane, RAM o CPU.
• Si el pool está limpio pero las apps ven corrupción, sospecha bugs a nivel de aplicación, RAM o la capa de red sobre el almacenamiento.

Tercero: decide si puedes mantener el sistema en línea

• Errores de memoria corregibles son una advertencia. Normalmente puedes seguir en línea, pero planifica una ventana de mantenimiento.
• Errores no corregibles o aumento de errores de checksum: detén escrituras, snapshot lo que puedas y planifica un failover/restauración controlada.
• Resilver/scrub en hardware inestable: arriesgado. Arregla la plataforma primero si puedes.

Tareas prácticas: comandos, salidas y decisiones

Estas son tareas reales que puedes ejecutar en Linux con OpenZFS. Cada una incluye qué buscar y la decisión asociada.
(Si usas FreeBSD, los comandos difieren, pero la lógica operacional es la misma.)

Task 1: Comprobar salud del pool y contadores de error

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Determine if the device needs to be replaced, and clear the errors
  scan: scrub repaired 0B in 05:12:44 with 3 errors on Sun Dec  8 03:20:55 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz1-0                  ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     3
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        /tank/vmstore/vm-112-disk-0.qcow2

Qué significa: Errores CKSUM en un solo disco suelen indicar un disco, cable, puerto HBA o backplane defectuoso. “Permanent errors” significa que ZFS no pudo reconstruir algunos bloques.

Decisión: Si la redundancia no puede sanar, restaura el archivo afectado desde backup/snapshot. Luego investiga la ruta del dispositivo (SMART, cableado). No “limpies y olvides.”

Task 2: Mostrar propiedades detalladas del pool que afectan integridad y recuperación

cr0x@server:~$ zpool get ashift,autotrim,autoexpand,autoreplace,listsnapshots tank
NAME  PROPERTY       VALUE   SOURCE
tank  ashift         12      local
tank  autotrim       off     default
tank  autoexpand     off     default
tank  autoreplace    off     default
tank  listsnapshots  off     default

Qué significa: ashift afecta amplificación de escritura y rendimiento. No arreglará problemas de ECC, pero un ashift incorrecto puede hacer scrubs/resilvers terriblemente largos.

Decisión: Si ashift es incorrecto para tus discos, planifica una migración (no un cambio rápido). Si los scrubs tardan días, tu ventana de exposición crece—otra razón para valorar ECC.

Task 3: Confirmar calendario de scrub y resultado del último scrub

cr0x@server:~$ zpool status tank | sed -n '1,20p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:12:44 with 3 errors on Sun Dec  8 03:20:55 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0

Qué significa: Tienes un scrub reciente y encontró errores. Scrub es tu sistema de alerta temprana; trátalo como tal.

Decisión: Si los scrubs encuentran rutinariamente nuevos errores de checksum, deja de asumir que es “aleatorio.” Trendéalo y escala a triage de hardware.

Task 4: Revisar logs de ZFS y mensajes del kernel alrededor de I/O

cr0x@server:~$ dmesg -T | egrep -i 'zfs|checksum|ata|sas|mce|edac' | tail -n 20
[Sun Dec  8 03:21:12 2025] ZFS: vdev I/O error, zpool=tank, vdev=/dev/sdb1, error=52
[Sun Dec  8 03:21:12 2025] ata3.00: status: { DRDY ERR }
[Sun Dec  8 03:21:12 2025] ata3.00: error: { UNC }
[Sun Dec  8 03:21:13 2025] mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 8: b200000000070005

Qué significa: Errores mixtos de I/O de almacenamiento y entradas MCE son una bandera roja. No asumas que el disco es culpable si la CPU reporta machine checks.

Decisión: Si MCE/EDAC sugiere problemas de memoria, prioriza la estabilidad de RAM/plataforma antes de ejecutar otro scrub/resilver que pueda escribir nueva “verdad.”

Task 5: Verificar que ECC esté realmente habilitado y reconocido

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'error correction|ecc|type:|manufacturer' | head -n 20
        Error Correction Type: Multi-bit ECC
        Type: DDR4
        Manufacturer: Micron Technology
        Error Correction Type: Multi-bit ECC
        Type: DDR4
        Manufacturer: Micron Technology

Qué significa: La plataforma reporta capacidad ECC. Esto no garantiza que Linux reciba eventos EDAC, pero es una línea base necesaria.

Decisión: Si reporta “None” u “Unknown”, deja de decirte que tienes ECC “porque los DIMMs son ECC.” También necesitas una placa/CPU que lo utilice.

Task 6: Comprobar contadores EDAC para errores corregidos/no corregidos

cr0x@server:~$ sudo edac-util -v
edac-util: EDAC drivers are loaded. 1 MC detected:
  mc0: 2 Uncorrected Errors with no DIMM info
  mc0: 41 Corrected Errors with no DIMM info

Qué significa: Errores corregidos indican que ECC está haciendo trabajo. Errores no corregidos significan fallos de memoria que ECC no pudo arreglar.

Decisión: Cualquier error no corregido: programa mantenimiento inmediato y reemplaza DIMMs/sockets/placa sospechosos. Errores corregidos en aumento: considéralos una señal de pre-fallo y planifica reemplazo.

Task 7: Inspeccionar detalle por DIMM (cuando esté disponible)

cr0x@server:~$ sudo ras-mc-ctl --summary
Summary of memory errors:
Location: mc0/csrow0/channel0/dimm0
  Corrected: 37
  Uncorrected: 0
Location: mc0/csrow0/channel1/dimm0
  Corrected: 4
  Uncorrected: 0

Qué significa: Los errores están localizados en un DIMM/canal, exactamente lo que quieres para un reemplazo accionable.

Decisión: Reemplaza el DIMM con el mayor conteo de errores corregidos primero, y vuelve a comprobar. Si los errores siguen en el mismo canal, sospecha slot o controlador de memoria.

Task 8: Confirmar que ZFS no esté usando dedup accidentalmente

cr0x@server:~$ zfs get -r dedup tank
NAME                PROPERTY  VALUE  SOURCE
tank                dedup     off    default
tank/vmstore        dedup     off    default
tank/backups        dedup     off    default

Qué significa: Dedup está desactivado, bien. Si está activado en alguna parte, la presión de memoria y la sensibilidad de la metadata aumentan drásticamente.

Decisión: Si encuentras dedup habilitado sin justificación y plan de dimensionamiento, desactívalo para escrituras nuevas (set dedup=off) y planifica migración de datos antiguos si es necesario.

Task 9: Comprobar tamaño del ARC y señales de presión de memoria

cr0x@server:~$ arc_summary | egrep -i 'arc size|target size|memory|evict' | head -n 12
ARC size (current):                                   27.4 GiB
Target size (adaptive):                               30.1 GiB
Min size (hard limit):                                8.0 GiB
Max size (high water):                                32.0 GiB
Evict skips:                                          0
Demand data hits:                                     89.3%

Qué significa: El ARC es grande y estable. Si ves expulsiones constantes, bajas tasas de aciertos o la caja intercambiando, estás en un estado de alta rotación donde las fallas duelen más.

Decisión: Si hay thrash del ARC o swap, reduce la carga, añade RAM o limita el ARC. No hagas resilvers en un host que esté intercambiando y volviéndose inestable.

Task 10: Comprobar swapping y presión de reclaim

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            64Gi        58Gi       1.2Gi       1.0Gi       4.8Gi       2.6Gi
Swap:           16Gi        12Gi       4.0Gi

Qué significa: Uso activo de swap en un host de almacenamiento es un olor a problema de rendimiento y, de forma indirecta, un amplificador de riesgo de integridad (más rotación, más estrés durante operaciones críticas).

Decisión: Encuentra qué consume memoria (VMs, dedup, workloads con mucha metadata). Añade RAM o reduce alcance. Si no puedes añadir ECC, al menos evita operar caliente y con swap.

Task 11: Verificar SMART y errores UDMA CRC (el cableado habla)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i 'reallocated|pending|offline_uncorrectable|udma_crc_error_count' 
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       12

Qué significa: Errores UDMA CRC implican normalmente cables/backplanes más que el medio. Errores de checksum de ZFS que correlacionan con incrementos de CRC suelen ser “datos mangled en tránsito.”

Decisión: Reemplaza cables, reseat conexiones, revisa backplane/puerto HBA. Luego scrubea otra vez para confirmar estabilidad.

Task 12: Identificar si los errores de checksum son nuevos o históricos

cr0x@server:~$ zpool status -v tank | tail -n 15
errors: Permanent errors have been detected in the following files:

        /tank/vmstore/vm-112-disk-0.qcow2

Qué significa: “Permanent errors” persisten hasta que restauras/sobrescribes los bloques afectados. Limpiar errores no arregla los datos.

Decisión: Restaura el archivo desde un snapshot/backup conocido bueno o bórralo y regenera. Luego usa zpool clear sólo después de la remediación.

Task 13: Mapear un problema a nivel de bloque a snapshots e intentar auto-sanación

cr0x@server:~$ zfs list -t snapshot -o name,creation -S creation tank/vmstore | head
NAME                                CREATION
tank/vmstore@hourly-2025-12-08-0300  Sun Dec  8 03:00 2025
tank/vmstore@hourly-2025-12-08-0200  Sun Dec  8 02:00 2025
tank/vmstore@daily-2025-12-07        Sat Dec  7 23:55 2025

Qué significa: Tienes snapshots para revertir o clonar, que son tu camino más rápido a la corrección.

Decisión: Si un archivo está marcado como permanentemente corrupto, restaura desde el snapshot conocido bueno más reciente y valida a nivel de aplicación.

Task 14: Forzar una lectura dirigida para sacar a la luz errores latentes

cr0x@server:~$ sudo dd if=/tank/vmstore/vm-112-disk-0.qcow2 of=/dev/null bs=16M status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 7 s, 307 MB/s
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 14 s, 305 MB/s
...output...

Qué significa: Una lectura secuencial completa puede disparar la verificación de checksum y mostrar si los errores reaparecen. No sustituye al scrub, pero es una herramienta rápida de triage para un objeto específico.

Decisión: Si las lecturas generan nuevos errores de checksum, trata la ruta subyacente como inestable; no esperes al próximo scrub semanal para enterarte de lo que ya sabes.

Task 15: Comprobar throughput de scrub/resilver e identificar si estás limitado por CPU o I/O

cr0x@server:~$ iostat -x 2 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    6.22   21.10    0.00   60.37

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
sdb              84.0  10432.0     0.0    0.0   28.4   124.2        3.0     64.0    2.1    2.40   98.0
sdc              82.0  10240.0     0.0    0.0   29.1   124.9        2.0     48.0    1.9    2.35   97.5

Qué significa: Alto %iowait y utilización cercana al 100% del disco sugiere que el scrub está limitado por disco. Si la CPU estuviera al máximo y los discos ociosos, estarías limitado por CPU/checksum.

Decisión: Disco limitado: revisa layout de vdev, ashift, salud de drives y cableado. CPU limitada: considera CPU más rápida, habilitar offloads de checksum si aplica, o reducir recordsize/rotación de metadata.

Task 16: Confirmar redundancia del special vdev (si usas uno)

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

        NAME                       STATE     READ WRITE CKSUM
        tank                       ONLINE       0     0     0
          raidz2-0                 ONLINE       0     0     0
            sda1                   ONLINE       0     0     0
            sdb1                   ONLINE       0     0     0
            sdc1                   ONLINE       0     0     0
            sdd1                   ONLINE       0     0     0
          special                  ONLINE       0     0     0
            mirror-1               ONLINE       0     0     0
              nvme0n1p1            ONLINE       0     0     0
              nvme1n1p1            ONLINE       0     0     0

Qué significa: El special vdev está espejado. Esa es la línea mínima de seguridad si pones metadata allí.

Decisión: Si special es un único dispositivo, arréglalo antes de optimizar otra cosa. Un special vdev único es un punto único de fallo del pool.

Broma #2: Ejecutar ZFS con dedup activada en no-ECC es como hacer malabares con motosierras porque “ahorra pasos.”

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

1) Errores de checksum “aleatorios” en múltiples discos

• Síntoma: CKSUM incrementa en más de un disco, a veces diferentes discos en distintos días.
• Causa raíz: Problema de ruta compartida (HBA, backplane, alimentación, cables) o inestabilidad de memoria/CPU causando datos malos escritos/validados.
• Solución: Revisa SMART CRC, cambia cables/puertos, actualiza firmware del HBA, revisa logs MCE/EDAC, ejecuta memtest en mantenimiento y detén escrituras hasta estabilizar.

2) “ZFS dice reparado, pero la app sigue rota”

• Síntoma: El scrub reporta reparaciones, pero la base de datos/formatos de archivos siguen quejándose.
• Causa raíz: ZFS reparó bloques corruptos desde la redundancia, pero el estado a nivel de aplicación ya pudo haber incorporado escrituras malas (especialmente si la corrupción fue pre-checksum).
• Solución: Restaura desde backups o snapshots consistentes a nivel de aplicación. Añade checksums a nivel de app donde sea posible (las bases de datos a menudo los tienen).

3) Los scrubs están limpios, pero aún no confías en el pool

• Síntoma: No hay errores ZFS, pero tuviste crashes inexplicables, kernel panics o reportes de corrupción de ficheros.
• Causa raíz: Inestabilidad de memoria que afecta cómputo y comportamiento de la aplicación más que las lecturas de disco, o corrupción que ocurre antes de que los datos lleguen a ZFS.
• Solución: Revisa EDAC/MCE, ejecuta pruebas de memoria, verifica PSU y temperatura, valida con checksums end-to-end de la aplicación y considera ECC si esto es fuente de verdad de almacenamiento.

4) “Borramos errores y ahora está bien”

• Síntoma: Alguien ejecutó zpool clear y declaró victoria.
• Causa raíz: Confundir contadores con corrupción. Limpiar reinicia el reporte, no la realidad.
• Solución: Identifica y remedia archivos dañados (restaurar/sobrescribir). Limpia sólo después de arreglar datos y estabilizar hardware.

5) Pool no importa después de un evento de energía

• Síntoma: La importación falla o se cuelga tras una pérdida abrupta de energía.
• Causa raíz: Problemas de hardware/firmware, memoria mala o ruta de almacenamiento inestable expuestos por la intensa reproducción y operaciones de metadata al arrancar.
• Solución: Valida RAM (logs ECC o memtest), revisa firmware HBA, asegúrate de manejo correcto de pérdida de energía (UPS) y documenta y prueba entornos de arranque y procedimientos de recuperación.

6) “Añadimos RAM y ahora tenemos errores”

• Síntoma: Los errores comienzan tras ampliar RAM.
• Causa raíz: Mezcla de tipos/timings de DIMM, DIMM marginal, ajustes BIOS incorrectos o una placa que no puede manejar la configuración de forma fiable.
• Solución: Usa configuraciones de memoria validadas, actualiza BIOS, reduce la velocidad a ajustes estables y vigila contadores EDAC. Reemplaza DIMMs sospechosos pronto.

Listas de verificación / plan paso a paso

Lista de decisión: ¿debe este sistema ZFS usar ECC?

1. ¿Es este pool una fuente de verdad? Si sí, por defecto usa ECC.
2. ¿Es difícil detectar la corrupción? Imágenes de VM, bases de datos, fotos, datos científicos: sí. Por defecto usa ECC.
3. ¿Usas dedup, special vdevs o snapshots intensos? Si sí, ECC fuertemente recomendado.
4. ¿Puedes restaurar rápido y lo has probado? Si no, ECC no te salvará, pero sin ECC te hará más daño.
5. ¿Tienes telemetría de errores de memoria? Si no, vuelas a ciegas—prefiere plataformas ECC con visibilidad EDAC.

Lista operacional: si debes ejecutar sin ECC

1. Manténlo simple: mirrors/RAIDZ, sin dedup, evita special vdevs de un solo dispositivo.
2. Ejecuta scrubs regulares y alerta ante nuevos errores de checksum inmediatamente.
3. Mantén margen de memoria: evita swap; limita ARC si es necesario.
4. Usa checksums a nivel de aplicación donde sea posible (checks de BD, hashes para archivos).
5. Tén backups verificados: pruebas periódicas de restauración, no “tenemos backups en algún lugar.”
6. Mantén un plan de repuestos de hardware: cables conocidos buenos, HBA de repuesto, disco de repuesto y procedimiento documentado de reemplazo.

Paso a paso: responder a los primeros errores de checksum

1. Congela suposiciones: no declares “disco malo” aún.
2. Captura la salida de zpool status -v y logs del sistema alrededor del tiempo.
3. Revisa SMART, especialmente CRC y sectores pendientes.
4. Comprueba contadores MCE/EDAC. Si hay errores corregidos, trata el hardware como degradado.
5. Identifica archivos afectados; restaura desde snapshot/backup si es posible.
6. Arregla la capa física (cable/puerto/HBA) antes de scrubea otra vez.
7. Ejecuta scrub y verifica que la tendencia de errores esté plana.
8. Si los errores reaparecen en múltiples dispositivos, planifica mantenimiento para aislar RAM/HBA/backplane.

Preguntas frecuentes

1) ¿ZFS requiere RAM ECC?

ZFS no requiere ECC para funcionar. ECC es un control de fiabilidad. Si el pool contiene datos importantes, ECC es la opción predeterminada correcta.

2) Si ZFS tiene checksums, ¿cómo puede importar la corrupción de RAM?

Los checksums detectan corrupción después de que se calcula la suma. Si los datos corruptos son checksummados y escritos, ZFS más tarde los validará como “correctos”, porque coinciden con su checksum.

3) ¿Está bien sin ECC para un NAS doméstico?

A veces. Si tienes backups reales y puedes tolerar restauraciones ocasionales, sin ECC puede ser un compromiso aceptable.
Si guardas fotos irremplazables y tu “backup” es otro disco en la misma caja, estás apostando, no haciendo ingeniería.

4) ¿Qué es peor: no tener ECC o no tener un calendario de scrub?

No tener un calendario de scrub suele ser peor a corto plazo porque descubrirás problemas latentes sólo durante un rebuild—cuando menos puedes permitirte sorpresas.
No tener ECC aumenta la probabilidad de que algunas sorpresas sean más extrañas y difíciles de atribuir.

5) ¿Los mirrors/RAIDZ hacen que ECC sea menos importante?

La redundancia ayuda cuando la corrupción está en disco y es detectable. ECC ayuda a prevenir escrituras malas y protege operaciones en memoria.
Abordan modos de fallo diferentes; se complementan, no se sustituyen.

6) ¿Puedo “validar” mi sistema sin ECC ejecutando memtest una vez?

Memtest es útil, pero es una prueba puntual. Algunas fallas dependen de temperatura o carga y aparecen sólo tras meses.
Si te tomas en serio la integridad, prefiere ECC más monitorización para ver errores corregidos antes de que se conviertan en incidentes.

7) ¿Qué características de ZFS hacen más importante ECC?

Dedup, special vdevs, snapshotting/cloning intensivo, workloads con mucha metadata y sistemas que operan cerca de los límites de memoria.
Estas aumentan la cantidad de estado crítico tocado en memoria y el coste de equivocarse.

8) Si veo errores ECC corregidos, ¿debo entrar en pánico?

No. Los errores corregidos significan que ECC hizo su trabajo. Pero no los ignores. Una tendencia al alza es señal de mantenimiento: reemplaza el DIMM, revisa la refrigeración y verifica ajustes BIOS.

9) ¿ECC es suficiente para garantizar integridad?

No. Aún necesitas redundancia, scrubs, backups y validación. ECC reduce una clase de riesgo aguas arriba; no hace tu sistema invencible ni opcionales los backups.

10) ¿Cuál es la mejora de fiabilidad más barata si no puedo tener ECC?

Disciplina operacional: scrubs, monitorización SMART, pruebas de restauración y mantener el sistema fuera de swap. Además, simplificar el pool (mirrors) y evitar funciones arriesgadas (dedup, special vdev único).

Siguientes pasos que puedes hacer esta semana

1. Decide tu unidad de pérdida. Si la pérdida del pool es un evento de carrera, compra hardware con ECC o mueve la carga.
2. Habilita y monitoriza las señales correctas. Rastrea salud con zpool status, resultados de scrub, SMART CRC/sectores pendientes y contadores EDAC/MCE.
3. Programa scrubs y prueba restauraciones. Los scrubs encuentran problemas; las pruebas de restauración demuestran que puedes sobrevivirlos.
4. Audita tus características ZFS. Si dedup está activado “por ahorrar espacio”, desactívalo para escrituras nuevas y rediseña antes de reintroducirlo.
5. Si sigues sin ECC, reduce la exposición. Mantén margen de memoria, evita swap y usa topologías de pool conservadoras.

La postura madura no es “siempre ECC” ni “nunca ECC.” Es: conoce tus modos de fallo, valora tus consecuencias y elige el hardware que coincida con la seriedad de tus promesas.
ZFS te avisará cuando detecte mentiras. ECC ayuda a que no las escribas en primer lugar.