smartctl y smartmontools: La Guía Completa de Monitoreo de Salud de Unidades en Linux

smartctl es la interfaz principal de línea de comandos del paquete smartmontools, diseñada para consultar, probar e interpretar datos S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) integrados en el firmware de HDDs, SSDs y unidades NVMe. Se comunica directamente con el firmware de la unidad a través de interfaces ATA, SCSI o NVMe para exponer telemetría de diagnóstico sin procesar que el propio sistema operativo no expone a través de rutas de E/S estándar.

Para cualquier administrador de Linux que gestione almacenamiento físico o virtual — ya sea en un servidor bare-metal, un Servidor Dedicado, o una matriz de discos conectada localmente — smartctl es la herramienta más fiable para detectar fallos inminentes de unidades antes de que causen pérdida irrecuperable de datos.

Qué es S.M.A.R.T. y por qué es importante

S.M.A.R.T. es un sistema de monitorización integrado en prácticamente todos los dispositivos de almacenamiento de consumo y empresariales fabricados después de 1996. Opera a nivel de firmware, rastreando continuamente docenas de parámetros internos: tasas de errores de lectura/escritura, indicadores de estrés mecánico, niveles de desgaste de NAND, recuentos de sectores reasignados y lecturas térmicas.

La distinción crítica que la mayoría de las guías omiten: los datos S.M.A.R.T. son predictivos, no reactivos. Una unidad puede pasar una verificación del sistema de archivos y servir E/S normalmente mientras acumula simultáneamente sectores reasignados a una tasa que estadísticamente predice un fallo en semanas. smartctl expone este estado de degradación oculto.

S.M.A.R.T. opera en tres familias de interfaces de almacenamiento:

• ATA/SATA — la especificación S.M.A.R.T. original, con más atributos
• SCSI/SAS — utiliza un modelo de atributos diferente (páginas de registro de Excepciones Informativas)
• NVMe — expone datos de salud a través del NVMe Health Information Log (Log Page 0x02), con métricas como capacidad de repuesto disponible, porcentaje utilizado y apagados no seguros

Instalación de smartmontools en Linux

El paquete smartmontools está disponible en los repositorios oficiales de todas las principales distribuciones de Linux. Instale la versión apropiada para su entorno:

Debian / Ubuntu:

“`bash

sudo apt-get update && sudo apt-get install smartmontools

“`

CentOS / RHEL 7:

“`bash

sudo yum install smartmontools

“`

CentOS Stream / RHEL 8+ / AlmaLinux / Rocky Linux:

“`bash

sudo dnf install smartmontools

“`

Fedora:

“`bash

sudo dnf install smartmontools

“`

Arch Linux:

“`bash

sudo pacman -S smartmontools

“`

openSUSE:

“`bash

sudo zypper install smartmontools

“`

Después de la instalación, verifique la versión y confirme que el soporte NVMe está compilado:

“`bash

smartctl –version

“`

Busque `NVMe` en la lista de tipos de dispositivos compatibles. Las versiones anteriores a la 6.6 tienen soporte NVMe incompleto — en servidores modernos con SSDs NVMe, asegúrese de ejecutar smartmontools 7.x o posterior.

Identificación de sus dispositivos de almacenamiento

Antes de ejecutar cualquier comando smartctl, identifique el nodo de dispositivo correcto. Confundir los identificadores de dispositivo en un sistema con múltiples discos es un error común y costoso.

“`bash

lsblk -d -o NAME,SIZE,MODEL,TRAN

“`

Esto muestra los nombres de dispositivos junto con el tipo de transporte (sata, nvme, usb), lo que informa directamente qué indicadores de smartctl necesitará. Para dispositivos NVMe, el nodo aparecerá como `/dev/nvme0`, `/dev/nvme1`, etc. — no como `/dev/sdX`.

Para controladores RAID por hardware (LSI MegaRAID, Adaptec, HP Smart Array), las unidades están ocultas detrás del controlador y requieren indicadores explícitos de paso directo, que se tratan en la sección avanzada a continuación.

