Corrupción silenciosa en ZFS: lo que ZFS detecta y que RAID suele pasar por alto

Corrupción silenciosa: qué es y por qué RAID puede pasarla por alto

La corrupción silenciosa (también llamada “bit rot”, “errores latentes de sector”, “escrituras mal dirigidas” o “ups, el controlador mintió”)
es cualquier caso en que la pila de almacenamiento devuelve datos que no son lo que se escribió, sin levantar un error de E/S.
La palabra clave es silenciosa: el SO obtiene una lectura exitosa, tu aplicación recibe bytes y nadie lanza una excepción.

RAID —especialmente RAID por hardware o RAID “solo mdadm”— típicamente se centra en la disponibilidad del dispositivo. Un disco falla, la paridad o
un espejo mantiene el volumen en línea. Genial. Pero RAID a menudo tiene visibilidad limitada sobre si el contenido del bloque es
correcto tal como lo escribió originalmente la aplicación. Puede detectar algunos errores (como un sector ilegible),
pero también puede entregar felizmente datos corruptos porque no tiene verificación end-to-end desde la app → sistema de archivos → disco.

Aquí va la verdad incómoda: muchos diseños RAID asumen que el resto de la pila es honesta. En producción, eso es una
suposición arriesgada. Los controladores tienen bugs de firmware. Las HBAs tienen peculiaridades. Los cables y backplanes hacen cosas extrañas a escala.
Los discos remapean sectores. DMA puede comportarse mal. La memoria puede voltear bits. Y sí, a veces los humanos “arreglan” un problema de almacenamiento
intercambiando bahías, recableando o actualizando firmware —y crean accidentalmente otro problema.

ZFS adopta un enfoque distinto: asume que el mundo es hostil. Revisa todo lo que puede y trata el “éxito”
de una capa inferior como una sugerencia, no como una garantía.

Qué “ve” ZFS y que el RAID clásico a menudo no ve

Sumas de verificación end-to-end: la idea principal

ZFS almacena una suma de verificación para cada bloque que escribe —datos y metadatos— y guarda esa suma en los metadatos padre
del bloque (no junto al propio bloque). Cuando ZFS lee un bloque, recalcula la suma y la compara con el valor esperado. Si las sumas no coinciden, ZFS sabe que los datos son incorrectos incluso si el disco dijo “lectura OK”.

Esa suma es end-to-end: cubre el camino desde la perspectiva del sistema de archivos hasta el dispositivo. ZFS no
confía únicamente en el ECC interno del disco o en la lógica de paridad del controlador como el único mecanismo de integridad.
Los usa como defensa en profundidad.

Lecturas auto-reparadoras (cuando existe redundancia)

Si el pool tiene redundancia (mirror, RAIDZ, dRAID), ZFS puede intentar copias alternativas cuando detecta corrupción. Lee
desde otra réplica, valida la suma y luego repara la copia mala automáticamente. Eso no es “reconstruir cuando muere un disco.” Es “reparar un bloque malo mientras el disco aún está vivo.”

La paridad RAID puede reconstruir datos cuando falta un disco. Pero si un disco devuelve un bloque malo sin error, RAID
a menudo no sabe qué disco está mal y puede no tener ninguna suma de verificación de alto nivel para probarlo. Terminas con un
bloque de Schrödinger: es correcto e incorrecto hasta que lo intentas usar.

Scrubs: detección proactiva en lugar de fallos sorpresa

Los scrubs de ZFS recorren el espacio asignado en el pool, leen bloques, verifican sumas y reparan cuando es posible. Así
es como detectas errores latentes de sector antes de que la única copia buena sea sobrescrita o antes de necesitar esos datos durante
un incidente.

Copy-on-write: menos “escrituras partidas”, otra superficie de fallo

ZFS es copy-on-write (CoW). Escribe bloques nuevos en otro lugar y luego actualiza punteros de metadatos de forma atómica. CoW no
previene mágicamente toda la corrupción, pero reduce un problema clásico de RAID: escrituras parciales que dejan un sistema de archivos en un
estado inconsistente (especialmente tras una pérdida de energía). Los sistemas de archivos tradicionales se apoyan en journaling y orden correcto.
ZFS se apoya en semántica transaccional en la capa de sistema de archivos.

Checksumming de metadatos también, porque perder el mapa es peor que perder el territorio

Muchos sistemas tratan los metadatos como “pequeños y fiables”. En la práctica, la corrupción de metadatos suele ser catastrófica:
estructuras de directorio, tablas de asignación, bloques indirectos. ZFS suma también los metadatos y puede auto-repararlos con redundancia.
Esa es una gran diferencia en el comportamiento ante fallos: en lugar de “el sistema de archivos necesita fsck y rezos”, a menudo ves “ZFS lo curó durante la lectura.”

