Advertencias SMART en Proxmox: qué atributos realmente predicen fallos

Cómo funciona SMART en realidad (y cómo lo consume Proxmox)

SMART es telemetría específica del vendedor envuelta en un contenedor con forma de estándar. El firmware del disco decide qué contar, cuándo incrementar y cómo mapear los valores “normalizados”. No estás leyendo física objetiva. Estás leyendo lo que el disco está dispuesto a admitir.

SMART proporciona tres tipos de señales que importan operativamente:

• Indicadores de fallo (estado general SMART “PASSED/FAILED”, NVMe “critical_warning”). Son instrumentos contundentes. Algunos discos fallan sin cambiarlos. Algunos los activan tarde.
• Contadores de degradación de medios (sectores realojados, sectores pendientes, no corregibles, errores de medios NVMe). Estos se correlacionan con fallos de superficie o NAND, y predicen el futuro mejor que la mayoría.
• Contadores de transporte y entorno (errores CRC, historial de temperatura, apagados inseguros). A menudo se refieren a cables, backplanes, alimentación y comportamiento.

Proxmox generalmente obtiene datos SMART vía smartmontools (smartctl/smartd) para dispositivos SATA/SAS y mediante los registros NVMe para NVMe. En la interfaz verás a menudo un “Estado” resumido más un puñado de atributos. Los resúmenes son para humanos. Los incidentes son para datos en bruto.

Si solo recuerdas una cosa: SMART es una herramienta de tendencias, no una foto única. Un número no nulo aislado puede ser inofensivo si nunca cambia. Un número pequeño que sube es una sirena.

Una cita para tener cerca del cuaderno de on-call: La esperanza no es una estrategia. — General Gordon R. Sullivan. No es específica de almacenamiento, pero se aplica dolorosamente a decisiones de discos “probablemente está bien”.

Chiste #1: SMART es como el informe de lesiones de un niño pequeño: hace mucho ruido por las cosas equivocadas y se queda callado sobre las realmente aterradoras.

Hechos interesantes y breve historia que cambian cómo lees SMART

• SMART precede a los SSD modernos. Se popularizó en los años 90 para discos giratorios, y muchos atributos aún arrastran supuestos de la era HDD.
• Los valores “normalizados” son ficción del vendedor. Los campos “VALUE/WORST/THRESH” están escalados y definidos por el vendedor; el contador raw suele ser más accionable.
• SMART temprano fue principalmente sobre “fallo predictivo”. La promesa original era avisar antes del fallo. En la práctica, muchos fallos son abruptos (electrónica, firmware, eventos de alimentación).
• Estudios a escala tipo Backblaze popularizaron algunos atributos. Los datos de flotas grandes hicieron famosos los sectores reallocados y pendientes para HDDs, pero la relación no es idéntica entre modelos.
• SMART para SSD es menos estandarizado de lo que se cree. Indicadores de desgaste (porcentaje usado, desgaste de NAND) son útiles, pero los registros específicos del vendedor siguen importando.
• Las pruebas SMART son “offline” pero no inofensivas. Las pruebas largas pueden estresar discos marginales y degradar el rendimiento; eso es una ventaja cuando validas una decisión de reemplazo.
• Los errores de transporte a menudo no tienen nada que ver con el disco. Un aumento de CRC grita “cable/backplane” más que “fallo del medio”.
• ZFS y Ceph ya hacen su propia verificación de la verdad. Los errores de checksum de ZFS y los errores de Ceph “bluestore” pueden revelar corrupción incluso cuando SMART parece tranquilo.
• El firmware del disco puede remapear sectores en silencio. La reubicación a veces es proactiva; el disco puede cambiar sectores débiles antes de que veas un error no corregible.

Los atributos SMART que realmente predicen fallos

“Predecir” hace mucho trabajo aquí. Ningún atributo es una profecía. Pero algunos se correlacionan consistentemente con discos que empeoran, rápidamente. Estos merecen un ticket de incidente, no un encogimiento de hombros.

Para HDD SATA: los tres grandes que más importan

1) Reallocated Sector Count (ID 5)

Este es el métrico canónico de “el medio se está degradando”. Un sector realojado es un sector que el disco no pudo leer/escribir de forma fiable y cambió por un sector de repuesto.

Cómo tratarlo en producción:

• Cero es la base. Un valor no nulo significa que el disco ya consumió repuestos.
• Un valor no nulo estable puede ser aceptable si no aumenta durante semanas y los scrubs no muestran errores de lectura.
• Las realocaciones crecientes son un disparador de reemplazo. No por el número en sí, sino porque el disco te está diciendo que sigue perdiendo la batalla.

2) Current Pending Sector (ID 197)

Los sectores pendientes son peores que las realocaciones a corto plazo. Son sectores que el disco tiene problemas para leer y aún no ha remapeado: a menudo espera una escritura exitosa para confirmar si puede remapear.