Comandos principales de smartctl

Visualización de información de identidad del dispositivo

“`bash

sudo smartctl -i /dev/sda

“`

Esto consulta la página IDENTIFY DATA del dispositivo y devuelve el número de modelo, número de serie, revisión de firmware, capacidad, tamaño de sector (512 bytes lógicos vs. 4096 bytes físicos — importante para la alineación) y los indicadores de capacidad S.M.A.R.T. En dispositivos NVMe:

“`bash

sudo smartctl -i /dev/nvme0

“`

Ejecución de una evaluación completa de salud

“`bash

sudo smartctl -H /dev/sda

“`

Devuelve un veredicto de una sola línea: `PASSED` o `FAILED`. Un resultado `FAILED` significa que el propio firmware de la unidad ha determinado que se han superado uno o más umbrales críticos. Una unidad que reporta FAILED debe tratarse como fallida — no espere más confirmación.

Sin embargo, un resultado `PASSED` no significa que la unidad esté en buen estado. Solo significa que ningún umbral ha sido formalmente superado. Por eso el análisis de atributos sin procesar es esencial.

Visualización de todos los atributos S.M.A.R.T.

“`bash

sudo smartctl -A /dev/sda

“`

Este es el comando con mayor densidad de información en uso rutinario. La tabla de salida contiene varias columnas que requieren una interpretación precisa:

El RAW_VALUE es lo que debe analizar principalmente. El sistema normalizado VALUE/WORST/THRESH es útil para la detección automática de umbrales, pero puede ser engañoso — algunos fabricantes utilizan curvas de normalización no estándar.

Salida completa: combinación de indicadores

Para obtener una imagen completa en un solo comando, combine los indicadores de información, salud y atributos:

“`bash

sudo smartctl -a /dev/sda

“`

El indicador en minúsculas `-a` es equivalente a `-H -i -c -A -l error -l selftest`. Este es el comando estándar a ejecutar al diagnosticar una unidad desconocida.

Para una salida aún más detallada que incluya todas las páginas de registro:

“`bash

sudo smartctl -x /dev/sda

“`

Atributos S.M.A.R.T. críticos y cómo interpretarlos

No todos los atributos S.M.A.R.T. tienen el mismo peso diagnóstico. Los siguientes son los atributos que los ingenieros de almacenamiento experimentados tratan como indicadores primarios de fallo:

Indicadores de fallo de alta prioridad

Reallocated_Sector_Ct (ID 5)

El recuento de sectores que la unidad ha reasignado al área de repuesto debido a errores de lectura/escritura/verificación. Cualquier valor distinto de cero en una unidad de menos de dos años merece atención inmediata. Un recuento en aumento constante — incluso de 1 a 5 en un mes — es un fuerte predictor de fallo inminente. En unidades empresariales, un número pequeño puede ser aceptable según las especificaciones del fabricante.

Current_Pending_Sector (ID 197)

Sectores marcados como inestables y en espera de reasignación. Estos sectores han producido errores durante las lecturas pero aún no han sido reasignados con éxito. Un valor distinto de cero aquí significa que la unidad está luchando activamente para leer datos. Si un sector pendiente se escribe posteriormente con éxito, puede ser reasignado o eliminado — pero el medio subyacente es sospechoso.

Uncorrectable_Sector_Count (ID 198) / Offline_Uncorrectable

Sectores que no pudieron ser corregidos por ECC y no pudieron ser reasignados. Este es el atributo más grave. Un valor distinto de cero aquí significa que los datos ya se han perdido de esos sectores. La copia de seguridad inmediata y el reemplazo de la unidad es la única respuesta apropiada.

Reported_Uncorrect (ID 187)

En las unidades modernas, esto cuenta los errores que el ECC interno de la unidad no pudo corregir. Los valores altos indican una degradación grave del medio.

Spin_Retry_Count (ID 10)