Mejor contabilidad de errores: obtienes recibos

Los contadores de errores de ZFS distinguen entre errores de lectura, errores de escritura y errores de checksum. Esa última categoría es
la interesante: el disco no falló, pero los datos no coincidieron. Muchos montajes RAID nunca exponen esa matización. ZFS
te dirá cuando la pila de almacenamiento está mintiendo.

Una idea parafraseada de W. Edwards Deming también vale para operaciones de almacenamiento: sin medición, gestionas a ciegas (paráfrasis de Deming).
ZFS mide la integridad de forma continua.

Fortalezas de RAID y las brechas que la gente confunde con seguridad

RAID trata la disponibilidad, no la corrección

El trabajo central de RAID es mantener un dispositivo de bloques en línea cuando un disco falla. Es bueno en eso. También es bueno en ocultar fallos de disco
al SO, lo cual puede ser conveniente y terrible a la vez: conveniente porque los servidores siguen en marcha,
terrible porque la primera vez que notas un problema puede ser cuando la tarjeta RAID ya está manejando múltiples
condiciones degradadas.

“Pero el controlador RAID tiene batería y patrol read”

La caché de escritura con respaldo por batería (o flash) es excelente para rendimiento y puede reducir algunos riesgos por pérdida de energía. Patrol
read puede detectar sectores ilegibles. Ninguno de los dos garantiza corrección end-to-end.

• Patrol read es una herramienta de salud de la superficie del disco. No valida que los bytes leídos coincidan con lo que la aplicación escribió
  meses atrás.
• Algunos stacks de controlador usan sumas internamente, pero por lo general no se exponen al sistema de archivos y no
  te protegen contra escrituras mal dirigidas o corrupción del lado del host.

El write hole y las pesadillas de paridad

Las escrituras de paridad RAID5/6 pueden sufrir el “write hole” si se pierde energía a mitad de la actualización de una franja. Los controladores modernos mitigan
esto con caché + journaling, pero las implementaciones varían. RAID por software tiene sus propias estrategias de mitigación, también variables.
ZFS evita el write hole clásico por diseño porque nunca sobrescribe in-place; comete nuevos árboles consistentes.

Cuando RAID reconstruye, somete a estrés tu eslabón más débil

La reconstrucción/resilver lee enormes cantidades de datos. Es cuando aparecen errores latentes de lectura. Una reconstrucción RAID6 aún puede fallar
si hay demasiados sectores ilegibles en el momento equivocado. El resilver de ZFS puede ser más rápido en ciertos escenarios porque solo reconstruye bloques
asignados, no cada sector de un disco.

Broma #1: RAID es como una rueda de repuesto—estás contento de tenerla, hasta que te das cuenta de que llevaba meses desinflada.

Datos y contexto histórico importantes

1. ZFS se originó en Sun Microsystems a principios-mediados de los 2000, diseñado para combinar la gestión de volúmenes y el sistema de archivos en una única pila coherente.
2. Las sumas de verificación end-to-end fueron un punto central desde el principio: ZFS trata la corrupción silenciosa como un problema de primera clase, no como un caso límite.
3. Los snapshots copy-on-write no eran “agradables de tener”—están estructuralmente ligados a la consistencia transaccional y a actualizaciones seguras en disco.
4. RAID existe desde antes de los discos multi-terabyte modernos; muchas suposiciones de RAID se formaron cuando las ventanas de reconstrucción eran cortas y el riesgo de URE era menor.
5. Los controladores RAID por hardware se hicieron populares en parte para descargar CPU y estandarizar la gestión de discos, cuando las matemáticas de paridad y el caching importaban más.
6. El scrub de ZFS formalizó lo que muchos admins hacían manualmente: lecturas completas periódicas para sacar a la luz errores latentes antes de que sean pérdida de datos.
7. Los discos empresariales publicitan tasas URE (errores de lectura irreparables), recordándote que “un disco que aún no ha fallado” puede fallar durante la reconstrucción.
8. OpenZFS se convirtió en la línea multiplataforma, con desarrollo activo en illumos, FreeBSD, Linux y otros — importante porque los bugs de almacenamiento no respetan fronteras de SO.
9. “Bit rot” no es un único fenómeno; es un cajón para defectos de medio, bugs de firmware, escrituras mal dirigidas y fallas en RAM/cable/controlador.

Modos de fallo: cómo ocurre la corrupción en flotas reales

Escrituras mal dirigidas: la corrupción más aterradora que no ves venir

