Errores de checksum ZFS en Proxmox: disco o cable — cómo demostrarlo

diciembre 26, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 10

¿Te fue útil?

Tienes un equipo Proxmox. ZFS había sido aburrido (el mejor tipo de almacenamiento). Entonces una mañana lo ves: CKSUM incrementándose en zpool status. El pool sigue online, las máquinas virtuales siguen arrancando, y tu cerebro ya está negociando: “Probablemente es solo un artefacto del scrub.”

No. Los errores de checksum de ZFS son ZFS haciendo su trabajo: decirte que leyó bytes que no coincidían con lo que escribió antes. Tu tarea es demostrar dónde ocurrió la corrupción: en el plato/NAND, en la electrónica del disco, en el cable, en el backplane o en el HBA. Adivinar es la forma de comprar la pieza equivocada dos veces.

Qué significan realmente los errores de checksum de ZFS (y qué no significan)

ZFS almacena checksums para los bloques y los verifica al leer. Si el checksum no coincide, ZFS lo marca como un error de checksum. Eso es una afirmación sobre los datos cuando se leyeron, no una confesión del disco. El disco puede devolver “éxito” mientras devuelve bytes incorrectos; ZFS lo nota de todos modos.

Aquí está la matiz importante:

Los errores de checksum son fallos de integridad de datos de extremo a extremo. La corrupción puede estar en el medio físico, en el firmware del disco, en el controlador, en el cable, en el backplane, en el expander, en la RAM, en DMA o en problemas del kernel/controlador.
ZFS a menudo puede repararlos automáticamente si existe redundancia (mirror/RAIDZ) y la copia mala puede ser reemplazada por una buena. Por eso puedes ver errores de checksum sin fallos visibles en las aplicaciones—hasta que no.
No son lo mismo que errores de lectura. Un error de lectura es “no pude leer el sector.” Un error de checksum es “leí algo, pero no es lo que escribiste antes.”

Si ejecutas mirrors o RAIDZ, ZFS puede indicarte qué miembro del vdev entregó los datos malos. Ese es tu punto de partida. Pero “qué dispositivo entregó bytes malos” no siempre es “qué dispositivo está defectuoso.” Los cables y los HBA se interponen y adoran las fallas intermitentes.

Una cita para llevar en el bolsillo: “La única confiabilidad real es la confiabilidad que mides.” — John Allspaw (idea parafraseada)

Guía rápida de diagnóstico (primero/segundo/tercero)

Si estás en producción, no tienes tiempo para convertirte en filósofo sobre entropía. Necesitas una vía rápida hacia las causas probables y luego recopilar evidencias hasta que puedas justificar un cambio de pieza.

Primero: confirma el alcance y si ZFS reparó algo

¿El pool está degradado, o solo muestra errores históricos?
¿Los errores están aumentando ahora mismo, o se quedaron en un solo número?
¿zpool status -v lista rutas de archivo (metadatos) o solo conteos?

Segundo: correlaciona los errores de ZFS con errores del transporte del kernel

Busca reinicios de enlace ata, I/O error, comandos “frozen”, reinicios de phy SAS phy reset o datos de SCSI sense alrededor de los mismos momentos de scrubs/resilvers.
Si ves inestabilidad del transporte, tu “disco malo” podría ser en realidad un cable, una bahía del backplane o un puerto del HBA.

Tercero: usa los logs SMART/NVMe para separar fallo de medio de fallo de transporte

El fallo de medio aparece como sectores realocados/pending/uncorrectable (HDD) o errores de integridad de medio/datos (NVMe).
El fallo de transporte aparece como errores CRC (SATA), reinicios/en tiempos de espera de enlace (SAS/SATA), pero puede dejar los contadores SMART de medio limpios.

Luego decides: ¿cambiar primero el cable/slot (barato, rápido) o cambiar primero el disco (también rápido, pero más riesgoso si en realidad es el slot y “contaminas” el reemplazo)?

Datos interesantes y contexto (porque la historia se repite)