Para HDDs, fallos repetidos al hacer girar los platos a la velocidad de operación. Indica estrés mecánico en el motor del husillo o los rodamientos. Cualquier valor distinto de cero en una unidad bajo uso intensivo es una señal de alerta.

Command_Timeout (ID 188)

El recuento de comandos que se abortaron debido a tiempo de espera agotado. Los valores elevados a menudo indican problemas de interfaz (cable, controlador o suministro de energía) en lugar de fallo del medio — pero también pueden preceder al fallo total de la unidad.

Atributos de monitorización secundaria

Raw_Read_Error_Rate (ID 1)

Frecuentemente malinterpretado: en las unidades Seagate, este atributo tiene un valor sin procesar muy alto por diseño, ya que representa una proporción codificada en un campo de 48 bits. Un valor sin procesar de varios millones en una unidad Seagate es normal. En Western Digital y otros fabricantes, el valor sin procesar debería estar cerca de cero. Siempre consulte la documentación del fabricante antes de generar alertas sobre este atributo.

Power_On_Hours (ID 9)

Horas totales de operación. Los HDDs de consumo están típicamente clasificados para 20.000–25.000 horas (aproximadamente 2–3 años de operación continua). Las unidades empresariales están clasificadas para más de 55.000 horas. Use esto para contextualizar otros valores de atributos.

Temperature_Celsius (ID 194)

La temperatura actual de la unidad. El rango de operación óptimo para la mayoría de los HDDs es 25–45°C. Las temperaturas sostenidas por encima de 55°C aceleran el desgaste de los rodamientos y la degradación del medio magnético. Para los SSDs, la tolerancia térmica es generalmente mayor, pero las temperaturas sostenidas por encima de 70°C acelerarán el desgaste de la NAND. En servidores sin flujo de aire adecuado — un problema común en despliegues de rack densos — la limitación térmica puede enmascararse como latencia de E/S antes de que el atributo de temperatura supere cualquier umbral formal.

Wear_Leveling_Count (ID 177) / Media_Wearout_Indicator (ID 233)

Atributos específicos de SSD que rastrean el consumo de resistencia de la NAND. Cuando el VALUE normalizado se acerca al valor THRESH, el SSD se está acercando a su resistencia de escritura nominal. Planifique el reemplazo de forma proactiva.

Power_Cycle_Count (ID 12)

Los ciclos de encendido frecuentes causan estrés mecánico en los HDDs (aparcamiento/desaparcamiento de cabezas, estrés del motor del husillo) y, en menor medida, estrés eléctrico en los SSDs. Recuentos inusualmente altos en relación con Power_On_Hours pueden indicar un entorno de alimentación inestable.

Ejecución de autopruebas de diagnóstico

Las autopruebas S.M.A.R.T. son ejecutadas por el propio firmware de la unidad, no por el sistema operativo. La unidad continúa sirviendo E/S durante las pruebas (con un impacto menor en el rendimiento), lo que hace que estas pruebas sean seguras para ejecutar en sistemas de producción.

Autoprueba corta

“`bash

sudo smartctl -t short /dev/sda

“`

Duración: típicamente 1–5 minutos. Prueba los componentes eléctricos y mecánicos y un pequeño porcentaje de la superficie del disco. Útil para una verificación rápida. Ver resultados después de completar:

“`bash

sudo smartctl -l selftest /dev/sda

“`

Autoprueba larga (prueba extendida)

“`bash

sudo smartctl -t long /dev/sda

“`

Duración: proporcional a la capacidad de la unidad — espere 1 hora por terabyte en un HDD típico de 7200 RPM, y 20–60 minutos en la mayoría de los SSDs. Realiza un análisis completo de la superficie de cada sector. Esta es la prueba definitiva para detectar sectores defectuosos en toda la superficie del medio.

Monitorice el progreso sin esperar a que se complete:

“`bash

sudo smartctl -c /dev/sda

“`

La salida incluye un porcentaje completado y un tiempo estimado de finalización.