Una escritura mal dirigida ocurre cuando el sistema escribe los datos correctos en el lugar equivocado. Tu aplicación escribe el bloque A, pero
el disco/controlador lo escribe en el bloque B. Ambas escrituras “tienen éxito”. RAID refleja o protege por paridad la ubicación equivocada. Más tarde, las lecturas devuelven datos que pasan el ECC del disco, y RAID piensa que todo está bien.

ZFS detecta esto porque la suma almacenada en los metadatos para el bloque A no coincidirá con lo que ahora está en el bloque A. Con
redundancia, ZFS puede leer otra copia y reparar.

DMA / corrupción en memoria: lo que el sistema de archivos no puede arreglar si no lo detecta

Si una memoria RAM defectuosa voltea bits antes de que los datos lleguen al disco, el disco guarda contenido corrupto. RAID protegerá fielmente los bytes equivocados.
ZFS calculará una suma al escribir—por lo que si la corrupción ocurre antes del cálculo de la suma, la suma coincidirá con los datos corruptos y ZFS no podrá saber que estaban mal.

Por eso la memoria ECC importa en sistemas ZFS. ZFS es un sistema de integridad; aún necesita memoria confiable.

Escrituras parciales y ordenamiento: la pérdida de energía no es amable

Una pérdida repentina de energía puede crear escrituras partidas: parte viejo, parte nuevo. Algunos discos mienten sobre la finalización del flush. Algunos
controladores reordenan. Los sistemas de archivos intentan lidiar con journaling, barreras y flushes cuidadosos.

El modelo transaccional CoW de ZFS reduce la exposición, pero aún necesitas un orden de escritura sensato y semánticas de flush honestas.
Si tu disco reconoce escrituras que no persiste, aún puedes perder los últimos segundos de datos. La diferencia:
es menos probable que obtengas una estructura de sistema de archivos corrupta; es más probable perder transacciones recientes.

Sectores defectuosos: el villano clásico y aburrido

Los errores latentes de sector aparecen en el peor instante: durante una reconstrucción, scrub o restauración. RAID puede reconstruir si puede
identificar la lectura mala y aún tiene suficiente redundancia. ZFS puede hacer lo mismo, pero también valida la corrección con
sumas y puede reparar mientras el disco sigue en línea.

Broma #2: Los vendedores de almacenamiento prometen “cinco nueves”, pero nunca dicen si esos nueves se refieren al tiempo de actividad o a tu sueño.

Guion rápido de diagnóstico

Cuando sospechas corrupción o ves errores de ZFS, la rapidez importa. No porque ZFS sea frágil—sino porque cuanto más tiempo
operes degradado, más probable es que acumules fallos. Aquí hay un orden de operaciones rápido y práctico que funciona en
la vida real en on-call.

1) Confirma si es integridad (checksum) o fallo de E/S (lectura/escritura)

• Revisa zpool status -v primero. Si ves incrementos en CKSUM, eso significa “el dispositivo devolvió datos pero estaban mal”.
• Si ves errores READ o WRITE, eso es más un fallo clásico de dispositivo o transporte.

2) Determina si la redundancia puede sanarlo

• Espejos y RAIDZ pueden corregir muchos errores de checksum automáticamente.
• Los pools de un solo disco no pueden. Pueden detectar corrupción, pero no repararla.

3) Localiza el problema: un disco, un camino o sistémico

• Si los errores se agrupan en un miembro de vdev, sospecha ese disco, su cable, esa bahía o ese puerto HBA.
• Si múltiples discos en la misma HBA muestran problemas, sospecha el controlador, el backplane, el expander o el firmware.
• Si aparecen errores de checksum en muchos dispositivos sin patrón, sospecha memoria, inestabilidad de CPU o un bug de driver.

4) Decide: scrub, poner offline/reemplazar o detener escrituras

• Ejecuta un scrub si tienes redundancia y el pool está estable; sacará a la luz y arreglará más problemas.
• Pon en offline/reemplaza un dispositivo que acumula errores.
• Detén las escrituras (o congela las cargas) si ves corrupción activa sin una estrategia clara de contención.

5) Valida las copias de seguridad restaurando, no creyendo

Si se sospecha corrupción, haz una restauración real de datos representativos. ZFS protege lo que almacena, no lo que
tu sistema de backups pueda manejar mal.

Tareas prácticas: comandos, salidas y qué hacer después

A continuación hay tareas prácticas que espero que un operador ejecute durante la comisionación, la higiene semanal y la respuesta a incidentes.
Cada tarea incluye un comando realista, una salida típica, lo que significa y la decisión que tomas.