La sumación de extremo a extremo de ZFS fue una reacción a la “corrupción silenciosa de datos” en pilas tradicionales donde el sistema de archivos confía ciegamente en el disco.
Los contadores de CRC de ATA UDMA existen porque incluso en los años 90, los ingenieros aceptaron que los cables y conectores son dispositivos de falla, no accesorios.
Los backplanes SAS empresariales introdujeron expanders y más conectores—más flexibilidad, más lugares donde la integridad de la señal puede fallar.
Los cables SATA de consumo varían mucho en calidad; algunos son esencialmente decorativos, especialmente a 6 Gb/s con tolerancias ajustadas.
Los scrubs de ZFS son intencionalmente aburridos: leen todo y verifican checksums, por eso tienden a “descubrir” primero los enlaces débiles.
Las mentiras del cache de escritura son más antiguas que tu carrera: un disco/controlador puede reconocer una escritura y luego perderla. Los checksums de ZFS detectan las consecuencias en la lectura.
El comportamiento CMR vs SMR en HDD puede generar picos largos de latencia I/O que parecen timeouts; los timeouts pueden activar reinicios que parecen “cable malo,” incluso cuando el disco está simplemente sobrecargado.
La RAM ECC importa porque ZFS usa RAM de forma agresiva; la corrupción en RAM puede convertirse en “errores de checksum” después. Es más rara que los cables, pero no mítica.

Un marco de evidencias: dónde puede ocurrir la corrupción

Cuando ZFS muestra errores de checksum para /dev/sdX, necesitas decidir a quién acusar:

El medio del disco (superficie/celdas NAND)
La electrónica/firmware del disco
El transporte (cable SATA, cable SAS, conectores)
El backplane/expander (bahía, trazas, chip expander)
El HBA/controlador (puerto, firmware, errores PCIe)
El host (RAM, PCIe, alimentación, driver del kernel)

El truco es evitar el fallo clásico de lógica: “ZFS culpó al disco, así que el disco está malo.” ZFS no tiene una tabla Ouija. Tiene un nodo de dispositivo y lo que esa ruta entregó en el momento de la lectura.

Cómo suele verse “el disco está malo”: SMART muestra sectores realocados/pending/uncorrectable; los errores persisten incluso al moverlo a otro puerto/cable; los errores de ZFS continúan en el mismo disco físico a través de movimientos.

Cómo suele verse “el cable/slot está malo”: Los contadores SMART del medio limpios, pero el UDMA CRC sube (SATA) o los logs del kernel muestran reinicios de enlace; reemplazar/mover el cable/slot hace que los errores se detengan, incluso con el mismo disco.

Chiste #1 (corto, relevante): Un cable SATA intermitente es el tipo de “alta disponibilidad” que no pediste: falla solo cuando lo miras.

Tareas prácticas (comandos, salidas, decisiones)

Estas son las tareas que realmente ejecuto en hosts Proxmox/Debian. Cada una incluye qué buscar y qué decisión impulsa. Hazlas en orden si puedes; salta si la producción está en llamas.

Task 1 — Capturar una línea base limpia: estado del pool con detalles

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 02:11:43 with 3 errors on Sun Dec 22 03:12:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     3
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     0

errors: No known data errors

Qué significa: ZFS vio desajustes de checksum en un dispositivo y los corrigió usando redundancia (mirror). El pool sigue online.

Decisión: Trátalo como una señal real de integridad. Empieza el trabajo de correlación antes de limpiar los contadores. No reemplaces nada aún a menos que los errores suban rápido o el pool esté degradado.

Task 2 — Identificar la ruta exacta del dispositivo que usa ZFS

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WD80EFZX
lrwxrwxrwx 1 root root  9 Dec 26 09:20 ata-WDC_WD80EFZX-68... -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 09:20 ata-WDC_WD80EFZX-68... -> ../../sdc

Qué significa: Puedes mapear los nombres de los miembros de ZFS a /dev/sdX para correlacionar SMART y logs del kernel.

Decisión: Trabaja con los nombres en /dev/disk/by-id en los comandos de ZFS (estables) y mapea a /dev/sdX solo para diagnóstico.

Task 3 — Extraer errores recientes del kernel para ese disco (el transporte SATA/SAS se delata)