Autoprueba de transporte

“`bash

sudo smartctl -t conveyance /dev/sda

“`

Disponible en la mayoría de las unidades ATA. Diseñada para detectar daños producidos durante el envío o la manipulación física. Comprueba problemas causados por impactos mecánicos. La duración es típicamente de 5 minutos. Esta prueba está infrautilizada — es particularmente valiosa al poner en marcha nuevo hardware o después de que un servidor haya sido reubicado físicamente.

Autoprueba selectiva

“`bash

sudo smartctl -t select,0-1000000 /dev/sda

“`

Permite probar un rango LBA específico en lugar de toda la unidad. Invaluable cuando las verificaciones del sistema de archivos han marcado errores en una región específica y necesita confirmar si el medio subyacente es el responsable.

Monitorización de salud específica para NVMe

Las unidades NVMe utilizan un modelo de atributos fundamentalmente diferente. El comando principal de salud:

“`bash

sudo smartctl -a /dev/nvme0

“`

Campos específicos de NVMe clave para monitorizar:

• Available Spare: Porcentaje de bloques NAND de repuesto restantes. Por debajo del 10% se justifica planificar el reemplazo.
• Available Spare Threshold: El umbral definido por el fabricante por debajo del cual la unidad puede reportar fiabilidad degradada.
• Percentage Used: Porcentaje estimado de resistencia de escritura nominal consumida. Al 100%, la unidad ha alcanzado su TBW (Terabytes Written) nominal — puede continuar funcionando, pero las garantías de fiabilidad ya no se aplican.
• Data Units Read / Written: E/S acumulada en unidades de 512.000 bytes. Útil para calcular la carga de trabajo real frente al TBW nominal.
• Media and Data Integrity Errors: Errores de medio no recuperados o errores de integridad de datos detectados por el controlador NVMe. Cualquier valor distinto de cero es grave.
• Number of Error Information Log Entries: Recuento de entradas del registro de errores. Un recuento que crece rápidamente indica problemas persistentes.
• Power State: Estado de energía NVMe actual — relevante para cargas de trabajo sensibles a la latencia donde la unidad puede estar en un estado de ahorro de energía profundo.

RAID por hardware y acceso de paso directo

Cuando las unidades están conectadas a través de un controlador RAID por hardware, el sistema operativo ve el disco virtual del controlador, no las unidades físicas. smartctl requiere paso directo explícito para llegar directamente al firmware de la unidad.

LSI MegaRAID:

“`bash

sudo smartctl -a /dev/sda -d megaraid,0

sudo smartctl -a /dev/sda -d megaraid,1

“`

HP Smart Array (controlador hpsa):

“`bash

sudo smartctl -a /dev/sda -d cciss,0

“`

3ware RAID:

“`bash

sudo smartctl -a /dev/twa0 -d 3ware,0

“`

Si no está seguro de qué tipo de paso directo usar, smartctl puede intentar la detección automática:

“`bash

sudo smartctl –scan

“`

Esto analiza todos los dispositivos de almacenamiento detectables y muestra la ruta de dispositivo recomendada y el indicador de tipo para cada uno.

Habilitación y deshabilitación de S.M.A.R.T.

S.M.A.R.T. está habilitado por defecto en prácticamente todas las unidades modernas. En casos raros — típicamente unidades más antiguas o ciertos entornos virtualizados — puede estar deshabilitado:

“`bash

sudo smartctl -s on /dev/sda

“`

Para deshabilitar (no recomendado excepto para escenarios de prueba específicos):

“`bash

sudo smartctl -s off /dev/sda

“`

Nota: En entornos virtualizados como KVM o VMware, el paso directo de S.M.A.R.T. a las VMs invitadas depende de la configuración del hipervisor. En un entorno de Hosting VPS, el hipervisor típicamente abstrae la unidad física, y smartctl dentro del invitado puede devolver datos limitados o ningún dato. Para acceso completo a S.M.A.R.T., se requiere monitorización a nivel de host físico o un Servidor Dedicado.