Task 1: Identificar corrupción vs fallo de E/S

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
  scan: scrub repaired 0B in 00:12:41 with 3 errors on Wed Dec 25 03:10:12 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sda     ONLINE       0     0     3
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/vmstore@auto-2025-12-24:/vm/guest1/disk0.img

Significado: Los errores CKSUM en sda indican datos malos devueltos sin un error de E/S. ZFS encontró al menos un error permanente en un archivo específico.

Decisión: Si existe redundancia, reemplaza sda y restaura o recrea el archivo afectado. Si el archivo es un disco de VM, trátalo como crítico: restaura desde un snapshot/copia conocida y buena.

Task 2: Iniciar un scrub (y saber qué hará)

cr0x@server:~$ sudo zpool scrub tank

Significado: Un scrub leerá los bloques asignados, validará sumas y reparará usando la redundancia.

Decisión: Programa scrubs regularmente; ejecuta uno después de reemplazar hardware o tras un evento sospechoso (pérdida de energía, recableado, reinicio de controlador).

Task 3: Comprobar el progreso del scrub y si está sanando o solo leyendo

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 01:20:41 2025
        412G scanned at 1.31G/s, 88G issued at 288M/s, 6.02T total
        0B repaired, 1.43% done, 06:12:11 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

Significado: “0B repaired” es bueno; si “repaired” aumenta, ZFS está sanando activamente.

Decisión: Si los bytes reparados suben repetidamente entre scrubs, considéralo un problema de ruta hardware (disco, cable, HBA) y no un evento cósmico aislado.

Task 4: Inspeccionar contadores de error a lo largo del tiempo

cr0x@server:~$ zpool status -p tank
  pool: tank
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     24
            sdb     ONLINE       0     0      0

Significado: Los errores CKSUM son contadores acumulativos. No se reinician automáticamente.

Decisión: Limpia contadores solo después de remediar y documentar. Si CKSUM sigue aumentando, reemplaza/reloca ese dispositivo y revisa la ruta.

Task 5: Borrar errores después de haber arreglado algo (no antes)

cr0x@server:~$ sudo zpool clear tank sda

Significado: Borra los contadores de error para sda para que nuevos errores sean visibles.

Decisión: Haz esto solo después de haber reinsertado/reemplazado hardware; de lo contrario estás borrando evidencia a mitad de la investigación.

Task 6: Listar datasets y puntos de montaje (para saber qué datos podrían estar afectados)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
NAME             USED  AVAIL  REFER  MOUNTPOINT
tank             4.12T  2.55T   128K  /tank
tank/vmstore     3.40T  2.55T  3.40T  /tank/vmstore
tank/backups      612G  2.55T   612G  /tank/backups

Significado: Puedes mapear problemas de salud del pool a datasets con impacto de negocio rápidamente.

Decisión: Si errores permanentes citan una ruta, identifica el dataset y decide si restaurar, rehidratar desde replicación o reconstruir datos generados.

Task 7: Encontrar snapshots (útil para revertir datos dañados)

cr0x@server:~$ zfs list -t snapshot -o name,creation -r tank/vmstore | tail
tank/vmstore@auto-2025-12-24-0100  Wed Dec 24 01:00 2025
tank/vmstore@auto-2025-12-25-0100  Thu Dec 25 01:00 2025
tank/vmstore@auto-2025-12-26-0100  Fri Dec 26 01:00 2025

Significado: Si la corrupción es reciente, un snapshot anterior al evento puede estar limpio.

Decisión: Considera clonar y validar antes de hacer rollback. No reviertas a ciegas un dataset muy activo sin coordinar con los responsables de la app.

Task 8: Validar propiedades del pool que influyen en la integridad

cr0x@server:~$ zfs get -o name,property,value -s local,default checksum,compression,recordsize tank/vmstore
NAME          PROPERTY     VALUE
tank/vmstore  checksum     on
tank/vmstore  compression  lz4
tank/vmstore  recordsize   128K

Significado: Las sumas están activadas por defecto; desactivarlas es autosabotaje.

Decisión: Deja checksum=on. Si heredas propiedades extrañas de plantillas, arréglalas antes de producción.

Task 9: Buscar dispositivos por IDs persistentes (evita la “ruleta sda”)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ata-|scsi-' | head
lrwxrwxrwx 1 root root  9 Dec 26 00:10 ata-ST8000NM000A_ZR123ABC -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 00:10 ata-ST8000NM000A_ZR123DEF -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 00:10 ata-ST8000NM000A_ZR123GHI -> ../../sdc

Significado: Nombres de dispositivo como /dev/sda pueden cambiar entre arranques; by-id es estable.

Decisión: Usa rutas by-id al crear pools y al reemplazar dispositivos para evitar cambiar el disco equivocado (un hobby real y popular).

