Recibes la alerta a las 02:17. “SMART Usage Attribute: 0xC5 Current_Pending_Sector changed from 0 to 1.”
La miras como si fuera un horóscopo. ¿Está muriendo la unidad o simplemente tuvo un mal día?
En Debian 13, las advertencias SMART son o bien tempranas, ruidosas y confusas —o bien tardías, silenciosas y costosas.
El truco es saber qué atributos realmente son predictivos, cuáles son matemáticas de proveedor sin sentido y cuál
debe ser el siguiente movimiento operativo cuando un número se altera.
SMART en palabras sencillas: qué puede y qué no puede decirte
SMART es la unidad diciéndote lo que ella piensa sobre sí misma. Eso es útil y sospechoso a la vez, como un currículum.
Expone contadores y umbrales que son en parte estandarizados, en parte específicos del proveedor y siempre moldeados
por decisiones de firmware que no puedes auditar.
Dos verdades importantes te mantienen cuerdo:
- SMART confirma fallos mejor de lo que los predice —pero unos pocos atributos se correlacionan fuertemente con fallos reales.
- SMART no sustituye la redundancia, las copias de seguridad ni los scrubs. Si no tienes eso, SMART es una alarma de humo en una casa llena de gasolina.
En Debian 13, las herramientas están maduras: smartmontools (smartctl + smartd), señales en el registro del kernel,
páginas de registro NVMe y retroalimentación de la pila de almacenamiento desde mdadm, LVM, ZFS, btrfs y tu hipervisor.
La ventaja es combinar esas señales en una decisión: ignorar, observar, probar o reemplazar.
Hechos y contexto que hacen que SMART tenga sentido
Algunos puntos de contexto que cambian cómo lees las alertas:
- SMART empezó como algo específico del proveedor en los años 90; los atributos “estándar” aún se interpretan de forma distinta entre fabricantes.
- Los valores normalizados (VALUE/WORST/THRESH) son una escala del proveedor, no física. RAW está más cerca de la realidad, pero aún puede estar codificado.
- Los umbrales SMART a menudo se ajustan para evitar RMAs, no para proteger tus datos. “PASSED” no significa “saludable”.
- La reubicación existe porque los discos se envían con sectores de repuesto. Los discos modernos remapean constantemente: algo de remapeo es esperado, pero las tendencias importan.
- Los SSD introdujeron el “desgaste” como modo de fallo relevante. SMART para SSDs incluye indicadores de desgaste, pero no todos son comparables entre modelos.
- NVMe definió registros de salud más consistentes que SMART SATA/ATA, pero los proveedores siguen diferenciándose en detalles y umbrales.
- Las auto-pruebas no son lo mismo que los scrubs. Las pruebas SMART son internas al dispositivo; los scrubs son validación a nivel de sistema de archivos/RAID de tus datos reales.
- SMART no puede ver directamente problemas de cableado. Los errores UDMA CRC son una pista, pero muchos problemas de enlace aparecen primero en los registros del kernel.
- Algunos fallos son “muerte súbita”. Bugs de firmware, fallos de controlador o eventos de energía pueden inutilizar una unidad con historial SMART limpio.
Los atributos que realmente predicen fallos (y por qué)
Si solo recuerdas una cosa: los errores de medio son más determinantes que el “estado de salud”.
Una unidad que empieza a tener problemas para leer/escribir sectores reales es una unidad que deberías tratar como culpable hasta probar lo contrario.
1) Sectores reubicados: Reallocated_Sector_Ct (05)
Este es el clásico: sectores que fueron marcados como defectuosos y reubicados a repuestos. Un recuento distinto de cero no es una muerte instantánea,
pero es una de las señales más claras de que la superficie se está degradando en discos giratorios y en algunos firmwares de SSD SATA.
Significado operativo: La unidad ya falló al almacenar datos de forma fiable al menos una vez.
Qué predice el fallo:
- La tasa de crecimiento importa más que el número absoluto.
- Reubicaciones nuevas durante lecturas intensas (scrub/backup) son especialmente condenatorias.
- Reubicaciones junto con sectores pendientes/uncorrectable es una combinación de “programar reemplazo”.
2) Sectores pendientes actuales: Current_Pending_Sector (C5)
Los sectores pendientes son la unidad diciendo: “Intenté leer este sector y no pude corregirlo. Si lo reescribes con éxito,
lo borraré; si reescribir falla, lo reubicaré.”
Los sectores pendientes son más accionables que los reubicados porque se correlacionan con
fallos de lectura que pueden aparecer como errores de E/S ahora, no solo “algo falló en algún momento”.
Decisiones:
- Cualquier número distinto de cero de sectores pendientes en una unidad con datos importantes es un detonante para iniciar pruebas controladas y planificar el reemplazo.
- Si el recuento baja a cero después de reescribir (o tras un scrub que fuerza lecturas), todavía lo tratas como un aviso.
- Si los sectores pendientes persisten o aumentan, reemplaza. No negocies con la entropía.
3) Offline uncorrectable: Offline_Uncorrectable (C6)
Esto cuenta errores no corregibles encontrados durante escaneos offline o auto-pruebas. Tiende a alinearse con “no podrás leer algunos datos sin redundancia.”
Decisiones:
- Un C6 distinto de cero en una unidad de datos significa que deberías asumir que tienes bloques ilegibles hasta probar lo contrario.
- Combina con comprobaciones del sistema de archivos, scrubs de RAID y lecturas dirigidas de áreas importantes (imágenes VM, bases de datos).
4) Errores de lectura no corregibles (variantes del proveedor)
En tablas SMART SATA/ATA verás atributos como Raw_Read_Error_Rate (01) y
Seek_Error_Rate (07). Los valores normalizados a menudo son inútiles (especialmente en Seagate).
Pero algunas unidades exponen contadores adicionales para errores no corregibles.
La clave no es el nombre “rate”. La clave es: ¿la unidad está devolviendo errores de lectura no corregibles al host?
Eso aparece de forma más fiable en:
- Entradas en el registro de errores SMART
- Fallos en el registro de auto-pruebas
- Mensajes de error de E/S en el kernel
- Errores de checksum en RAID/ZFS
5) Fallos en el registro de auto-pruebas SMART (no es un atributo, sino un veredicto)
Si una auto-prueba larga termina con “Completed: read failure” o “Completed: unknown failure”, eso es la unidad
admitiendo que no puede leer su propio medio de forma fiable.
Decisión: Si la unidad tiene algo que te importe, el reemplazo es la opción por defecto.
6) NVMe “critical warning” y errores de medio
El informe de salud NVMe es diferente. Dos campos NVMe importan mucho:
- Critical Warning (máscara de bits): si está activado, el dispositivo pide atención.
- Media and Data Integrity Errors: cuenta fallos que el controlador no pudo recuperar.
También vigila Percentage Used (desgaste). No es predictor por sí solo, pero desgaste alto más errores de medio es una combinación mala.
7) Errores a nivel de interfaz: UDMA_CRC_Error_Count (C7)
Este no predice fallo de la unidad. Predice flakiness de cableado, backplane o controlador.
Si C7 crece, estás corrompiendo tu día con errores de enlace.
Decisión: Reemplaza/ajusta el cable, revisa el backplane, revisa la alimentación y deja de culpar la superficie del disco.
Una cita que se ha pasado por equipos de operaciones durante décadas:
«La esperanza no es una estrategia.»
— James Cameron
Broma #1: “SMART ‘PASSED’” es como un niño pequeño diciendo “yo no lo rompí”. Punto de datos interesante, no una certificación.
Los atributos que te hacen perder el tiempo (la mayoría de las veces)
Algunos atributos SMART son famosos sobre todo porque aparecen en todas las salidas de smartctl,
no porque sean predictivos para tu incidente.
Raw_Read_Error_Rate (01) y Seek_Error_Rate (07)
En muchos fabricantes estos valores RAW son contadores gigantes que aumentan constantemente y no significan nada sin
contexto propietario. La gente entra en pánico porque el número se ve aterrador. Es comprensible: es enorme, está etiquetado “error” y los humanos buscan patrones.
Cuando importan: cuando el registro de auto-pruebas de la unidad, el registro de errores SMART o los registros del kernel también muestran errores de lectura reales.
Power_On_Hours (09) y Start_Stop_Count (04)
Útiles para planificación de ciclo de vida y argumentos de garantía. Débiles como predictores inmediatos de fallo.
Las unidades pueden morir jóvenes; las unidades pueden correr antiguas y persistentes.
Temperature_Celsius (194/190)
La temperatura importa, pero es un amplificador de riesgo, no un detector de humo. Si vas caliente,
verás más errores y vida más corta. Pero un pico de temperatura aislado no es razón para cambiar una unidad.
Horas de vuelo del cabezal, ciclos de carga, contadores de vibración
Estos pueden ser significativos en flotas grandes cuando los correlacionas. En un único servidor, mayormente te dicen:
“Este chasis está en un armario con mala ventilación y talento para hacer chillar a los ventiladores.”
“Resultado de auto-evaluación de salud general: PASSED”
Trátalo como la luz “check engine” de un coche apagada. Agradable, pero no tranquilizador si el motor ya hace ruidos metálicos.
NVMe vs SATA: telemetría diferente, trampas distintas
Debian 13 facilita ejecutar tanto SMART ATA como los registros NVMe, pero el modelo mental difiere:
- SATA/ATA SMART expone muchos atributos; la interpretación es en parte folklore, en parte experiencia, en parte documentos de proveedores que no tienes.
- NVMe expone un registro de salud más estructurado con contadores más claros: errores de medio, cierres inseguros, porcentaje de desgaste y eventos de temperatura.
La trampa con NVMe es asumir que siempre es “mejor”. Las unidades NVMe pueden fallar abruptamente (problemas de firmware/controlador),
y “Percentage Used” puede adormecer a la gente pensando: “Solo 12% usado, debe estar bien.” A los errores de medio no les importa tu optimismo.
La trampa con SATA es lo contrario: asumir que cada atributo es interpretable. Muchos no lo son. Es mejor concentrarse
en el pequeño conjunto que mapea de forma fiable a fallos: reubicaciones, pendientes, no corregibles, fallos de auto-prueba
y registros de error reales.
Guion de diagnóstico rápido (primeras/segundas/terceras comprobaciones)
Cuando llega una advertencia SMART, quieres responder dos preguntas rápidamente:
¿Hay riesgo de datos ahora mismo? y ¿es el problema el disco o el camino al disco?
Primero: confirma que el síntoma no es una alucinación del monitoreo
- Revisa los registros del kernel en busca de errores de E/S y reinicios de enlace.
- Revisa los valores actuales de smartctl y los registros de error/auto-prueba.
- Comprueba si el atributo SMART cambió una sola vez o está en tendencia.
Segundo: clasifica el modo de fallo
- Degradación del medio: pendientes/reubicados/no corregibles, fallos de lectura en auto-pruebas.
- Interfaz/camino: errores CRC, reinicios de enlace SATA, timeouts, problemas de HBA, alimentación/backplane.
- Inducido por la carga: errores que aparecen solo bajo lecturas intensas o solo en LBAs específicos (región mala).
- Salud del controlador NVMe: critical warning activado, errores de medio incrementándose, estrangulamiento térmico, muchos cierres inseguros.
Tercero: decide rápido—reemplazar ahora, probar ahora o vigilar
- Reemplazar ahora: cualquier C5/C6 distinto de cero que persista, fallos de auto-prueba, errores de medio en NVMe o errores de E/S en kernel en discos de datos importantes.
- Probar ahora: un único sector pendiente que se limpia, una única reubicación sin tendencia o contadores sospechosos pero no fatales (ejecutar prueba larga + scrub).
- Vigilar: errores CRC sin errores de medio tras arreglar cableado; problemas de temperatura tras corregir flujo de aire; “PASSED” y nada más.
Tareas prácticas: comandos, salidas y decisiones (12+)
Estas son las tareas que realmente ejecuto en Debian cuando aparecen alertas SMART. Cada una incluye:
comando, ejemplo de salida, qué significa y qué decisión tomar.
Tarea 1: Identificar el disco y su ruta (no adivines)
cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,TRAN,ROTA,MOUNTPOINTS
NAME MODEL SERIAL SIZE TYPE TRAN ROTA MOUNTPOINTS
sda ST8000NM000A-2KE1 ZR123ABC 7.3T disk sata 1
├─sda1 512M part 1 /boot/efi
└─sda2 7.3T part 1
nvme0n1 Samsung SSD 990 S7KX... 1.8T disk nvme 0
└─nvme0n1p1 1.8T part 0 /
Qué significa: Confirma qué dispositivo es giratorio (ROTA=1) vs SSD (ROTA=0), y mapea los puntos de montaje.
Decisión: Usa la ruta de herramienta correcta (/dev/sda vs /dev/nvme0 o /dev/nvme0n1) y no reemplaces la unidad equivocada.
Tarea 2: Obtener el resumen SMART para discos SATA/ATA
cr0x@server:~$ sudo smartctl -a /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
=== START OF INFORMATION SECTION ===
Model Family: Seagate Exos 7E8
Device Model: ST8000NM000A-2KE1
Serial Number: ZR123ABC
User Capacity: 8,001,563,222,016 bytes [8.00 TB]
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 100 100 010 Pre-fail Always - 8
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 8
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 1
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 1
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
Qué significa: “PASSED” es irrelevante aquí; C5=1 y C6=1 son riesgo activo. Reallocated=8 muestra remapeos previos.
Decisión: Ejecuta una prueba larga inmediatamente y programa el reemplazo. Si los datos son críticos, inicia la evacuación ahora.
Tarea 3: Obtener SMART/registro de salud NVMe de la forma correcta
cr0x@server:~$ sudo smartctl -a /dev/nvme0
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number: Samsung SSD 990 PRO 2TB
Serial Number: S7KX...
Firmware Version: 5B2QJXD7
PCI Vendor/Subsystem ID: 0x144d
IEEE OUI Identifier: 0x002538
Total NVM Capacity: 2,000,398,934,016 [2.00 TB]
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 45 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 6%
Data Units Read: 18,345,112
Data Units Written: 11,902,771
Host Read Commands: 247,110,004
Host Write Commands: 183,991,201
Controller Busy Time: 2,401
Media and Data Integrity Errors: 0
Unsafe Shutdowns: 7
Qué significa: NVMe sano: sin advertencias críticas, sin errores de medio, bajo desgaste. Los cierres inseguros pueden ser un problema de instalación/energía.
Decisión: Si tuviste un incidente, busca en otro lado (energía, kernel, sistema de archivos). Aun así arregla los cierres inseguros porque se correlacionan con rarezas futuras.
Tarea 4: Revisar el registro de errores SMART (ATA) para ver fallos reales, no solo contadores
cr0x@server:~$ sudo smartctl -l error /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
SMART Error Log Version: 1
ATA Error Count: 2
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Error 2 occurred at disk power-on lifetime: 28421 hours (1184 days + 5 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 00 00 00 40 Error: UNC at LBA = 0x00a1b2c3 = 10629827
Qué significa: UNC = no corregible. La unidad devolvió una lectura irrecuperable en un LBA específico.
Decisión: Trátalo como fallo de medio. Si hay redundancia, realiza un scrub/resilver; si no, prioriza la copia de seguridad y el reemplazo.
Tarea 5: Revisar el registro de auto-pruebas SMART (la confesión de la unidad)
cr0x@server:~$ sudo smartctl -l selftest /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
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 90% 28422 10629827
# 2 Short offline Completed without error 00% 28420 -
Qué significa: La prueba corta pasó; la larga encontró un fallo de lectura en un LBA. Eso es común: las pruebas cortas no cubren suficiente superficie.
Decisión: Reemplaza el disco. Además ejecuta comprobaciones de nivel superior (scrub) para asegurar que la redundancia corrigió los datos.
Tarea 6: Iniciar una prueba SMART corta (triage rápido)
cr0x@server:~$ sudo smartctl -t short /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
Testing has begun.
Please wait 2 minutes for test to complete.
Test will complete after Tue Dec 29 03:14:12 2025
Qué significa: La unidad aceptó la petición de prueba. Esto no prueba la salud; solo verifica lo básico.
Decisión: Si la prueba corta falla, es señal inmediata de reemplazo. Si pasa pero tienes pendientes/no corregibles, aún ejecutas la prueba larga.
Tarea 7: Iniciar una prueba SMART larga (cobertura de superficie)
cr0x@server:~$ sudo smartctl -t long /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
Testing has begun.
Please wait 822 minutes for test to complete.
Test will complete after Tue Dec 29 17:02:41 2025
Qué significa: El tiempo de prueba larga es realista para HDDs grandes. Forzará lecturas a través del medio.
Decisión: Planifícalo según la carga. En arrays ocupados, programa fuera de hora pico, pero no lo postergues una semana “porque es incómodo”.
Tarea 8: Vigilar errores de E/S a nivel kernel y reinicios de enlace
cr0x@server:~$ sudo journalctl -k -S -2h | egrep -i 'ata[0-9]|i/o error|reset|nvme|blk_update_request|medium error' | tail -n 30
Dec 29 01:42:18 server kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 29 01:42:18 server kernel: ata3.00: failed command: READ FPDMA QUEUED
Dec 29 01:42:18 server kernel: blk_update_request: I/O error, dev sda, sector 10629827 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 29 01:42:19 server kernel: ata3: hard resetting link
Dec 29 01:42:24 server kernel: ata3: link is slow to respond, please be patient (ready=0)
Dec 29 01:42:29 server kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Qué significa: Error de E/S en un sector coincide con error LBA en SMART: problema de medio. Los reinicios de enlace pueden ser secundarios (unidad luchando) o por cableado/backplane.
Decisión: Si ves errores de medio, reemplaza. Si solo ves reinicios y CRC que aumentan, céntrate en cableado/HBA.
Tarea 9: Comprobar crecimiento de errores UDMA CRC (problema del camino)
cr0x@server:~$ sudo smartctl -A /dev/sda | egrep 'UDMA_CRC_Error_Count|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 8
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 1
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 1
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 12
Qué significa: Los errores CRC son corrupción a nivel de enlace. No deberían aumentar. También hay errores de medio aquí, así que probablemente tienes ambas cosas: una unidad enferma y un camino cuestionable.
Decisión: Reemplaza la unidad (medio). Mientras lo haces, vuelve a asentar/reemplaza el cable o revisa el backplane para evitar que la siguiente unidad herede la misma historia de CRC.
Tarea 10: Ejecutar un scrub/comprobación RAID (mdadm) e interpretar el resultado
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5]
md0 : active raid1 sda2[0] sdb2[1]
7813772288 blocks super 1.2 [2/2] [UU]
[==>..................] check = 12.4% (970000000/7813772288) finish=420.0min speed=270000K/sec
unused devices: <none>
Qué significa: Se está ejecutando una comprobación. Si la comprobación encuentra bloques ilegibles en un miembro, md confiará en el otro (si está intacto).
Decisión: Déjala terminar y vigila los registros del kernel. Si aparecen errores, acelera el reemplazo y verifica que el espejo esté realmente limpio.
Tarea 11: Para ZFS, hacer scrub y buscar errores de checksum/lectura
cr0x@server:~$ sudo zpool status -v
pool: tank
state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device or restore the affected file(s) from backup.
scan: scrub repaired 0B in 01:12:33 with 0 errors on Tue Dec 29 02:10:01 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sda DEGRADED 5 0 2
sdb ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
tank/vmstore:vm-102-disk-0
Qué significa: ZFS te está diciendo la verdad incómoda: hubo errores de lectura/checksum, y un archivo está afectado.
Decisión: Reemplaza sda, luego restaura el dataset/archivo afectado desde copia de seguridad o réplica. Ejecuta scrub otra vez después del resilver.
Tarea 12: Para btrfs, revisar estadísticas del dispositivo (no es SMART, pero es la realidad)
cr0x@server:~$ sudo btrfs device stats /mnt/data
[/dev/sda2].write_io_errs 0
[/dev/sda2].read_io_errs 3
[/dev/sda2].flush_io_errs 0
[/dev/sda2].corruption_errs 2
[/dev/sda2].generation_errs 0
Qué significa: El sistema de archivos observó errores de lectura y corrupción. Eso ya no es “quizás”.
Decisión: Reemplaza el dispositivo subyacente y ejecuta un scrub. Confirma que la redundancia/reparación funcionó; si no, restaura desde copia de seguridad.
Tarea 13: Habilitar y configurar smartd para alertas accionables
cr0x@server:~$ sudo apt update
...
cr0x@server:~$ sudo apt install -y smartmontools
...
cr0x@server:~$ sudo systemctl enable --now smartd
Created symlink /etc/systemd/system/multi-user.target.wants/smartd.service → /lib/systemd/system/smartd.service.
Qué significa: smartd ahora está en ejecución y puede monitorear dispositivos periódicamente.
Decisión: No te quedes ahí. Debes afinar /etc/smartd.conf para monitorear los dispositivos correctos (especialmente detrás de HBAs) y para ejecutar pruebas.
Tarea 14: Validar que smartd vigila los discos que crees que vigila
cr0x@server:~$ sudo smartd -q showtests
smartd 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
Device: /dev/sda, will do test schedule 'S/../.././02|L/../../6/03'
Device: /dev/nvme0, will do test schedule 'S/../.././02|L/../../6/03'
Qué significa: smartd parseó tus horarios y ejecutará pruebas cortas diarias a las 02:00 y pruebas largas los sábados a las 03:00.
Decisión: Si faltan tus discos críticos, arregla el descubrimiento (passthrough SATA, megaraid, mapeo de dispositivos scsi) antes de confiar en las alertas.
Tarea 15: Inspeccionar los mensajes de registro en Debian 13 desde smartd
cr0x@server:~$ sudo journalctl -u smartd -S -24h | tail -n 40
Dec 29 02:00:01 server smartd[1321]: Device: /dev/sda, starting scheduled Short self-test.
Dec 29 02:02:15 server smartd[1321]: Device: /dev/sda, SMART Self-test log error count increased from 0 to 1
Dec 29 02:02:15 server smartd[1321]: Device: /dev/sda, SMART Prefailure Attribute: 5 Reallocated_Sector_Ct changed from 7 to 8
Qué significa: smartd está haciendo su trabajo: ejecutó la prueba, vio un nuevo problema en el registro de auto-pruebas y observó crecimiento de atributos.
Decisión: Esto es territorio de reemplazo. También captura la salida completa de smartctl -a para el ticket y el postmortem.
Tarea 16: Si el disco está detrás de un HBA/controlador RAID, trátalo explícitamente
cr0x@server:~$ sudo smartctl -a -d sat /dev/sdb
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model: WDC WD80EFAX-68KNBN0
Serial Number: 7SG...
...
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 200 000 Old_age Always - 34
Qué significa: El medio parece bien; los errores CRC son altos. Eso apunta lejos del plato y hacia problemas del camino.
Decisión: Vuelve a asentar/reemplaza el cable SATA/slot de backplane, revisa firmware del HBA y observa si C7 sigue creciendo después.
Broma #2: Si tu estrategia de almacenamiento es “sabremos que está mal cuando deje de funcionar”, felicidades por tu emocionante carrera en respuesta de emergencias.
Tres microhistorias corporativas desde las trincheras SMART
Microhistoria 1: El incidente causado por una suposición errónea
Una empresa SaaS mediana ejecutaba una flota de servidores Debian con SSDs locales para una capa de caché y HDDs para datos a granel.
El monitoreo alertó sobre Reallocated_Sector_Ct para un par de HDDs. El ingeniero on-call miró de reojo
“SMART overall-health: PASSED” y cerró la alerta como ruido. La suposición fue simple: “Si SMART dice passed, está bien.”
Dos días después, un trabajo nocturno de analítica empezó a fallar. No catastróficamente—solo lo suficiente para reintentar y obstruir la cola.
La latencia de los paneles de clientes subió. Los gráficos de almacenamiento eran confusos: picos de iowait y luego calma; un patrón que
parecía “sistema ocupado” más que “disco muriéndose”.
Cuando finalmente ejecutaron smartctl -l selftest, la prueba larga ya había reportado un fallo de lectura en un LBA consistente.
ZFS (que usaban en un clúster) habría alertado con fuerza, pero ese dataset en particular estaba en ext4 sobre mdadm,
y los errores aparecieron como errores de E/S intermitentes en el registro del kernel que nadie había correlacionado con la advertencia SMART.
La solución fue aburrida: reemplazar el disco, reconstruir el espejo, volver a ejecutar el trabajo. El postmortem, sin embargo, fue picante de forma útil.
Cambiaron la política: cualquier recuento de pendientes/no corregibles en discos de datos a granel desencadena programación de reemplazo, independientemente de “PASSED.”
También enseñaron al equipo a mirar el registro de errores SMART y el de auto-pruebas, no solo la línea de resumen.
Microhistoria 2: La optimización que salió mal
En otra organización, alguien intentó reducir ventanas de mantenimiento moviendo las pruebas SMART largas a “solo trimestral”, porque
“la prueba larga es disruptiva y además tenemos RAID”. También deshabilitaron los scrubs de RAID para evitar picos de rendimiento en horas laborales.
La optimización se veía bien en papel: menos lecturas en segundo plano, menos quejas de latencia.
Unos meses después, un disco empezó a crecer Current_Pending_Sector. Nadie lo notó porque smartd solo hacía pruebas cortas,
y los sectores pendientes estaban en una región fría raramente leída. La producción parecía sana. Las copias de seguridad “eran exitosas” porque eran
incrementales y no tocaban los bloques malos.
Entonces vino el evento doble: un segundo disco en el mismo grupo RAID falló por completo (el controlador lo dejó caer).
El rebuild castigó al disco superviviente, forzando lecturas a través de la superficie. Ahí los sectores pendientes se convirtieron en no corregibles.
El array no pudo reconstruir algunos bloques. No todo el dataset. Solo lo suficiente para corromper varias imágenes VM.
La causa raíz no fue “RAID es inútil”. La causa fue eliminar los únicos mecanismos que habrían forzado a mostrar errores latentes
mientras la redundancia aún estaba intacta: scrubs regulares y pruebas largas. Reintrodujeron scrubs mensuales y pruebas largas semanales para HDDs,
luego los limitaron en tasa y los programaron fuera de horas pico. Las quejas de latencia bajaron después de que dejaron de ejecutarlos a la hora de comer.
Microhistoria 3: La práctica aburrida pero correcta que salvó el día
Una empresa con control de cambios estricto ejecutaba Debian 13 en servidores de base de datos con NVMe espejados.
Tenían una política que sonaba tediosa: cada ticket de reemplazo de unidad debía incluir smartctl -a,
las últimas 24 horas de registros del kernel para el dispositivo y la salida de una comprobación de redundancia (mdadm check o ZFS scrub).
Una semana, una alerta de monitoreo se activó: aumentaron los “Unsafe Shutdowns” en NVMe. Nadie entró en pánico. La unidad “PASSED”, sin errores de medio, sin advertencia crítica.
Pero la política requería reunir evidencia, así que el ingeniero on-call también sacó los últimos registros del kernel y notó breves eventos de pérdida de energía en el bus PCIe.
Lo rastrearon hasta una conexión de distribución de energía floja en una PDU de rack (no dramático, solo ligeramente desajustada después de una visita de mantenimiento).
Si hubieran reemplazado el NVMe habrían “arreglado” nada y habrían ocultado el problema de la instalación. En cambio estabilizaron la alimentación y observaron los contadores.
No hubo más aumentos de cierres inseguros. No hubo corrupción.
La práctica aburrida—reunir múltiples señales antes de actuar—evitó un ciclo de reemplazos por cargo-cul y detectó el riesgo sistémico real.
A veces el movimiento de ingeniería más fiable es papeleo con dientes.
Errores comunes: síntoma → causa raíz → solución
Aquí están los modos de fallo que he visto repetidamente, mapeados a lo que realmente debes hacer al respecto.
Esta sección es intencionalmente específica; el consejo genérico es como proliferan los incidentes.
1) “SMART PASSED pero los logs de la app muestran errores de E/S”
Síntoma: Base de datos o host VM ve errores de lectura esporádicos; SMART overall-health dice PASSED.
Causa raíz: Los umbrales del proveedor son laxos; el resumen de salud no salta hasta tarde. Los errores de medio aparecen primero en registros/auto-pruebas.
Solución: Revisa registro de errores SMART y registro de auto-pruebas; ejecuta prueba larga; si existen fallos de lectura, reemplaza la unidad y verifica integridad de datos vía scrub.
2) “UDMA_CRC_Error_Count está subiendo; reemplazar discos no ayudó”
Síntoma: Errores CRC aumentan en varios discos en la misma bahía/ruta de cable.
Causa raíz: Cable SATA/backplane defectuoso, conector marginal de HBA o ruido de alimentación causando corrupción de enlace.
Solución: Reemplaza/ajusta cables; mueve el disco a otra bahía; actualiza firmware del HBA; inspecciona PSU/backplane; confirma que el contador CRC deja de aumentar.
3) “Current_Pending_Sector es 1 y luego volvió a 0, así que estamos bien”
Síntoma: C5 parpadea y se limpia tras una prueba.
Causa raíz: Un sector débil fue reescrito/reubicado; puede ser un signo temprano de degradación de superficie.
Solución: Ejecuta prueba larga y un scrub del sistema de archivos/RAID; monitoriza la tendencia semanalmente. Si aparecen nuevos pendientes, reemplaza.
4) “Las pruebas SMART largas dejan el rendimiento terrible, así que las deshabilitamos”
Síntoma: Quejas de usuarios durante las pruebas; tareas en segundo plano eliminadas.
Causa raíz: Pruebas programadas en hora pico, sin limitación de I/O, sin coordinación con la carga.
Solución: Programa fuera de pico; escalona discos; limita la tasa de scrub/comprobación; acepta algún coste de mantenimiento para evitar sorpresas en tiempo de reconstrucción.
5) “NVMe Percentage Used es bajo; aun así hay errores de medio”
Síntoma: Desgaste parece bien; errores de integridad de medio/datos incrementan.
Causa raíz: Problemas de controlador o NAND no relacionados con desgaste, defectos de firmware o inestabilidad térmica/eléctrica.
Solución: Tratar errores de medio como reales; actualizar firmware si la política lo permite; revisar temperaturas y eventos de energía; reemplazar el dispositivo si los errores persisten.
6) “Hicimos una prueba SMART; pasó; la corrupción sigue existiendo”
Síntoma: Pruebas SMART muestran “Completed without error”, pero ZFS/btrfs informa corrupción.
Causa raíz: Las pruebas SMART no validan la integridad de extremo a extremo; puede que no toquen bloques exactos o no detecten problemas de camino transitorios.
Solución: Confía en los checksums del sistema de archivos sobre SMART. Haz scrub, localiza archivos afectados, restaura desde copia de seguridad e investiga controlador/cableado.
7) “smartd está en ejecución pero nunca recibimos alertas”
Síntoma: smartd activo; sin notificaciones incluso cuando una unidad está claramente fallando.
Causa raíz: smartd no configurado para monitorear todos los dispositivos, especialmente detrás de HBAs; o la ruta de correo/notificación está rota.
Solución: Valida dispositivos monitorizados con smartd -q showtests; prueba la ruta de alertas; configura explícitamente dispositivos con tipos -d correctos.
Listas de verificación / plan paso a paso
Checklist A: Cuando ves sectores pendientes/no corregibles (C5/C6) en HDD SATA
- Captura evidencia:
smartctl -a,-l error,-l selftest, y registros recientes del kernel para el dispositivo. - Ejecuta una auto-prueba larga (
smartctl -t long) si el sistema puede tolerar la carga de lectura. - Ejecuta tu validación de redundancia (mdadm check / ZFS scrub / btrfs scrub) mientras la redundancia esté intacta.
- Si la prueba larga falla o C5/C6 aumenta: programa reemplazo inmediatamente.
- Después del reemplazo: reconstruye/resilver, luego haz scrub otra vez para confirmar que no quedan errores residuales.
Checklist B: Cuando solo ves errores CRC (C7) y no errores de medio
- Confirma que C5/C6 están a cero y las auto-pruebas están limpias.
- Vuelve a asentar/reemplaza el cable SATA, o mueve a otra bahía/slot de backplane.
- Revisa registros del kernel en busca de reinicios/timeouts de enlace.
- Observa C7 durante 24–72 horas. Debería dejar de aumentar.
- Si C7 sigue subiendo en múltiples discos, escala a investigación de HBA/backplane/energía.
Checklist C: Señales de advertencia NVMe
- Recopila salida de
smartctl -a /dev/nvmeX(critical warning, media errors, temperatura, percentage used). - Revisa registros del kernel en busca de PCIe AER, reinicios NVMe o timeouts.
- Si critical warning está activado o media errors aumentan: reemplaza la unidad (y guarda evidencia para RMA).
- Si solo aumentan los unsafe shutdowns: investiga energía/PSU/PDU y reinicios abruptos antes de culpar al SSD.
Checklist D: Hacer que smartd sea realmente útil (no solo instalado)
- Inventario de dispositivos: SATA, SAS, NVMe, bridges USB, HBAs.
- Configura
/etc/smartd.confcon tipos de dispositivo y horarios correctos. - Verifica el parseo y los horarios:
smartd -q showtests. - Verifica el envío de alertas: simula una notificación o valida la ingestión de journald en tu monitoreo.
- Revisa semanalmente: cualquier crecimiento en realloc/pending/uncorrectable desencadena un ticket con tendencia y plan.
Preguntas frecuentes
1) ¿Qué atributos SMART deberían despertarme por la noche?
Sectores pendientes (C5), offline uncorrectable (C6), reubicaciones en tendencia (05),
entradas UNC en el registro de errores SMART y fallos de auto-prueba. Para NVMe: critical warning y media/data integrity errors.
2) ¿Un Reallocated_Sector_Ct distinto de cero siempre es motivo de reemplazo inmediato?
No siempre. Un recuento pequeño y estable en un HDD antiguo puede seguir funcionando. Pero el crecimiento—especialmente durante scrubs/pruebas—
es motivo para planificar reemplazo. Si también tienes C5/C6 o fallos de auto-prueba, deja de debatir y reemplaza.
3) ¿Por qué Current_Pending_Sector volvió a cero?
Porque el sector fue reescrito o reubicado con éxito. Eso limpia la lista de pendientes. No borra el hecho de que
la unidad encontró una lectura que no pudo corregir. Trátalo como una advertencia temprana y busca recurrencia.
4) ¿Puede SMART predecir la muerte súbita de un SSD por bugs de firmware?
A veces verás reinicios, advertencias críticas o contadores que suben. A menudo no. Fallos de firmware/controlador pueden ser abruptos.
Por eso existen redundancia y copias de seguridad: para manejar fallos que no avisan.
5) ¿Debo confiar en RAW o en valores normalizados SMART?
Prefiere RAW para contadores como reubicaciones/pendientes/no corregibles/CRC. Los valores normalizados son escalas del proveedor y pueden ser engañosos.
Pero no ignores cruces de umbral normalizados: suelen significar que el proveedor finalmente admite que la unidad está muerta.
6) ¿Valen la pena las pruebas cortas?
Sí, como chequeo rápido y para automatización. No, no son suficientes para validar la superficie.
Si investigas una advertencia, una prueba larga (más un scrub/comprobación) es el movimiento adulto.
7) SMART dice que el disco está bien, pero ZFS muestra errores de checksum—¿qué hago?
Cree en ZFS. Los checksums del sistema de archivos detectan corrupción de extremo a extremo que SMART puede no ver. Haz scrub, identifica archivos afectados,
reemplaza hardware sospechoso (disco, cable, HBA) y restaura desde copia de seguridad si es necesario.
8) ¿Con qué frecuencia debería ejecutar pruebas SMART largas en HDDs?
Semanalmente es común para flotas importantes, mensual para entornos más tranquilos. La cadencia correcta es la que realmente ejecutas
sin causar incidentes de rendimiento. Escalona discos y evita horas pico.
9) ¿Los errores CRC significan que mis datos están corruptos?
Los errores CRC indican problemas de transmisión a nivel de enlace; el protocolo detecta y reintenta. Normalmente obtienes reintentos y latencia,
no corrupción silenciosa. Aun así, errores frecuentes de enlace pueden provocar timeouts y fallos de nivel superior, así que arregla el camino.
10) ¿Qué es lo más útil para guardar en un ticket cuando SMART advierte?
Una salida completa de smartctl -a más el registro de errores SMART y el registro de auto-pruebas, y los últimos registros relevantes del kernel.
Los datos de tendencia (qué cambió desde la semana pasada) son incluso mejores que una sola instantánea.
Conclusión: siguientes pasos que puedes hacer hoy
Las advertencias SMART no son un debate filosófico. Son un insumo para una decisión bajo incertidumbre.
Tu trabajo en Debian 13 es tomar esa decisión rápido, con las señales correctas y sin superstición.
- Concéntrate en señales predictivas: pendientes (C5), no corregibles (C6), reubicaciones en tendencia (05), fallos de auto-prueba, entradas UNC en el registro SMART, advertencias críticas NVMe y errores de medio.
- Diferencia medio de camino: C7 y reinicios de enlace suelen ser cables/backplanes/HBAs, no platos.
- Combina capas: SMART + registros del kernel + resultados de scrub/comprobación. Los sistemas de checksum de archivos (ZFS/btrfs) son brutalmente honestos—úsalos.
- Haz smartd real: configura horarios, valida dispositivos monitorizados, verifica la entrega de alertas y captura evidencia en los tickets.
- Cuando dudes y los datos importen: evacua, reemplaza y valida con un scrub. Las unidades son más baratas que las llamadas de incidente.