Significado operativo: tienes datos que el disco no puede leer de forma consistente. Eso genera timeouts, lecturas lentas y, eventualmente, errores no corregibles.

Regla de decisión: Pending > 0 en un miembro ZFS/RAID merece seguimiento inmediato: ejecuta una prueba larga y revisa errores en ZFS/Ceph. Si el pending persiste o crece, programa el reemplazo.

3) Uncorrectable Sector Count / Offline Uncorrectable (ID 198) y Reported Uncorrectable Errors (ID 187)

Si el disco admite que no pudo corregir lecturas durante un escaneo offline (198) o durante operaciones normales (187), trátalo como “riesgo de integridad de datos presente”.

En RAIDZ/espejos puedes sobrevivir. En sistemas de un solo disco quizá no. En cualquier caso, el disco ya no es “aburrido”, y “aburrido” es el estado deseado.

Para SSD SATA: los atributos que importan

1) Indicador de desgaste de medios / Porcentaje usado / Conteo de nivelado de desgaste

Diferentes vendedores lo nombran distinto. Quieres un indicador directo del desgaste de la NAND. Cuando esto se acerca al final de vida, esperas:

• escrituras más lentas
• mayor sobrecarga de corrección de errores
• modo solo lectura eventual en algunos modelos

Regla de decisión: Cuando el desgaste indica que estás dentro del último tramo de la vida útil nominal, programa el reemplazo según tu calendario, no según el disco.

2) Sectores realojados / eventos de realocación (varía)

Los SSD remapean diferente que los HDD, pero una métrica de realocación creciente suele correlacionar con NAND o inestabilidad del controlador. Si sube, trátalo como las realocaciones de HDD: tendencia y plan de reemplazo.

3) Errores no corregibles

Los no corregibles en SSD son una mala señal. Son menos comunes que en HDD moribundos, y cuando ocurren suelen significar problemas de controlador/NAND que no mejoran.

Para NVMe: los pocos campos que importan más que una docena de atributos SATA

1) Critical Warning

Es un bitmask. Cualquier valor no nulo merece atención. Puede indicar poca capacidad de repuestos, problemas de temperatura o modo de solo lectura por medios.

2) Percentage Used

Es exactamente lo que suena: desgaste relativo a la vida nominal del fabricante. No es perfecto, pero mucho mejor que adivinar por horas de encendido.

3) Media and Data Integrity Errors

Suele exponerse como “Media and Data Integrity Errors” en SMART NVMe. Un valor no nulo y creciente significa que el dispositivo falla al entregar datos correctos sin recuperación de errores.

4) Error Information Log Entries

Es el contador de “algo sigue fallando”. Puede incrementarse por errores recuperables también, así que correlaciónalo con picos de latencia, errores I/O en logs y errores de checksum de ZFS.

La tendencia vence al umbral

La mayoría de los valores “THRESH” de SMART están establecidos tan bajos que cuando se activan ya llevas una mala semana. Tus umbrales operativos deberían ser más conservadores:

• Cualquier aumento en pending o no corregibles recibe investigación inmediata.
• Realocaciones que aumentan mes a mes disparan reemplazo planificado.
• Errores de medios NVMe en aumento disparan planificación de reemplazo; aumento rápido implica reemplazo urgente.
• Errores de transporte en aumento disparan trabajo en cableado/backplane/energía antes de culpar al disco.

Los atributos ruidosos que te hacen perder el tiempo

Algunos atributos SMART son infames por inducir a error porque los vendedores codifican múltiples subcontadores en un valor raw, o porque el atributo depende de la carga. A los paneles les encantan porque se mueven. A los ingenieros les molestan porque no responden a la pregunta “¿caerá este disco?”

Raw Read Error Rate (ID 1) y Seek Error Rate (ID 7)

En muchos modelos Seagate esos números raw parecen aterradores y siguen subiendo incluso en discos sanos. Ese no es tu incidente. Tende el valor normalizado si es necesario, pero no reemplaces un disco solo por una tasa de errores de lectura raw que asusta.

Hardware ECC Recovered (ID 195)

Altos conteos de recuperación ECC a menudo significan “la corrección de errores está haciendo su trabajo”. No es automáticamente malo. Se vuelve interesante solo si coincide con no corregibles, timeouts o errores de checksum de ZFS.

Spin Retry Count (ID 10) y Start/Stop Count (ID 4)

Estos dependen de la carga y la gestión de energía. Los conteos de start/stop se abusan especialmente por aparcamiento agresivo de cabezas. Altos conteos no predicen necesariamente fallo inminente; predicen que configuraste la gestión de energía como un portátil.

Power-On Hours (ID 9)

La edad importa, pero no determina todo. He reemplazado discos nuevos que llegaron dañados y he mantenido vivos discos empresariales de 7 años tratándolos con cuidado y vigilando los contadores adecuados.

Temperatura (ID 194/190)