Task 10: Comprobar SMART para señales tempranas

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep 'SMART overall-health|Reallocated_Sector_Ct|Current_Pending_Sector|UDMA_CRC_Error_Count'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       1
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       37

Significado: Sectores pendientes y errores CRC apuntan a problemas de medio y/o cabling. “PASSED” no significa “saludable”, significa “no muerto todavía”.

Decisión: Reemplaza el disco si los sectores pendientes persisten o las reasignaciones aumentan. Si los errores CRC suben, cambia cable/bahía y observa si cesan.

Task 11: Confirmar que el pool no esté accidentalmente sobre un volumen RAID del controlador

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MODEL
NAME        SIZE TYPE MODEL
sda       7.3T  disk ST8000NM000A
sdb       7.3T  disk ST8000NM000A
sdc       7.3T  disk ST8000NM000A
nvme0n1   1.8T  disk Samsung SSD 990

Significado: Si ves un único “disco” enorme que en realidad es un LUN RAID del controlador, ZFS no puede ver discos individuales y no puede hacer la auto-reparación por dispositivo correctamente.

Decisión: Prefiere el modo HBA/JBOD para ZFS. Si ya estás desplegado sobre un LUN RAID, planifica una migración; no esperes a que el controlador sea tu único punto de arrepentimiento.

Task 12: Reemplazar un disco que falla correctamente (ejemplo mirror)

cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-ST8000NM000A_ZR123ABC /dev/disk/by-id/ata-ST8000NM000A_ZR999XYZ

Significado: ZFS empieza a resilver hacia el disco nuevo.

Decisión: Monitoriza el resilver. No saques el disco viejo hasta ver el nuevo online y el resilver progresando.

Task 13: Monitorizar resilver e interpretar “resilvered X” correctamente

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: resilver in progress since Fri Dec 26 02:11:05 2025
        842G scanned at 780M/s, 216G issued at 200M/s, 2.90T total
        216G resilvered, 7.43% done, 05:41:32 to go
config:

        NAME                                                   STATE     READ WRITE CKSUM
        tank                                                   ONLINE       0     0     0
          mirror-0                                             ONLINE       0     0     0
            replacing-0                                        ONLINE       0     0     0
              /dev/disk/by-id/ata-ST8000NM000A_ZR123ABC        ONLINE       0     0    24
              /dev/disk/by-id/ata-ST8000NM000A_ZR999XYZ        ONLINE       0     0     0
            sdb                                                ONLINE       0     0     0

Significado: “issued” en resilver muestra lo que se está escribiendo; “scanned” incluye lo que se está comprobando. El disco viejo aún conserva historial de checksums; eso está bien.

Decisión: Si el resilver se ralentiza mucho, revisa carga de I/O, discos que fallan o un cuello de botella en el HBA. Si aparecen errores de checksum durante el resilver, pausa e investiga la ruta.

Task 14: Tras el resilver, verificar que no haya nuevos errores y ejecutar un scrub

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: resilvered 2.90T in 05:55:12 with 0 errors on Fri Dec 26 08:06:17 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdx     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

Significado: Resilver completado sin errores.

Decisión: Lanza un scrub poco después, especialmente si el incidente implicó inestabilidad de cables/controlador. Quieres confianza, no sensaciones.

Task 15: Revisar el historial de eventos ZFS para la cronología

cr0x@server:~$ sudo zpool events -v | tail -n 20
TIME                           CLASS
Dec 26 2025 01:18:43.221001000  ereport.fs.zfs.checksum
Dec 26 2025 02:11:05.102334000  sysevent.fs.zfs.resilver_start
Dec 26 2025 08:06:17.552190000  sysevent.fs.zfs.resilver_finish

Significado: Los eventos te dicen cuándo comenzaron los problemas de checksum y qué remediación ocurrió.

Decisión: Usa esto para correlacionar con ventanas de mantenimiento, actualizaciones de firmware, eventos de energía o picos de carga.

Task 16: Confirmar ashift y evitar trampas accidentales de rendimiento/latencia 512e

cr0x@server:~$ zdb -C tank | egrep 'ashift|path' | head -n 10
        path: /dev/disk/by-id/ata-ST8000NM000A_ZR123DEF
        ashift: 12
        path: /dev/disk/by-id/ata-ST8000NM000A_ZR123GHI
        ashift: 12

Significado: ashift=12 indica sectores de 4K. Un ashift incorrecto puede causar amplificación de escritura y timeouts que parecen discos inestables.

Decisión: Si ashift es incorrecto en un pool, planifica migración. No puedes cambiar ashift en sitio de forma segura en el caso general.

Tres micro-historias corporativas desde el terreno

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