cr0x@server:~$ sudo journalctl -k --since "24 hours ago" | egrep -i "sdb|ata|scsi|sas|link reset|I/O error" | tail -n 30
Dec 26 02:41:12 server kernel: ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
Dec 26 02:41:12 server kernel: ata6: SError: { CommWake DevExch PhyRdyChg }
Dec 26 02:41:12 server kernel: ata6.00: failed command: READ FPDMA QUEUED
Dec 26 02:41:12 server kernel: ata6: hard resetting link
Dec 26 02:41:13 server kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 26 02:41:15 server kernel: sd 5:0:0:0: [sdb] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 26 02:41:15 server kernel: sd 5:0:0:0: [sdb] Sense Key : Medium Error [current]
Dec 26 02:41:15 server kernel: sd 5:0:0:0: [sdb] Add. Sense: Unrecovered read error

Qué significa: Estás viendo reinicios de enlace y un error de lectura. Eso puede ser un disco, pero la inestabilidad del transporte está fuertemente sugerida por reinicios/frozen commands repetidos.

Decisión: Si ves muchos reinicios de enlace y ruido de SError, planea una prueba de mover cable/slot. Pero también verifica SMART por errores reales de medio, porque ambos pueden ser verdaderos.

Task 4 — Revisar salud SMART y los contadores que separan “medio” de “transporte” (HDD/SATA)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i "Serial Number|SMART overall|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count"
Serial Number:    WD-ABC123XYZ
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       12

Qué significa: Los contadores de medio están limpios (0), pero existen errores CRC. Los errores CRC son clásicos de problemas de cable/conector/backplane en SATA.

Decisión: Reemplaza el cable SATA o mueve el disco a otra bahía/puerto primero. No hagas RMA a un disco perfectamente sano porque un cable de $3 tiene personalidad propia.

Task 5 — Para NVMe, revisar logs de errores y errores de medio (vocabulario distinto)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i "critical_warning|media_errors|num_err_log_entries|temperature|percentage_used"
critical_warning                    : 0x00
temperature                         : 42 C
percentage_used                     : 3%
media_errors                        : 0
num_err_log_entries                 : 0

Qué significa: NVMe no reporta errores de medio. Eso no lo exime completamente, pero reduce la probabilidad de degradación de NAND real.

Decisión: Si errores de checksum de ZFS aparecen en NVMe con estadísticas de medio limpias, inspecciona errores PCIe, alimentación, firmware y la ranura de la placa base.

Task 6 — Revisar errores PCIe/AER (especialmente para HBAs y NVMe)

cr0x@server:~$ sudo journalctl -k --since "7 days ago" | egrep -i "AER|pcie|Corrected error|Uncorrected" | tail -n 40
Dec 25 11:03:18 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:03:00.0
Dec 25 11:03:18 server kernel: pcieport 0000:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
Dec 25 11:03:18 server kernel: pcieport 0000:00:1c.0: AER: [ 0] RxErr

Qué significa: Los errores de capa física pueden manifestarse como rarezas de almacenamiento. “Corrected” no significa “inofensivo”; significa “lo notamos y lo corregimos, hasta que no.”

Decisión: Si esto se correlaciona con errores de ZFS, considera volver a asentar el HBA/NVMe, probar otra ranura, actualizar firmware y revisar alimentación/temperaturas.

Task 7 — Ejecutar un scrub de ZFS y observar si los errores de checksum aumentan durante lecturas sostenidas

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ watch -n 30 "zpool status tank"
Every 30.0s: zpool status tank

  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 09:31:12 2025
        1.32T scanned at 682M/s, 920G issued at 475M/s, 6.12T total
        0B repaired, 0.00% done, 03:45:12 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     5
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     0

Qué significa: El conteo de CKSUM está aumentando durante el scrub. Eso es un fallo activo, no un residuo histórico.

Decisión: Deja de tratar esto como tareas de mantenimiento. Planea mitigación inmediata: reduce la carga, prepara un camino de reemplazo y comienza a aislar el transporte (cambiar cable/slot) o el disco (reemplazar) según la evidencia.

Task 8 — Limpiar contadores solo después de haber capturado evidencias

cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:11:43 with 0 errors on Thu Dec 26 12:05:01 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     0

Qué significa: Los contadores se reiniciaron. Genial para seguir recurrencias, terrible si lo hiciste antes de recopilar logs.