La temperatura es un factor de riesgo, no un predictor de fallo por sí mismo. Las temperaturas persistentemente altas aceleran el desgaste y pueden desencadenar throttling o tasas de error, pero un pico durante un rebuild no es sentencia de muerte.

Dónde Proxmox muestra SMART y qué te está diciendo realmente

En Proxmox VE, normalmente ves SMART en nodo → Disks → SMART. También puede mostrar estado en la vista de almacenamiento según tu configuración. La UI es conveniente para un vistazo, pero no es donde haces análisis de causa raíz.

Usa la UI para detectar “algo cambió”. Luego baja a la shell y extrae:

• atributos SMART completos (no solo los pocos que la UI renderiza)
• registro de errores SMART
• historial de auto-pruebas
• logs del kernel mostrando timeouts/resets
• estado de scrub y checksum de ZFS/Ceph

También: Proxmox suele correr en hosts con HBAs, backplanes y a veces controladoras RAID. El passthrough SMART puede ser incompleto. Si SMART falta campos o siempre devuelve “UNKNOWN”, no es que el disco sea misterioso; es que tu ruta de almacenamiento es opaca.

Tareas prácticas: comandos, qué significa la salida y la decisión que tomas

Estas son las tareas que realmente ejecuto cuando aparecen advertencias SMART en Proxmox. Cada una incluye el “¿y qué?” porque recoger números sin decisiones es solo acumulación competitiva de logs.

Task 1: Confirma la ruta del dispositivo y el modelo (evita culpar al disco equivocado)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINT
NAME   SIZE MODEL               SERIAL            TYPE MOUNTPOINT
sda   3.6T  ST4000NM0035-1V4    ZC1ABC12          disk
sdb   3.6T  ST4000NM0035-1V4    ZC1ABD34          disk
nvme0n1 1.8T INTEL SSDPE2KX020T8 PHBT1234001      disk

Significado: Mapea nombres Linux a discos físicos (modelo + serial). Los nombres de dispositivo en la UI de Proxmox pueden cambiar tras reinicios o cambios de HBA.

Decisión: Si no puedes asociar la advertencia a un número de serie, detente. Construye ese mapeo primero o extraerás el disco equivocado y aprenderás humildad a la mala.

Task 2: Extrae el resumen completo de salud SMART para un disco SATA/SAS

cr0x@server:~$ sudo smartctl -a /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-3-pve] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     ST4000NM0035-1V4107
Serial Number:    ZC1ABC12
LU WWN Device Id: 5 000c50 0a1b2c3d4
Firmware Version: SN04
User Capacity:    4,000,787,030,016 bytes [4.00 TB]
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
...
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Significado: “PASSED” no anula pending/uncorrectables. Aquí tenemos realocaciones, sectores pendientes y no corregibles offline: problemas clásicos de medio.

Decisión: Si 197 o 198 es no nulo, escala. Ejecuta una prueba larga, revisa el estado de ZFS/Ceph y planifica reemplazo si los números persisten o aumentan.