Una empresa SaaS mediana ejecutaba un clúster de bases de datos sobre almacenamiento “enterprise”: SAN de controladores duales, RAID6, los acrónimos tranquilizadores habituales.
La suposición del equipo era simple: RAID6 significa que la corrupción de datos está básicamente resuelta. Se centraron en fallos de disco y unidades de repuesto, no en la integridad de datos.

Durante unos meses, vieron rarezas intermitentes en consultas: un subconjunto pequeño de filas fallaba comprobaciones a nivel de aplicación.
Nada consistente. No había fallos de disco obvios. Soporte de almacenamiento pidió logs, el equipo los recopiló y el problema
se negó educadamente a reproducirse en horario laboral.

El punto de inflexión fue una prueba de restauración (no durante una caída—solo un simulacro programado). La base de datos restaurada pasó
checksums a nivel de base de datos para la mayoría de tablas, pero un par de índices estaban sutilmente corruptos. Las copias de seguridad
habían capturado la corrupción porque la corrupción ya estaba presente y era silenciosa.

Migraron la carga a mirrors ZFS en servidores commodity con memoria ECC, ejecutaron scrubs semanales y habilitaron snapshots frecuentes.
Lo aterrador no fue que RAID fallara—hizo lo que prometía. La suposición equivocada fue creer que RAID
prometía corrección. RAID prometía “tu volumen permanece en línea cuando un disco muere.” Contrato distinto.

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

Otra organización tenía un clúster de virtualización con ZFS en Linux. El rendimiento iba bien, pero alguien quiso “mejores” números:
menor latencia, más IOPS. Añadieron un dispositivo L2ARC y ajustaron recordsize y cachés agresivamente. Entonces se atrevieron: deshabilitaron escrituras sync
al nivel del dataset para almacenamiento de VM porque “el UPS es sólido”.

Meses después, una actualización de firmware del controlador provocó un bucle de reinicio inesperado en un host. El UPS era de hecho sólido.
El host no lo fue. Tras el desastre, varias VMs no arrancaban. ZFS en sí estaba consistente—CoW hizo su trabajo—pero los sistemas de archivos invitados habían perdido transacciones que creían durables.

La optimización no fue el L2ARC. Fue la decisión de mentir sobre durabilidad. Desactivar sync es como quitarte el cinturón porque arruga la camisa. Parece genial hasta el primer frenazo.

Revirtieron la configuración, añadieron un dispositivo SLOG adecuado para cargas que necesitaban mejorar latencia de sync, e implementaron una checklist de revisión de cambios
específica para ajustes de durabilidad de almacenamiento. El rendimiento volvió a “suficientemente bueno” y la corrección volvió a “no negociable”.

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

Una empresa de servicios financieros usaba OpenZFS para almacenamiento de documentos. Nada glamuroso. El equipo tenía tres hábitos aburridos:
scrubs mensuales, pruebas de restauración trimestrales y la regla de que cualquier error de checksum desencadenaba una inspección física de toda la ruta: unidad, bahía, backplane, puerto HBA, cable.

Un mes, un scrub informó un puñado de reparaciones de checksum en un miembro de mirror. Sin cortes, sin quejas de usuarios. El ingeniero on-call abrió un ticket y siguió la regla: sacar SMART, revisar errores CRC, inspeccionar el cable SAS. SMART
mostraba conteos CRC en ascenso, pero el disco parecía bien por lo demás.

Cambiaron el cable y movieron el disco a otra bahía. Los errores pararon. En una tarea de mantenimiento posterior, encontraron que la bahía original del backplane tenía contacto intermitente bajo vibración.

Nadie escribió una novela postmortem porque nada cayó. Ese es el punto. La práctica aburrida convirtió una historia de “corrupción silenciosa algún día” en un no-evento.

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

1) Síntoma: aumentan errores CKSUM, pero SMART dice “PASSED”

Causa raíz: El estado general SMART es demasiado burdo; los errores de checksum a menudo indican transporte, firmware o escrituras mal dirigidas, no solo medio moribundo.

Solución: Revisa atributos SMART (CRC/pending/realloc), intercambia cables, cambia bahías, actualiza firmware HBA y reemplaza el disco si los errores persisten después de remediar la ruta.

2) Síntoma: errores permanentes en archivos después del scrub

Causa raíz: ZFS detectó corrupción pero no pudo reparar porque la redundancia era insuficiente, todas las réplicas estaban malas o los datos corruptos fueron sobrescritos.

Solución: Restaura archivos afectados desde backup o un snapshot/replica limpia. Luego investiga por qué la redundancia no te salvó (vdev de un solo disco, pool degradado durante el evento, fallos múltiples).