Decisión: Limpia solo después de guardar zpool status -v y los fragmentos relevantes de journalctl. Si los errores vuelven rápido, tienes evidencia de un problema en curso.

Task 9 — Revisar auto-tests SMART (no son perfectos, pero son evidencia admisible)

cr0x@server:~$ sudo smartctl -t long /dev/sdb
Please wait 728 minutes for test to complete.
cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i "Self-test execution|# 1|error"
Self-test execution status:      241 (The previous self-test routine completed with a read failure)
# 1  Extended offline    Completed: read failure       90%     54123         12345678

Qué significa: Un test largo encontró una falla de lectura. Eso es un indicador fuerte de problema de medio/disco, no solo de cable. (Los cables aún pueden causar fallas de lectura, pero el registro SMART de fallas de lectura tiende a implicar al disco.)

Decisión: Si los tests largos fallan, prioriza reemplazar el disco. Aún verifica el cableado si los CRC también están subiendo, porque un cable malo puede hacer que un disco bueno parezca culpable.

Task 10 — Para SATA, vigilar `UDMA_CRC_Error_Count` en el tiempo (no debería crecer)

cr0x@server:~$ sudo smartctl -A /dev/sdb | awk '$2==199 || /UDMA_CRC_Error_Count/ {print}'
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       12
cr0x@server:~$ sleep 60
cr0x@server:~$ sudo smartctl -A /dev/sdb | awk '$2==199 || /UDMA_CRC_Error_Count/ {print}'
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       14

Qué significa: Los errores CRC aumentaron mientras el sistema estaba en marcha. Eso casi nunca es “medio del disco.” Es integridad de señal: cable, conector o backplane.

Decisión: Reemplaza el cable, vuelve a asentar los conectores, cambia de puerto/slot. Tras el cambio, el conteo CRC debería dejar de aumentar. No se reiniciará, pero debería quedar plano.

Task 11 — Mapear el disco a una bahía física (para no cambiar lo equivocado a las 2 a.m.)

cr0x@server:~$ sudo lsblk -o NAME,SERIAL,MODEL,SIZE,WWN,HCTL
NAME   SERIAL         MODEL         SIZE WWN                HCTL
sdb    WD-ABC123XYZ   WDC WD80EFZX  7.3T 0x50014ee2b1c2d3e4 5:0:0:0
sdc    WD-DEF456UVW   WDC WD80EFZX  7.3T 0x50014ee2b1c2d3e5 6:0:0:0

Qué significa: Tienes seriales y HCTL. Con HBAs/backplanes, HCTL ayuda a mapear a un puerto/bahía. Con SAS, puedes profundizar usando direcciones SAS.

Decisión: Pon etiquetas en bandejas/cables. Si no puedes mapear físico a lógico de forma fiable, terminarás reemplazando el disco sano y dejando el roto.

Task 12 — Revisar topología SAS y eventos de enlace (para HBA/backplanes SAS)

cr0x@server:~$ sudo sas2ircu 0 DISPLAY | egrep -i "Enclosure|Slot|Serial|PHY|Link Rate|Error"
Enclosure# : 1
Slot #     : 4
Serial No  : WD-ABC123XYZ
PHY Error Count : 19
Negotiated Link Rate : 6.0 Gbps

Qué significa: Errores PHY y problemas de negociación de enlace implican transporte o la ruta expander/backplane. Una sola bahía mostrando errores mientras otras están limpias es una flecha brillante apuntando a la bahía.

Decisión: Mueve el disco a otra bahía del mismo enclosure/backplane. Si los errores siguen al disco, es el disco. Si los errores se quedan en la bahía, es el backplane/canal del HBA/cableado.

Task 13 — Revisar estadísticas de error SATA en sysfs (útil cuando SMART es ruidoso o incompleto)

cr0x@server:~$ for h in /sys/class/ata_link/link*/ata_link/*/dev*/../.. 2>/dev/null; do :; done
cr0x@server:~$ sudo grep -R . /sys/class/ata_link/link*/sata_spd 2>/dev/null | head
/sys/class/ata_link/link5/sata_spd:6.0 Gbps
/sys/class/ata_link/link6/sata_spd:6.0 Gbps