Task 3: Extrae salud NVMe y el bit de critical warning

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-3-pve] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       INTEL SSDPE2KX020T8
Serial Number:                      PHBT1234001
Firmware Version:                   VDV10131
PCI Vendor/Subsystem ID:            0x8086
IEEE OUI Identifier:                0x5cd2e4
Total NVM Capacity:                 2,000,398,934,016 [2.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       1.4
Number of Namespaces:               1

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Critical Warning:                   0x00
Temperature:                        44 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    63%
Media and Data Integrity Errors:    0
Error Information Log Entries:      18

Significado: Percentage Used está subiendo (63%), pero no es fin de vida por sí solo. “Error Information Log Entries” es no nulo; correlaciónalo con logs y síntomas de rendimiento.

Decisión: Si Critical Warning es no nulo o Media and Data Integrity Errors sube, planifica reemplazo. Si solo suben entradas de log de errores pero no hay errores de integridad, investiga firmware/controlador/timeouts primero.

Task 4: Revisa el registro de errores SMART (la lista de confesiones del disco)

cr0x@server:~$ sudo smartctl -l error /dev/sda
SMART Error Log Version: 1
ATA Error Count: 3
  CR = Command Register [HEX]
  FR = Features Register [HEX]
  SC = Sector Count Register [HEX]
  SN = Sector Number Register [HEX]
  ...
Error 3 occurred at disk power-on lifetime: 4231 hours
  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  ...
  40 -- 51 0008  0000001a2b3c  ...
  Commands leading to the command that caused the error were:
  READ FPDMA QUEUED

Significado: Errores durante lecturas son consistentes con pending/uncorrectables. Si los errores son antiguos y no aumentan, menos urgente.

Decisión: Si el conteo de errores incrementa durante tu ventana de incidente, trátalo como inestabilidad en vivo. Prepárate para reemplazar y resilver/reconstruir.

Task 5: Revisa el historial de auto-pruebas SMART

cr0x@server:~$ sudo smartctl -l selftest /dev/sda
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       10%      4232         0x0000001a2b3c
# 2  Short offline       Completed without error       00%      4200         -

Significado: La prueba larga encontró una falla de lectura en un LBA específico. Eso no es “monitoréalo”. Es “programa el reemplazo”.

Decisión: Reemplaza el disco. Si está en un espejo/RAIDZ/OSD, inicia la recuperación controlada ahora, no después de que falle más.

Task 6: Ejecuta una prueba SMART corta (triage rápido)

cr0x@server:~$ sudo smartctl -t short /dev/sda
Please wait 2 minutes for test to complete.
Test will complete after Tue Dec 26 02:16:04 2025
Use smartctl -l selftest /dev/sda to read test results.

Significado: Las pruebas cortas detectan problemas obvios rápido. No escanean toda la superficie.

Decisión: Si la prueba corta falla, ya no hay debate. Reemplaza. Si pasa pero tienes pending/uncorrectables, ejecuta extendida a continuación.

Task 7: Ejecuta una prueba SMART extendida (escaneo de superficie, la prueba “pruébalo”)

cr0x@server:~$ sudo smartctl -t long /dev/sda
Please wait 411 minutes for test to complete.
Test will complete after Tue Dec 26 09:06:11 2025
Use smartctl -l selftest /dev/sda to read test results.

Significado: Las pruebas extendidas escanean la superficie y tienden a sacar a la luz sectores marginales.

Decisión: Si reporta fallos de lectura, reemplaza. Si completa pero los pending permanecen, no declares victoria hasta verificar que los pending se limpiaron y no aparecen nuevos errores bajo carga.

Task 8: Identifica si los “errores CRC” son cableado/backplane, no disco

cr0x@server:~$ sudo smartctl -A /dev/sda | egrep 'UDMA_CRC_Error_Count|CRC|199'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       47

Significado: Los errores CRC suelen ser corrupción en la capa de enlace entre disco y controlador: cable, conector, expander, backplane, vibración o ruido de alimentación.

Decisión: Si este contador aumenta, resitúa/reemplaza el cable, mueve el disco a otra bahía, revisa el backplane e inspecciona logs del kernel por resets de enlace. No RMAes el disco primero a menos que otros atributos de medio también estén mal.

Task 9: Correlaciona con logs del kernel por timeouts y resets

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i 'ata[0-9]|reset|timeout|I/O error|nvme'
Dec 26 01:41:08 server kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 26 01:41:08 server kernel: ata3.00: failed command: READ FPDMA QUEUED
Dec 26 01:41:09 server kernel: ata3: hard resetting link
Dec 26 01:41:14 server kernel: blk_update_request: I/O error, dev sda, sector 43905102 op 0x0:(READ)

Significado: Resets de enlace más errores I/O: podría ser medio o transporte. Combina esto con SMART 199 y 5/197/198.

Decisión: Si 5/197/198 están limpios pero hay resets de enlace, trata primero como cableado/HBA/backplane. Si 197/198 son no nulos y ves errores I/O, trátalo como fallo de disco en progreso.

Task 10: Salud ZFS: mira qué piensa el sistema de archivos (normalmente tiene razón)

cr0x@server:~$ sudo zpool status -v
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device and run 'zpool clear' or 'zpool replace'.
  scan: scrub repaired 0B in 00:18:11 with 0 errors on Tue Dec 24 03:12:18 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        rpool                       DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            ata-ST4000NM0035_ZC1ABC12  FAULTED     12    0    34  too many errors
            ata-ST4000NM0035_ZC1ABD34  ONLINE      0    0     0

errors: Permanent errors have been detected in the following files:
/rpool/vm-100-disk-0

Significado: ZFS ve errores reales de lectura/checksum y ha marcado el dispositivo como faulted. Esto va más allá de una “advertencia SMART”; es un incidente de integridad.

Decisión: Reemplaza el disco inmediatamente. Luego maneja los errores permanentes: restaura desde replicación/backup los bloques o discos de VM afectados.

Task 11: Scrub ZFS bajo demanda (cuando necesitas la verdad, no consuelo)

cr0x@server:~$ sudo zpool scrub rpool
cr0x@server:~$ sudo zpool status rpool
  pool: rpool
 state: ONLINE
  scan: scrub in progress since Tue Dec 26 02:22:10 2025
        215G scanned at 1.20G/s, 48.1G issued at 273M/s, 2.10T total
        0B repaired, 2.31% done, 02:41:18 to go
config:

        NAME                       STATE     READ WRITE CKSUM
        rpool                      ONLINE       0     0     0
          mirror-0                 ONLINE       0     0     0
            ata-ST4000NM0035_ZC1ABC12  ONLINE       0     0     0
            ata-ST4000NM0035_ZC1ABD34  ONLINE       0     0     0

Significado: Un scrub lee todo y verifica checksums. Si SMART susurra pero ZFS está limpio, puede que tengas indicadores tempranos sin corrupción visible para el usuario aún.

Decisión: Si el scrub reporta errores, actúa de inmediato. Si el scrub está limpio pero SMART muestra pending/uncorrectables, igualmente programa el reemplazo: el scrub puede no tocar sectores no referenciados actualmente.

Task 12: Chequeo rápido de Ceph (si tu clúster Proxmox lo usa)

cr0x@server:~$ sudo ceph -s
  cluster:
    id:     8f3c2d3e-1b2a-4c5d-9e10-1a2b3c4d5e6f
    health: HEALTH_WARN
            1 osds down
            2 slow ops, oldest one blocked for 31 sec

  services:
    mon: 3 daemons, quorum a,b,c (age 4h)
    mgr: a(active, since 2d)
    osd: 12 osds: 11 up (since 3m), 12 in (since 7d)

  data:
    pools:   4 pools, 256 pgs
    objects: 1.2M objects, 4.3 TiB
    usage:   13 TiB used, 24 TiB / 37 TiB avail
    pgs:     254 active+clean, 2 active+degraded

Significado: Ceph te está diciendo que un disco/OSD está caído y que las operaciones están lentas. SMART puede estar involucrado, pero la salud de Ceph es la señal prioritaria.

Decisión: Identifica el host y disco del OSD caído, revisa SMART/NVMe logs y reemplaza/restaura el OSD. No te quedes mirando SMART mientras Ceph sangra.

Task 13: Mapea un OSD Ceph a un disco físico (deja de adivinar)

cr0x@server:~$ sudo ceph-volume lvm list
====== osd.4 ======
  [block]       /dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC1ABC12
  [block.db]    /dev/nvme0n1p2
  devices       /dev/sda

====== osd.5 ======
  [block]       /dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC1ABD34
  [block.db]    /dev/nvme0n1p3
  devices       /dev/sdb

Significado: Ahora puedes ligar “osd.4” a un serial y bahía específicos.

Decisión: Reemplaza el disco correcto, no su vecino inocente.

Task 14: Busca errores PCIe SATA/NVMe (un “problema de disco” que es realmente de la plataforma)

cr0x@server:~$ sudo journalctl -k --since "24 hours ago" | egrep -i 'pcie|aer|nvme.*reset|controller is down'
Dec 25 18:12:44 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:02:00.0
Dec 25 18:12:44 server kernel: nvme nvme0: controller reset
Dec 25 18:12:46 server kernel: nvme nvme0: I/O 37 QID 5 timeout, aborting

Significado: Errores AER de PCIe corregidos y resets de controlador suelen ser por gestión de energía, bugs de firmware, risers o ranuras marginales—no por desgaste de la NAND.

Decisión: Antes de RMAar el NVMe, revisa BIOS/firmware, desactiva ASPM agresivo si hace falta, resitúa y valida térmicas. Reemplaza el disco si aparecen errores de medios o los resets persisten después de arreglos de plataforma.

Task 15: Trazar atributos SMART en el tiempo (porque “¿está empeorando?” es la pregunta real)

cr0x@server:~$ sudo smartctl -A /dev/sda | awk 'NR==1 || $1 ~ /5|187|197|198|199/ {print}'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       -       12
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       2
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Significado: Este es tu conjunto de “principales ofensores” para HDD SATA. Captúralo diario o semanalmente.

Decisión: Cualquier tendencia al alza en 197/198/187 es plan de reemplazo. 199 en aumento es plan de cableado/backplane.

Task 16: Valida identidad del disco por-id (nombres estables para automatización y reemplazo)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ZC1ABC12|nvme-INTEL'
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-ST4000NM0035-1V4107_ZC1ABC12 -> ../../sda
lrwxrwxrwx 1 root root 13 Dec 26 01:10 nvme-INTEL_SSDPE2KX020T8_PHBT1234001 -> ../../nvme0n1

Significado: Usa estos identificadores estables en rutas vdev by-id de ZFS y en tus runbooks.

Decisión: Si tu pool usa nombres /dev/sdX, programa una limpieza/migración a nombres by-id antes de tener un incidente de reemplazo.

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

Esta es la rutina “tienes cinco minutos antes de la reunión y 30 segundos antes de que el pager escale”. El objetivo no es la verdad perfecta; es la clasificación rápida: fallo de medio vs ruido de transporte vs plataforma vs sistema de archivos.

Primero: determina si esto es un incidente de integridad

• ZFS: zpool status -v. Si ves errores CKSUM, dispositivos faulted o errores permanentes, trátalo como riesgo de integridad ahora.
• Ceph: ceph -s. Si hay OSDs caídos, operaciones lentas o PGs degradados: trátalo como inestabilidad del servicio de almacenamiento ahora.
• Logs del kernel: busca errores I/O y resets en la última hora.

Segundo: separa degradación de medio del ruido de transporte

• Extrae salud SMART/NVMe (smartctl -a).
• Indicadores de medio: pending (197), no corregibles (198/187), realocados (5), errores de medios NVMe.
• Indicadores de transporte: CRC (199), resets de enlace, resets SAS phy, AER de PCIe, resets de controlador NVMe sin errores de medio.

Tercero: fuerza el asunto con una prueba controlada

• Ejecuta prueba SMART corta y luego larga si hace falta.
• Ejecuta scrub de ZFS o deep-scrub de Ceph si el clúster lo puede soportar.
• Vigila los contadores otra vez después de la prueba. Si pending se limpia y no aparecen nuevos errores, puede que hayas esquivado una bala. Si los contadores suben, reemplaza.

Chiste #2: Si tu “diagnóstico rápido” acaba en “vamos a reiniciar y ver”, felicidades—estás practicando astrología de almacenamiento.

Tres micro-historias corporativas (cómo los equipos se equivocan y aciertan)

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

Una empresa mediana ejecutaba un clúster Proxmox con espejos ZFS. El on-call vio un SMART “PASSED” y una advertencia de Proxmox sobre un par de sectores realocados. Asumieron que estaba bien porque el pool seguía ONLINE y las VMs corrían.

El detalle sutil: el disco también tenía un pequeño pero no nulo Current_Pending_Sector. No se enfatizó en la vista del panel. Nadie lo trazó. Nadie ejecutó una prueba larga. La vida siguió.

Dos semanas después, un scrub rutinario de ZFS lo alcanzó. Tocó uno de los sectores pendientes durante una lectura, el disco hizo timeout y el HBA reseteó el enlace. ZFS siguió intentando. La latencia se disparó. La I/O de VM se congeló. El clúster no “perdió datos”, pero perdió algo más precioso en el momento: tiempo.

Reemplazaron el disco después de que finalmente cayó. El resilver tomó más tiempo del esperado porque el miembro espejo sobreviviente ahora hacía doble trabajo en producción. El postmortem fue directo: el error no fue ignorar las realocaciones; fue tratar los sectores pendientes como “otro número SMART”.

La acción correctiva fue aburrida: snapshots diarios SMART de 5/197/198 y un ticket automático si 197 es no nulo o aumenta. No detuvieron fallos. Detuvieron sorpresas.

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

Otro equipo quería alertas más silenciosas. Su UI de Proxmox mostraba frecuentes advertencias SMART de “temperatura” y “UDMA CRC error count” en varios nodos. La gente empezó a ignorar notificaciones y, naturalmente, a perder las reales.

Así que “optimizaron” las alertas: subieron umbrales y suprimieron alertas CRC porque “siempre es el backplane”. También suprimieron advertencias de temperatura porque “esos discos siempre se calientan durante rebuilds”. El panel se volvió más tranquilo. Todos se sintieron mejor.

Meses después, tuvieron pausas intermitentes de VMs en un host. Nada obvio en SMART. Sin sectores realocados, sin pending. Pero los logs del kernel mostraban ráfagas de resets de enlace e incrementos de CRC durante carga pico. Resultó que un puerto de expander SAS estaba marginal. Los errores no eran constantes; venían en tormentas.

Como las alertas CRC estaban suprimidas, el problema de hardware persistió. El expander se degradó más y empezó a causar timeouts múltiples de discos durante scrubs. Fue entonces cuando ZFS empezó a mostrar errores de checksum. El sistema no falló por un disco; falló porque la alerta “ruidosa” era en realidad su sistema de aviso temprano para un componente compartido.

La solución no fue “volver a activar alertas y sufrir”. Fue mejor: alertar sobre la tasa de CRC (cambio en el tiempo), no el valor raw, y correlacionarlo con puerto/bahía específico mediante inventario. Reemplazaron el expander, no un montón de discos inocentes.

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

Una organización financiera ejecutaba Proxmox con Ceph. Su política era monótona: cada disco tiene una etiqueta con serial, bahía y ID OSD; cada semana capturan resúmenes SMART/NVMe en una pequeña tienda de series temporales; cada mes ejecutan pruebas largas programadas escalonadas por nodo.

Una tarde, Ceph pasó a HEALTH_WARN por algunas operaciones lentas. Nada estaba caído. El on-call revisó el panel de tendencias y vio que un NVMe tenía “Media and Data Integrity Errors” que pasó de 0 a 1 en el último día. Solo uno. No emocionante. Pero era nuevo.

Dreneron el host, marcaron el OSD fuera y reemplazaron el NVMe en horario laboral. Las diagnósticas del vendedor confirmaron después una falla temprana de medios. Si hubieran esperado a que “Critical Warning” se activara, habrían sufrido la falla durante una ventana de mantenimiento ya estresada.

La práctica que los salvó no fue una herramienta ingeniosa. Fue el hábito de tratar errores de integridad nuevos como accionables, aunque sean pequeños, y hacer reemplazos en su propio horario.

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

1) “SMART PASSED pero Proxmox muestra advertencias”