Monitorización automatizada con smartd

El demonio smartd es el componente de nivel de producción de smartmontools. Se ejecuta en segundo plano, sondeando periódicamente las unidades y ejecutando pruebas programadas, luego alertando a los administradores cuando se superan umbrales o se producen fallos en las pruebas.

Configuración de /etc/smartd.conf

La configuración predeterminada monitoriza todas las unidades detectadas con configuraciones básicas. Una configuración reforzada para producción tiene este aspecto:

“`

Monitor all ATA/SCSI/NVMe drives with full attribute checking

Run short test every day at 02:00, long test every Saturday at 03:00

Email alert on any failure or attribute change

DEVICESCAN -a -o on -S on

-s (S/../.././02|L/../../6/03)

-m admin@yourdomain.com

-M exec /usr/share/smartmontools/smartd-runner

“`

Directivas clave explicadas:

Habilitación e inicio de smartd

“`bash

sudo systemctl enable smartd

sudo systemctl start smartd

sudo systemctl status smartd

“`

Verifique que el demonio está monitorizando activamente:

“`bash

sudo journalctl -u smartd -f

“`

Configuración de alertas por correo electrónico

Para que las alertas de correo electrónico de smartd funcionen, el sistema requiere un MTA (agente de transferencia de correo) en funcionamiento. En instalaciones de servidor mínimas, instale y configure `postfix` o `msmtp` para retransmisión. Si está utilizando una infraestructura de correo dedicada, considere combinar las alertas de smartd con un servicio de Hosting de Correo Electrónico correctamente configurado para garantizar que la entrega de alertas no sea bloqueada por filtros de spam.

Comparación de atributos S.M.A.R.T.: HDD vs. SSD vs. NVMe

Flujo de trabajo práctico: diagnóstico de una unidad sospechosa

Cuando una unidad muestra síntomas — errores de E/S en `dmesg`, corrupción del sistema de archivos, latencia inusual — siga esta secuencia de diagnóstico:

Paso 1: Confirmar la disponibilidad de S.M.A.R.T.

“`bash

sudo smartctl -i /dev/sda | grep -i "SMART support"

“`

Paso 2: Verificar el veredicto general de salud

“`bash

sudo smartctl -H /dev/sda

“`

Paso 3: Inspeccionar el registro de errores

“`bash

sudo smartctl -l error /dev/sda

“`

El registro de errores registra los últimos 5 errores ATA con marcas de tiempo y direcciones LBA. Cruce las direcciones LBA con los mapas de bloques del sistema de archivos usando `debugfs` o `xfs_db` para determinar si los errores afectan a estructuras críticas del sistema de archivos.

Paso 4: Analizar los atributos críticos

“`bash

sudo smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|Command_Timeout"

“`

Paso 5: Ejecutar una prueba corta para confirmación inmediata

“`bash

sudo smartctl -t short /dev/sda

sleep 120

sudo smartctl -l selftest /dev/sda

“`

Paso 6: Si la prueba corta pasa y los síntomas persisten, ejecutar una prueba larga durante una ventana de mantenimiento

“`bash

sudo smartctl -t long /dev/sda

“`

Paso 7: Revisar el registro de autoprueba para las direcciones LBA de fallo

“`bash

sudo smartctl -l selftest /dev/sda

“`

Las pruebas fallidas reportan el LBA del primer error encontrado. Esto localiza exactamente la ubicación del daño en el medio.

Errores comunes y casos extremos

Unidades conectadas por USB: smartctl a menudo no puede comunicarse con unidades conectadas a través de adaptadores USB-a-SATA porque el chip puente USB no reenvía comandos ATA. Use el indicador `-d sat` o `-d usb`, o especifique el tipo de puente explícitamente (p. ej., `-d usb,0x0bc2,0x2312`). El indicador `–scan` intentará identificar el tipo correcto automáticamente.