Qué significa: Puedes confirmar la velocidad del enlace y a veces detectar disminuciones tras reinicios. Un enlace que repetidamente baja de 6.0 a 3.0 Gbps bajo carga es sospechoso.

Decisión: Si las bajadas se correlacionan con errores, trátalo como integridad de cabling/backplane. Reemplaza/vuelve a asentar y luego verifica estabilidad.

Task 14 — Leer el disco sospechoso con estrés (con cuidado) y observar logs

cr0x@server:~$ sudo dd if=/dev/sdb of=/dev/null bs=8M status=progress
118111600640 bytes (118 GB, 110 GiB) copied, 25 s, 4.7 GB/s
240019120128 bytes (240 GB, 224 GiB) copied, 55 s, 4.4 GB/s
^C
cr0x@server:~$ sudo journalctl -k --since "5 minutes ago" | egrep -i "sdb|ata|reset|I/O error" | tail -n 20
Dec 26 09:52:41 server kernel: ata6: hard resetting link
Dec 26 09:52:45 server kernel: ata6.00: configured for UDMA/133
Dec 26 09:52:46 server kernel: blk_update_request: I/O error, dev sdb, sector 123456789 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0

Qué significa: Bajo lecturas sostenidas, el enlace se reinició y los errores I/O reaparecieron. Eso no es “ZFS dramático.” Es la estabilidad del transporte o disco rompiéndose bajo carga.

Decisión: Si dd reproduce consistentemente reinicios de enlace, puedes reproducir la falla. Reproduce una vez antes y otra vez después de cambiar cable/slot. Eso te da “prueba,” no sensaciones.

Task 15 — Verificar integridad de memoria (raro, pero catastrófico cuando es la causa)

cr0x@server:~$ sudo dmesg -T | egrep -i "EDAC|MCE|Machine check|memory error" | tail -n 20
[Thu Dec 26 07:11:32 2025] EDAC MC0: 1 CE memory scrubbing error on CPU#0Channel#1_DIMM#0

Qué significa: Se registran errores ECC corregibles. No es una acusación inmediata, pero significa que la plataforma no está impoluta. Los sistemas sin ECC no registrarán esto; simplemente corromperán y sonreirán.

Decisión: Si ves actividad MCE/EDAC y errores de checksum ZFS en múltiples vdevs/dispositivos, amplía el ámbito a RAM/CPU/placa base antes de reemplazar una pila de “discos malos”.

Task 16 — Cuando decidas reemplazar, hazlo al estilo ZFS (y conserva la evidencia)

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFZX-68... /dev/disk/by-id/ata-WDC_WD80EFZX-NEW123
cr0x@server:~$ watch -n 30 "zpool status tank"
Every 30.0s: zpool status tank

  pool: tank
 state: ONLINE
  scan: resilver in progress since Thu Dec 26 10:12:40 2025
        1.88T scanned at 512M/s, 1.02T issued at 278M/s, 6.12T total
        1.02T resilvered, 16.66% done, 05:12:11 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
              ata-WDC_WD80EFZX-68...                      ONLINE       0     0     0
              ata-WDC_WD80EFZX-NEW123                     ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...                        ONLINE       0     0     0

Qué significa: El resilver está reconstruyendo la redundancia. Observa si aparecen nuevos errores de checksum durante el resilver; resilver es una prueba de estrés que a menudo desenmascara cables marginales.

Decisión: Si aparecen errores de checksum en el disco nuevo inmediatamente, deja de culpar a los discos. Comienza a culpar al puerto, al cable, a la línea del expander o al HBA.

Tres microhistorias del mundo corporativo (cómo esto sale mal)

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

Una empresa mediana ejecutaba Proxmox en unos cuantos servidores commodity. Pools de arranque en espejo ZFS, RAIDZ para almacenamiento de VM. Un host empezó a mostrar errores de checksum en un solo disco. El ingeniero de guardia hizo lo que todo el mundo hace bajo estrés: reemplazó el disco. Los errores se detuvieron. Todos volvieron a dormir.

Dos semanas después, los errores de checksum regresaron—esta vez en el disco de reemplazo. Eso desencadenó la hipótesis de “lote malo de discos”. Otro reemplazo siguió. Mismo cuento: silencio por un rato, luego errores otra vez.