3) Síntoma: scrubs tardan una eternidad e impactan mucho el rendimiento

Causa raíz: I/O insuficiente, tormentas de retries por discos que fallan o diseño de pool que obliga lecturas amplias. A veces es simplemente “construiste un pool muy ocupado y programaste el scrub en hora punta”.

Solución: Ejecuta scrubs fuera de pico, investiga dispositivos lentos, limita prioridad de scrub/resilver donde sea posible y considera más vdevs/espejos para paralelismo.

4) Síntoma: el controlador RAID muestra saludable, pero ZFS dentro de una VM reporta corrupción

Causa raíz: ZFS no puede ver discos físicos; ve un disco virtual o LUN RAID. La corrupción puede introducirse debajo del guest.

Solución: Prefiere pasar HBAs/discos a ZFS (modo JBOD/HBA) o ejecuta ZFS en el host. Si debes virtualizar, asegúrate de que la capa inferior provea garantías de integridad y semánticas de flush estables.

5) Síntoma: tras eventos de energía, las apps se quejan por escrituras perdidas, pero el pool ZFS está “ONLINE”

Causa raíz: Se deshabilitaron escrituras sync, o discos/controladores mintieron sobre flush de caché, o la carga esperaba durabilidad que no se proporcionó.

Solución: Vuelve a habilitar semánticas sync, usa un SLOG adecuado si es necesario y verifica políticas de caché de escritura. Trata “reconocido pero no durable” como pérdida de datos por diseño.

6) Síntoma: errores repetidos en múltiples discos del mismo host

Causa raíz: Fallo de ruta común: HBA, expander, backplane, firmware, alimentación o inestabilidad de memoria.

Solución: Mueve un disco a un camino controlador distinto y observa. Actualiza firmware. Revisa dmesg por resets de enlace. Valida salud ECC y ejecuta diagnóstico de memoria.

7) Síntoma: reemplazar un disco no detiene errores de checksum

Causa raíz: Reemplazaste a la víctima, no al culpable. A menudo es el cableado, la bahía o el controlador, o el modelo/firmware del disco tiene un problema conocido.

Solución: Cambia cable, cambia bahía, actualiza firmware y si hace falta reemplaza el HBA. Rastrea errores por slot físico y by-id, no por nombres sda.

Listas de verificación / plan paso a paso

Checklist de comisionamiento (antes de tráfico de producción)

1. Usa memoria ECC. Si no puedes, al menos reconoce el riesgo explícitamente en la revisión de diseño.
2. Usa HBAs en modo IT/JBOD, no volúmenes RAID por hardware, para que ZFS pueda ver y gestionar discos directamente.
3. Construye pools con rutas de dispositivo persistentes (/dev/disk/by-id).
4. Elige redundancia apropiada al radio de impacto: mirrors para IOPS y resilver rápido; RAIDZ para capacidad con expectativas de reconstrucción cuidadosas.
5. Establece y documenta el calendario de scrubs (común: mensual para pools grandes, más a menudo para datos críticos).
6. Habilita snapshots y replicación; decide retenciones basadas en objetivos de recuperación, no en deseo.
7. Prueba restauración de datasets representativos antes de poner en producción.

Checklist de higiene operacional (semanal/mensual)

1. Revisa zpool status en todas las flotas; alerta por deltas no nulos en READ/WRITE/CKSUM.
2. Revisa atributos SMART por tendencias, no solo por flags de fallo.
3. Ejecuta scrubs programados; verifica que completen y si repararon algo.
4. Monitorea tiempos de resilver; el aumento en duración es una alarma temprana de discos envejeciendo o diseño sobrecargado.
5. Realiza una prueba de restauración trimestral. Elige muestras aleatorias y verifica realmente la integridad a nivel de aplicación.

Plan de respuesta a incidentes (errores de checksum detectados)

1. Congela cambios riesgosos. Para los “apresurados” reinicios y actualizaciones de firmware durante el incidente.
2. Ejecuta zpool status -v y captura la salida para el ticket.
3. Si existe redundancia, lanza un scrub y monitoriza reparaciones y nuevos errores.
4. Inspecciona SMART y dmesg por resets de enlace y errores CRC; cambia cables/bahías si corresponde.
5. Reemplaza dispositivos que sigan acumulando errores. Usa zpool replace con rutas by-id.
6. Tras la remediación, limpia contadores, vuelve a hacer scrub y confirma estabilidad por al menos un ciclo completo de scrub.
7. Restaura archivos/VMs afectados desde snapshots o backups; valida a nivel de aplicación.
8. Anota qué se reemplazó (serial del disco, bahía, cable) para que el siguiente ingeniero no repita la misma danza.