Entornos virtualizados: Dentro de un invitado KVM o VMware, `/dev/sda` es un disco virtual. smartctl puede devolver `Device does not support SMART` o datos fabricados pasados por el hipervisor. No confíe en la salida de smartctl dentro del invitado para la evaluación de la salud de la unidad física en infraestructura de hosting compartido.

Falsos positivos en Raw_Read_Error_Rate: Como se señaló anteriormente, la codificación de este atributo por parte de Seagate produce valores sin procesar alarmantes que son completamente normales. Verifique siempre con la documentación de atributos del fabricante antes de actuar sobre este valor.

Unidades detrás de RAID por software (mdadm): smartctl accede a las unidades componentes directamente (`/dev/sda`, `/dev/sdb`), no al dispositivo RAID (`/dev/md0`). Monitorice cada unidad miembro individualmente.

Espacio de nombres NVMe vs. controlador: Use `/dev/nvme0` (controlador) para datos de salud, no `/dev/nvme0n1` (espacio de nombres/dispositivo de bloque). Algunas versiones de smartctl aceptan ambos, pero el nodo del controlador es autoritativo para el acceso al registro de salud.

Unidades que mienten: Algunos SSDs de consumo, particularmente las unidades NAND QLC de gama baja, han sido documentados reportando atributos S.M.A.R.T. saludables hasta un fallo completo y repentino. S.M.A.R.T. es un indicador sólido pero no una garantía — no reemplaza las copias de seguridad regulares.

Despliegue de smartmontools en entornos de servidor

Para los administradores que gestionan múltiples servidores físicos — como los que ejecutan cargas de trabajo en Servidores Dedicados — centralizar la monitorización S.M.A.R.T. es esencial. Considere la siguiente arquitectura:

• Prometheus + node_exporter: El `node_exporter` incluye un script de recopilador de archivos de texto `smartmon` que exporta atributos S.M.A.R.T. como métricas de Prometheus. Esto permite alertas a través de Alertmanager y visualización en paneles de Grafana.
• Nagios / Icinga2: El plugin `check_smart` proporciona integración de monitorización S.M.A.R.T. para pilas de monitorización tradicionales.
• Scripts personalizados de smartd: La directiva `-M exec` en smartd.conf puede activar cualquier script en caso de alerta — útil para integrarse con PagerDuty, webhooks de Slack o sistemas de tickets personalizados.
• Agregación de archivos de registro: Configure smartd para escribir en syslog, luego reenvíe a un agregador de registros centralizado (pila ELK, Loki) para el análisis de tendencias históricas en toda una flota.

Para entornos de hosting web que utilizan paneles de control, los despliegues de VPS con cPanel se benefician de la monitorización S.M.A.R.T. a nivel de host configurada por el proveedor de infraestructura, ya que cPanel en sí no expone datos de salud de la unidad de forma nativa.

Lista de verificación de puntos clave

Úsela como referencia previa al despliegue y operacional continua:

• Instale smartmontools 7.x o posterior para garantizar soporte completo de NVMe y SSD moderno
• Ejecute `smartctl –scan` en hardware nuevo para identificar todas las unidades y sus indicadores de interfaz requeridos
• Verifique primero el veredicto de salud `-H` — un resultado `FAILED` requiere acción inmediata independientemente de otros atributos
• Trate cualquier Reallocated_Sector_Ct, Current_Pending_Sector o Uncorrectable_Sector_Count distinto de cero como una señal de fallo — no espere a que el recuento aumente
• No confíe únicamente en Raw_Read_Error_Rate — valide con la documentación del fabricante antes de generar alertas
• Programe pruebas largas automatizadas semanalmente a través de smartd en todas las unidades de producción; pruebas cortas diariamente
• Configure alertas de correo electrónico de smartd y verifique la entrega antes de confiar en ellas
• Para RAID por hardware, utilice siempre el indicador de paso directo apropiado — monitorizar el disco virtual no equivale a monitorizar las unidades físicas
• En entornos virtualizados, realice la monitorización S.M.A.R.T. a nivel del hipervisor/host, no dentro de las VMs invitadas
• Combine la monitorización S.M.A.R.T. con una estrategia de copia de seguridad — S.M.A.R.T. predice fallos, no previene la pérdida de datos
• Para unidades NVMe, monitorice Available Spare y Percentage Used además de los recuentos de errores
• En servidores con múltiples unidades, integre smartd con una plataforma de alertas centralizada en lugar de depender de la entrega de correo electrónico local