La suposición equivocada fue sutil: “Si el error aparece en el disco, el disco es la causa.” Nunca revisaron los contadores CRC SATA. Nunca miraron dmesg por reinicios de enlace. La bahía física compartía un cable que había sido doblado fuertemente durante una ventana de mantenimiento apresurada.

Cuando finalmente cambiaron el cable y movieron el disco a una posición diferente del backplane, el conteo CRC dejó de subir inmediatamente. Los discos “malos” originales, probados en otro lugar, estaban bien. La empresa pagó por tres discos y perdió una noche de sueño porque trataron un problema de transporte como un problema de medio.

La lección que quedó: ZFS dijo la verdad (“llegaron bytes malos”), pero no dijo toda la verdad (“dónde se estropearon”). Tienes que interrogar la ruta.

Microhistoria #2: La optimización que salió mal

Un gran equipo de plataforma interno quería reconstrucciones más rápidas y mejor rendimiento para VM. Añadieron un HBA con más puertos y pasaron de SATA directo a un backplane SAS con expander para simplificar el cableado. El rack quedó más limpio. La hoja de inventario quedó más limpia. A todos les gusta lo limpio.

Entonces los tiempos de scrub se volvieron impredecibles. Algunos scrubs iban a toda velocidad; otros avanzaban como caracoles. Algunos hosts mostraron errores de checksum intermitentes, siempre “corregidos”, nunca “fatales”. Ese es el tipo de problema de almacenamiento más peligroso porque entrena a la gente a ignorarlo.

La “optimización” fue que usaron cables mini-SAS de calidad mixta y los enrutaron cerca de la distribución de potencia. El expander más las longitudes de cable mayores redujeron los márgenes de señal. Bajo I/O pico (scrubs más snapshots de VM), la ruta a veces fallaba. ZFS hizo lo que hace: detectó la discrepancia, buscó datos buenos en la paridad/espejo y sanó. La plataforma parecía bien—hasta que un día un segundo disco en el mismo vdev se desconectó durante un resilver y la ventana de recuperación se volvió estrecha y sudorosa.

Lo arreglaron por medios aburridos: cables de mayor calidad, menos enrutamiento agresivo y mover el HBA a una ranura con menos errores PCIe corregidos. El rendimiento se mantuvo. Más importante, los scrubs se volvieron consistentes y los errores de checksum dejaron de aparecer como alergias estacionales.

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

Un equipo vinculado a finanzas ejecutaba Proxmox con espejos ZFS para bases de datos críticas. Su entorno no era sofisticado, pero tenían el hábito: scrubs mensuales programados y un runbook interno que exigía “resultados de scrub + deltas SMART” para revisión.

Un mes, el informe de scrub mostró dos errores de checksum en un miembro del mirror. No cientos. Solo dos. SMART parecía limpio salvo por un contador CRC que había aumentado en uno. Nada más. Ningún ticket de usuarios. La tentación era encogerse de hombros.

El runbook obligó al siguiente paso: limpiar contadores, cambiar el cable, volver a ejecutar un scrub dentro de 48 horas y comparar. Tras cambiar el cable, el CRC dejó de aumentar. El scrub se completó limpio. Dejaron el disco en su lugar.

Tres meses después, el mismo host tuvo un evento de energía (mantenimiento de UPS fallido). Los discos lo manejaron, pero ese cable viejo probablemente habría hecho la recuperación más fea. En su lugar, el pool arrancó limpio. El equipo no “salvó el día” con heroísmos. Lo salvó por ser monótono según el calendario.

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

Aquí es donde la mayoría de los hilos de errores de checksum ZFS mueren: síntomas vagos y cambios de piezas por cargo-culto. Aquí hay patrones específicos que aparecen en hosts Proxmox.

1) CKSUM aumenta durante scrub, SMART de medio parece perfecto

Síntoma: zpool status muestra CKSUM subiendo; Reallocated/Pending/Uncorrectable son cero.
Probable causa raíz: Cable SATA o conector del backplane causando errores CRC; o errores PHY SAS.
Solución: Reemplazar cable, volver a asentar ambos extremos, mover a otro puerto/slot, luego volver a ejecutar scrub y confirmar que CRC/PHY dejan de aumentar.

2) Un disco muestra CKSUM, luego el disco de reemplazo muestra CKSUM en la misma bahía