Síntoma: Estado general SMART es PASSED; Proxmox aún marca salud del disco.

Causa raíz: El estado general es un umbral burdo del vendedor; contadores significativos (pending/uncorrectable) pueden ser no nulos mientras el general sigue PASSED.

Solución: Ignora la manta de consuelo “PASSED”. Revisa los raw 5/187/197/198 (SATA) o errores de medios/critical warning de NVMe. Trázalos.

2) “UDMA CRC Error Count sigue aumentando; reemplacé disco y persiste el problema”

Síntoma: El atributo SMART 199 incrementa; aparecen errores I/O; reemplazar el disco no lo detiene.

Causa raíz: Problema de transporte: cable SATA, conector de backplane, expander, puerto HBA o inestabilidad de alimentación.

Solución: Resitúa/reemplaza cables, cambia bahías, inspecciona backplane, actualiza firmware del HBA, revisa alimentación. Reemplaza el componente compartido cuando los errores siguen a la bahía/puerto, no al disco.

3) “Errores de checksum ZFS pero SMART parece limpio”

Síntoma: ZFS reporta errores CKSUM; atributos SMART no muestran realocaciones/pending.

Causa raíz: Corrupción de datos en tránsito (cableado/HBA), RAM inestable (menos común pero catastrófico), o bugs de firmware/controlador. SMART mide el disco, no todo el camino.