Preguntas frecuentes

¿Funciona smartctl dentro de un VPS o instancia en la nube?

En la mayoría de los entornos VPS, el hipervisor presenta un dispositivo de bloque virtual al invitado. smartctl dentro del invitado devolverá datos nulos o datos sintetizados por el hipervisor, que no reflejan la salud real de la unidad física. La monitorización S.M.A.R.T. significativa requiere acceso al host físico. Para visibilidad completa a nivel de unidad, un Servidor Dedicado es la solución apropiada.

¿Cuál es la diferencia entre `smartctl -a` y `smartctl -x`?

El indicador `-a` muestra el conjunto estándar de datos S.M.A.R.T.: información del dispositivo, veredicto de salud, indicadores de capacidad, todos los atributos, registro de errores y registro de autoprueba. El indicador `-x` muestra todo lo que proporciona `-a` más páginas de registro adicionales que incluyen el registro de autoprueba selectiva, el registro de estadísticas del dispositivo, el registro de defectos pendientes y las estadísticas del dispositivo ATA — proporcionando una imagen más completa del historial de la unidad. Use `-x` para diagnósticos exhaustivos; `-a` para verificaciones rutinarias.

¿Cuánto tiempo tarda una autoprueba larga y es seguro ejecutarla en una unidad de producción?

La duración depende de la capacidad y velocidad de la unidad: aproximadamente 1 hora por terabyte para un HDD de 7200 RPM, y 20–60 minutos para la mayoría de los SSDs. La prueba se ejecuta en segundo plano en el firmware de la unidad, y la unidad continúa sirviendo E/S durante la prueba. El impacto en el rendimiento es típicamente menor (reducción del rendimiento del 5–15%). Es seguro ejecutarla en sistemas de producción durante períodos de bajo tráfico, pero se recomienda programarla durante una ventana de mantenimiento para cargas de trabajo sensibles a la latencia.

¿Qué significa cuando Current_Pending_Sector es distinto de cero pero Reallocated_Sector_Ct no ha aumentado?

La unidad ha identificado sectores que producen errores de lectura pero aún no los ha reasignado con éxito. La reasignación ocurre cuando la unidad puede escribir en el sector — ya sea a través de una operación de escritura o un análisis sin conexión. Si el recuento permanece estático, los sectores pueden estar en una región de solo lectura o la unidad puede carecer de sectores de repuesto disponibles para la reasignación. Un recuento de Current_Pending_Sector distinto de cero y en aumento, con Reallocated_Sector_Ct permaneciendo plano, a menudo indica que la unidad ha agotado su grupo de sectores de repuesto — una condición de fallo crítico.

¿Puede smartctl detectar el desgaste de un SSD antes de que falle la unidad?

Sí, para los SSDs SATA, los atributos Wear_Leveling_Count (ID 177), Media_Wearout_Indicator (ID 233) y Available_Reservd_Space (ID 232) rastrean el consumo de resistencia de la NAND. Para los SSDs NVMe, los campos Percentage Used y Available Spare en el NVMe Health Information Log sirven el mismo propósito. Cuando Available Spare cae por debajo de su umbral o Percentage Used alcanza el 100%, la unidad ha consumido su resistencia de escritura nominal. A diferencia de los fallos mecánicos repentinos, la degradación por desgaste de los SSDs es gradual y altamente predecible — lo que la convierte en uno de los casos de uso más sólidos para la monitorización proactiva de S.M.A.R.T.