Síntoma: Reemplazaste el disco; los errores vuelven en el nuevo.
Probable causa raíz: Bahía/bucle del backplane malo, puerto de expander o puerto del HBA.
Solución: Conserva el disco nuevo, muévelo a otra bahía; si puedes, coloca otro disco conocido bueno en la bahía sospechosa como prueba. Si los errores se quedan con la bahía, repara/reemplaza el backplane o cambia el puerto del HBA.

3) Errores CHECKSUM en múltiples discos a la vez

Síntoma: Varios dispositivos en distintos vdevs muestran aumentos de CKSUM alrededor del mismo momento.
Probable causa raíz: Sistémico: problema del HBA, errores PCIe, inestabilidad de alimentación, RAM/MCE, o un camino compartido del backplane/expander.
Solución: Revisa logs AER/MCE, firmware del HBA, PSU/cableado y rutas compartidas del expander. No reemplaces múltiples discos a lo loco sin acotar el componente compartido.

4) Conteo CKSUM es distinto de cero pero nunca aumenta

Síntoma: El conteo histórico de CKSUM permanece constante durante semanas.
Probable causa raíz: Evento transitorio pasado: pérdida de energía, un movimiento de cable único, un fallo puntual del controlador.
Solución: Limpia contadores después de capturar evidencias; monitorea. Si vuelve, trátalo como activo. Si no, regístralo y sigue adelante.

5) “No known data errors” pero todo el mundo entra en pánico de todos modos

Síntoma: ZFS dice que corrigió errores; no hay archivos listados.
Probable causa raíz: La redundancia funcionó. Pero aún indica problemas subyacentes de confiabilidad.
Solución: Investiga transporte/medio. No lo ignores. Este es tu sistema de alerta temprana haciéndote un favor.

6) Los errores aparecen después de que cambiaste recordsize, compresión u otro “ajuste de rendimiento”

Síntoma: La cronología sugiere que la configuración causó la corrupción.
Probable causa raíz: No es el ajuste de ZFS. Más a menudo aumentó la presión de I/O y expuso un cable/disco marginal que solo falla bajo throughput sostenido.
Solución: Reproduce bajo carga; verifica errores de transporte; repara el componente marginal. Luego decide si el ajuste sigue siendo buena idea para tu carga.

Chiste #2 (corto, relevante): Las fallas de almacenamiento son como las reuniones—si no tomas notas, las repetirás.

Listas de verificación / plan paso a paso

Checklist A — Probar “disco” vs “cable/slot” con downtime mínimo

Capturar evidencias: guarda la salida de zpool status -v y el segmento de logs del kernel alrededor de la última ventana de scrub/resilver.
Revisar contadores SMART del medio: reallocated, pending, offline uncorrectable (HDD) o media errors (NVMe).
Revisar contadores de transporte: SATA UDMA_CRC_Error_Count; errores PHY SAS; reinicios/tiempos de espera en kernel.
Limpiar errores ZFS: solo después de capturar evidencias.
Cambiar el sospechoso más barato primero: reemplazar cable SATA/SAS o mover el disco a otra bahía/puerto.
Reejecutar scrub (o una prueba de lectura controlada): confirma si los errores reaparecen y si los contadores CRC/PHY aumentan.
Si los errores siguen al disco a través de puertos: reemplaza el disco.
Si los errores se quedan con el puerto/bahía: arregla backplane/linea HBA/ruteo de cableado; considera actualizar firmware del HBA y cambiar la ranura PCIe.

Checklist B — Si el pool está degradado (deja de diagnosticar, comienza a estabilizar)

Reduce la carga: pausa backups pesados, replicación y scrubs agresivos.
Confirma el estado de redundancia: mirror vs RAIDZ, número de fallos tolerados.
Exporta evidencias (estado del pool, logs) a un lugar seguro.
Reemplaza el componente más probable con base en evidencias, pero conserva el disco viejo hasta completar el resilver y validar con scrub.
Después del resilver, vuelve a ejecutar scrub. Sin scrub, sin confianza.

Checklist C — “Necesitamos prueba para compras”