Solución: Revisa logs del kernel por resets, CRC, errores PCIe. Valida salud de RAM ECC. Cambia HBA/cables. Scrubea de nuevo. No culpes a SMART por ser la herramienta equivocada.

4) “Sectores pending aparecieron tras un evento de energía”

Síntoma: 197 > 0 después de un apagado brusco o pérdida de energía.

Causa raíz: Escrituras incompletas o sectores marginales expuestos por un apagado repentino; a veces se limpian después de reescribir los sectores afectados.

Solución: Ejecuta una prueba larga SMART y luego verifica si los pending se limpian. Si persisten o aparecen no corregibles, reemplaza. Además, arregla la alimentación: UPS, PSUs redundantes, cierres limpios.

5) “NVMe se resetea bajo carga; SMART parece bien”

Síntoma: Resets de controlador NVMe y timeouts I/O; sin errores de medios.

Causa raíz: Problemas de plataforma/PCIe: térmicas, firmware, ASPM, risers, ranura marginal, alimentación.

Solución: Revisa logs AER, térmicas, actualizaciones de firmware. Considera desactivar gestión agresiva de energía. Si los resets persisten, cambia el dispositivo a otra ranura o reemplaza el componente de plataforma.

6) “La prueba larga SMART ralentiza las VMs, así que nunca la ejecutamos”