Preguntas frecuentes

¿ZFS previene toda la corrupción?

No. ZFS detecta corrupción en disco y corrupción en la ruta de I/O después de la suma de verificación. Si los datos se corrompen en RAM antes de que se calcule la suma, ZFS almacenará fielmente los datos corruptos con una suma coincidente. Usa memoria ECC y hardware estable.

Si ya tengo RAID, ¿sigo necesitando ZFS?

Si tu prioridad es la corrección, necesitas una capa de integridad end-to-end en algún lugar. ZFS la proporciona en la capa de sistema de archivos+volumen. RAID proporciona redundancia de dispositivo. Combinarlos suele ser redundante de forma negativa (complejidad) a menos que uses RAID como una abstracción JBOD simple—mejor reemplazada por modo HBA.

¿Por qué ZFS reporta errores de checksum cuando el disco dice que está bien?

Porque el disco puede devolver datos equivocados sin reportar error (bugs de firmware, lecturas mal dirigidas, corrupción en el transporte). ZFS valida el contenido, no la confianza del dispositivo.

¿Cuál es la diferencia entre errores READ y CKSUM en zpool status?

READ indica que el dispositivo no pudo devolver datos (fallo de E/S). CKSUM indica que devolvió datos, pero no coincidían con la suma esperada. CKSUM suele ser más alarmante porque implica corrupción silenciosa.

¿Con qué frecuencia debo ejecutar scrubs?

Mensualmente es un punto de partida común para pools multi-terabyte. Más a menudo para datos críticos o hardware menos fiable. La respuesta correcta es: lo suficiente para que los errores latentes se encuentren mientras la redundancia aún existe y antes de que las copias de seguridad caduquen.

¿Un scrub arreglará la corrupción?

Si tienes redundancia y al menos una copia buena existe, sí—ZFS puede auto-reparar durante el scrub. Si tienes un vdev de un solo disco, el scrub detecta corrupción pero no puede repararla. Si todas las copias están malas, tocará restaurar desde backup en cualquier caso.

¿Los mirrors son más seguros que RAIDZ?

Los mirrors tienden a resilverizar más rápido y son operativamente más simples; también ofrecen mejor IOPS de lectura aleatoria. RAIDZ es eficiente en capacidad pero puede tener ventanas de reconstrucción más largas y dominios de fallo más amplios. “Más seguro” depende de la carga, el tamaño del disco y la disciplina operativa. Si no haces scrubs regularmente, ninguno es seguro.

¿Puedo ejecutar ZFS sobre un volumen RAID por hardware?

Puedes, pero estás cegando a ZFS respecto al comportamiento de discos físicos y estás empujando la confianza hacia el controlador RAID. Pierdes parte de la capacidad de ZFS para localizar fallos y auto-reparar en la capa correcta. Si te importa la integridad, da a ZFS acceso directo a los discos.

¿Qué debo hacer cuando ZFS reporta “Permanent errors”?

Trátalo como pérdida de datos para los archivos referenciados. Restaura desde backup o un snapshot/replica limpio, luego arregla el problema subyacente del hardware/ruta y vuelve a hacer scrub. No asumas “se curó solo” si dice permanent.

¿La compresión o recordsize afectan la detección de corrupción?

Las sumas siguen funcionando. La compresión cambia los bloques físicos escritos, pero siguen siendo sumados. El recordsize afecta patrones de I/O y comportamiento de reconstrucción, lo que puede influir en cuán rápido notas problemas y cuán dolorosos son los scrubs/resilvers.

Siguientes pasos prácticos

Si usas RAID y crees que estás “cubierto”, decide qué quieres realmente: ¿disponibilidad o corrección? Si lo que quieres es corrección, añade una capa de integridad end-to-end. ZFS es una de las pocas que lo hace de forma comprensiva y operativa.

1. Habilita (y realmente monitoriza) scrubs de ZFS. Ponlos en calendario y alerta sobre reparaciones y errores.
2. Diseña para redundancia que pueda sanar: mirrors o RAIDZ/dRAID con ventanas de reconstrucción realistas.
3. Usa memoria ECC y HBAs en modo JBOD/IT para que ZFS vea discos reales.
4. Cuando aparezcan errores de checksum, no discutas con ellos. Localiza la ruta, reemplaza al culpable, vuelve a hacer scrub y restaura los datos afectados.
5. Prueba backups restaurando. La corrupción que ya está en la fuente se propagará gustosamente a copias de seguridad “perfectamente exitosas”.

La ganancia operativa es simple: ZFS convierte la corrupción silenciosa en corrupción ruidosa. Los problemas ruidosos se arreglan. Los silenciosos se convierten en incidentes.