Muestra zpool status -v con el miembro exacto y los conteos CKSUM crecientes.
Muestra logs del kernel con reinicios de enlace/tiempos de espera o errores de medio vinculados a ese dispositivo.
Muestra deltas SMART: CRC aumentando (cable) o reallocated/pending aumentando (disco).
Muestra la prueba A/B: después de cambiar cable/puerto, el problema se detuvo (cable) o siguió al disco (disco).

Preguntas frecuentes

1) ¿Los errores de checksum de ZFS son siempre un disco que falla?

No. Son una falla de verificación de integridad. Los discos son culpables comunes, pero cables, backplanes, HBAs, PCIe y RAM pueden producir el mismo síntoma.

2) Si SMART dice “PASSED”, ¿el disco aún puede estar malo?

Sí. El estado general de SMART es una barra baja. Mira atributos específicos (reallocated/pending/uncorrectable) y los resultados de self-test. También correlaciona con logs del kernel.

3) ¿Cuál es la mejor señal única de un cable SATA malo?

Que UDMA_CRC_Error_Count aumente. Uno o dos CRC históricos pueden ocurrir; un contador que sigue subiendo bajo carga es un conector humeante.

4) ZFS reparó los errores. ¿Puedo ignorarlo?

Puedes, pero estás gastando redundancia como si fuera gratis. Hoy es una discrepancia corregible; mañana es un segundo fallo durante un resilver. Investiga y arregla la causa subyacente.

5) ¿Debo ejecutar `zpool clear` de inmediato?

No. Captura evidencias primero. Limpiar temprano destruye la línea de tiempo y dificulta probar si la solución funcionó.

6) ¿Por qué los errores aparecen durante scrub pero no durante la actividad normal de VM?

El scrub fuerza lecturas de superficie completa y la verificación de checksums. Es I/O sostenido y cobertura amplia, lo que expone transporte marginal y medios débiles que los patrones normales de datos calientes quizá nunca toquen.

7) Si cambio el disco, ¿qué debo observar durante el resilver?

Observa nuevos errores de lectura/escritura/checksum en cualquier miembro, y revisa los logs del kernel por reinicios. El resilver es una prueba de estrés para toda la cadena: disco, cable, HBA, expander, alimentación.

8) ¿Los problemas de RAM pueden parecer errores de checksum de disco?

Sí. La RAM defectuosa puede corromper datos en memoria antes de escribirlos o después de leerlos. ECC reduce la probabilidad y aumenta la observabilidad vía logs EDAC/MCE.

9) ¿La compresión o el recordsize causan errores de checksum?

No directamente. Esos ajustes cambian patrones de I/O y carga de CPU, lo que puede desencadenar rutas hardware marginales. Arregla la marginalidad; no culpes a la compresión porque fue lo último que tocaste.

10) ¿Qué pasa si el pool es RAIDZ y ZFS apunta a un disco con CKSUM?

Trátalo de forma similar: primero revisa transporte/medio para ese disco. Pero recuerda que el resilver/scrub de RAIDZ puede estresar todo el vdev; observa de cerca a los otros miembros durante el diagnóstico.

Conclusión: próximos pasos que puedes hacer hoy

Los errores de checksum no son “un problema de ZFS.” Son ZFS detectando el problema de otra parte antes que tus aplicaciones. Tu misión es convertir esa advertencia en un diagnóstico defendible.

Haz esto, en este orden:

Captura zpool status -v y la ventana relevante de logs del kernel.
Revisa indicadores SMART/NVMe de medio y contadores de transporte (CRC/PHY/reinicios de enlace).
Limpa contadores, luego reproduce con un scrub o una lectura controlada.
Cambia cable/slot/puerto primero cuando la evidencia señale transporte (CRC/PHY, reinicios con estadísticas de medio limpias).
Reemplaza el disco cuando la evidencia de medio apunte al disco (test SMART largo fallido, reallocated/pending/uncorrectable creciendo, errores siguen al disco).
Después de cualquier arreglo, ejecuta scrub de nuevo. Si no scrubbeaste, no verificaste.

Si sigues esa disciplina, dejarás de discutir por conjeturas y empezarás a entrar a la sala de repuestos con pruebas. A los ingenieros de almacenamiento les encanta la prueba. Es lo único que sobrevive a la siguiente revisión del incidente.