Síntoma: Evitas pruebas largas porque impactan el rendimiento.

Causa raíz: No hay ventanas de mantenimiento; miedo al impacto; falta de programación escalonada.

Solución: Escalona las pruebas por nodo y por disco en ventanas de baja carga. Si no soportas una prueba larga SMART, tampoco soportas un resilver durante pico.

7) “Alertamos por cada valor raw SMART no nulo”

Síntoma: Alertas constantes; todos las ignoran.

Causa raíz: Alertar sobre atributos ruidosos sin lógica de tasa/tendencia.

Solución: Alerta sobre cambios en atributos de alta señal (pending, no corregibles, realocaciones, errores de medios NVMe) y sobre la tasa de cambio para CRC/temperatura, no sobre valores absolutos.

Listas de verificación / plan paso a paso

Checklist A: Cuando Proxmox lanza una advertencia SMART

1. Identifica el disco por número de serie (lsblk, /dev/disk/by-id).
2. Extrae datos SMART/NVMe completos (smartctl -a).
3. Extrae los atributos de alta señal:
   • SATA: 5, 187, 197, 198, 199
   • NVMe: Critical Warning, Percentage Used, Media/Data Integrity Errors
4. Revisa el registro de errores y el historial de auto-pruebas (smartctl -l error, -l selftest).
5. Correlaciona con logs del kernel para la misma ventana (journalctl -k).
6. Revisa salud ZFS/Ceph (zpool status -v o ceph -s).
7. Toma una decisión:
   • Contadores de medio aumentando → reemplazar disco (planificado o urgente según la tasa).
   • CRC/resets sin contadores de medio → arreglar transporte/plataforma primero.
   • Errores permanentes ZFS → tratar como incidente de integridad y recuperar bloques/discos de VM.

Checklist B: Reglas de decisión de reemplazo que realmente uso

• Reemplazar ahora si:
  • Cualquier prueba larga SMART muestra fallo de lectura
  • ZFS marca el dispositivo como faulted o muestra errores permanentes
  • 197 (pending) persiste tras prueba larga o aumenta
  • 198/187 aumentan (no corregibles) bajo carga normal
  • NVMe Critical Warning es no nulo o errores de medios aumentan
• Planificar reemplazo si:
  • Sectores realocados (5) son no nulos y aumentan lentamente
  • SSD Percentage Used es alto y te acercas a políticas de ciclo de vida
• No reemplazar todavía si:
  • Solo CRC/errors de enlace aumentan y contadores de medio están limpios → arregla cableado/backplane/HBA
  • Solo atributos ruidosos asustan (raw read error rate) sin corroboración

Checklist C: Construir una monitorización SMART sensata en Proxmox

1. Asegura que smartmontools esté instalado y smartd corriendo.
2. Usa IDs de dispositivo estables para el seguimiento (symlinks by-id).
3. Recopila un subconjunto pequeño de atributos y trázalos (snapshots diarios son suficientes).
4. Alerta sobre cambio, no por existencia:
   • delta(197) > 0 → page
   • delta(198) > 0 → page
   • delta(5) > 0 → ticket
   • delta(199) > 0 → ticket; page si es rápido y correlaciona con errores I/O
5. Programa pruebas SMART largas escalonadas entre discos y nodos.
6. Verifica que los scrubs de ZFS o Ceph se ejecuten y se revisen.

Preguntas frecuentes

1) Si SMART dice PASSED, ¿puedo ignorar las advertencias de Proxmox?

No. “PASSED” a menudo significa “no ha cruzado el umbral catastrófico del vendedor”. Sectores pending y no corregibles pueden existir mientras la salud general aún pasa.

2) ¿Qué único atributo de HDD SMART es más predictivo?

Current_Pending_Sector (197) es el que cambia las decisiones más rápido. Representa sectores ilegibles ahora mismo, no remapeos históricos.

3) ¿Los sectores realocados siempre son motivo de reemplazo?

No siempre de forma inmediata. Un conteo pequeño y estable de realocados puede durar mucho. Un conteo creciente es tu plan de reemplazo escribiéndose solo.

4) ¿Qué significa en la práctica UDMA CRC error count?

Corrupción de datos en el enlace entre disco y controlador. Piensa en cable, backplane, expander, puerto HBA o ruido de alimentación. Frecuentemente no es culpa del disco.

5) ¿Por qué ZFS muestra errores checksum cuando SMART parece estar bien?

Porque SMART mide la vista interna del disco. ZFS valida checksums de extremo a extremo y puede detectar corrupción causada por RAM, HBA, cables o bugs de firmware.

6) ¿Debo ejecutar pruebas SMART largas en hosts de producción?

Sí, pero escalonadas. Una prueba larga es más barata que un rebuild sorpresa en pico. Si el impacto es inaceptable, eso es un problema de capacidad/planificación, no de SMART.

7) Para NVMe, ¿sobre qué debo alertar?

Alerta sobre Critical Warning no nulo, aumento de Media and Data Integrity Errors y saltos repentinos de resets/timeouts en logs del kernel. Percentage Used es para planificación de ciclo de vida.

8) Proxmox no puede leer SMART detrás de mi controladora RAID. ¿Ahora qué?

Usa las herramientas de la controladora para salud de discos, o cambia a una controladora HBA/IT donde el SO pueda ver discos directamente. Si no puedes observar la salud por disco, estás operando a ciegas—y a escala, eso tiene consecuencias.

9) ¿Cómo decido entre “reemplazar disco” y “arreglar cableado”?

Si 5/197/198/187 (o errores de medios NVMe) aumentan, es el disco. Si solo CRC/resets de enlace aumentan y los contadores de medio están limpios, es la ruta.

10) ¿Temperatura alta significa fallo inminente?

No necesariamente inminente, pero acorta la vida y puede inducir errores y throttling. Trata la temperatura persistentemente alta como un bug de fiabilidad: flujo de aire, curvas de ventilador, polvo y diseño del chasis.

Conclusión: qué hacer a continuación, de forma práctica

Cuando Proxmox te muestra una advertencia SMART, no te hipnotices con el “PASSED” general. Ve directo a los pocos contadores que realmente predicen problemas: sectores pending, no corregibles, realocados, errores de medios NVMe, y los contadores de transporte que implican tu cableado y backplane.

Próximos pasos que devuelven valor de inmediato:

1. Elige un conjunto pequeño y directo de alertas: 5/187/197/198/199 para SATA; critical warning/media errors/percentage used para NVMe.
2. Trazar esos valores. Alertas sobre cambio, no por existencia.
3. Haz de ZFS/Ceph el juez de integridad y de SMART el sistema de aviso temprano.
4. Escribe tus reglas de decisión de reemplazo y síguelas. Lo importante es la consistencia, no el heroísmo.

Tu stack de almacenamiento no necesita que seas optimista. Necesita que seas aburrido, sistemático y un poco desconfiado de los paneles.