Configuración y uso de Smartmontools

Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: https://www.alcancelibre.org

Licencia Creative Commons
© 1999-2026 Joel Barrios Dueñas. Este manual se distribuye bajo la licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0). Usted es libre de compartir y adaptar el material bajo los siguientes términos: debe dar crédito al autor, no puede utilizarlo para fines comerciales y debe compartir las obras derivadas bajo la misma licencia. La licencia completa está disponible en https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.es.

Introducción

Smartmontools constituye un conjunto de herramientas diseñado para supervisar la salud de las unidades de almacenamiento mediante la ejecución de pruebas que verifican su correcto funcionamiento. Su eficacia depende de que tanto la unidad como la tarjeta madre soporten la tecnología SMART (Self-Monitoring, Analysis and Reporting Technology o Tecnología de Auto-supervisión, Análisis e Informes), lo que permite anticipar posibles fallas. La implementación básica implica simplemente iniciar un servicio, mientras que la personalización se logra editando un archivo de configuración. Su funcionamiento predeterminado resulta adecuado para la mayoría de los escenarios.

El componente principal es smartd, un servicio (daemon) que supervisa en segundo plano la funcionalidad SMART integrada en la mayoría de los discos duros ATA/SATA, unidades de estado sólido (SSD) y dispositivos SCSI/SAS y NVMe. Su labor consiste en verificar la fiabilidad del soporte físico, predecir fallos inminentes y ejecutar diversos tipos de pruebas internas.

De manera predeterminada, el servicio smartd intenta supervisar los dispositivos ATA y SCSI cada 30 minutos. Registra cualquier error o cambio en los atributos SMART a través de la interfaz SYSLOG ―generalmente en /var/log/messages para sistemas derivados de Fedora y RHEL― y puede configurarse para enviar alertas por correo electrónico ante la detección de problemas.

⚠️ Nota de importancia crítica: Aunque SMART es una tecnología valiosa, es imposible predecir todos los fallos con precisión absoluta. Un informe de estado saludable (PASSED) dista de ser garantía de la imposibilidad de una falla súbita. Por el contrario, un informe de fallo (FAILED) o tasas de error anormales sirven como indicadores contundentes de un problema de sustento físico o inconsistencia de datos inminente. Los procedimientos siempre deben complementarse con copias de seguridad periódicas y robustas, comprobando periódicamente su integridad y capacidad de restauración.

Sitio oficial del proyecto: https://www.smartmontools.org

Equipamiento lógico necesario

La mayoría de las distribuciones recientes incluyen el paquete smartmontools en sus almacenes de software predeterminados. Sin embargo, es frecuente su ausencia en la instalación de esquemas minimalistas (ejemplo: AlmaLinux 8/9/10 Minimal).

Instalación en AlmaLinux, Rocky Linux y Red Hat™ Enterprise Linux (DNF)

Ejecute el siguiente mandato para instalar el paquete:

dnf -y install smartmontools

Instalación en ALDOS (YUM)

Ejecute el siguiente mandato para instalar el paquete:

yum -y install smartmontools

Activar, iniciar, reiniciar o detener el servicio smartd

A continuación se detallan los procedimientos para controlar el servicio smartd en sistemas con SystemD y SysVinit.

En AlmaLinux, Rocky Linux y Red Hat™ Enterprise Linux (SystemD)

Para activar el servicio en todos los niveles de operación e iniciarlo inmediatamente:

systemctl enable --now smartd

Para reiniciar el servicio y aplicar cambios en la configuración:

systemctl restart smartd

Para detener el servicio (sólo si es estrictamente necesario):

systemctl stop smartd

En ALDOS (SysVinit)

Para activar el servicio en todos los niveles de ejecución:

chkconfig smartd on

Para iniciar el servicio:

service smartd start

Para reiniciar el servicio y aplicar cambios en la configuración:

service smartd restart

Para detener el servicio (sólo si es estrictamente necesario):

service smartd stop

Configuración del servicio smartd

⚠️ Advertencia: Los procedimientos descritos en este documento requieren unidades de almacenamiento reales, por lo que su aplicación en máquinas virtuales carece de utilidad.

La configuración del servicio smartd se gestiona a través del archivo /etc/smartd.conf. Comience editando éste:

vim /etc/smartd.conf

Al inicio del archivo encontrará un contenido similar al siguiente:

# Sample configuration file for smartd.  See man smartd.conf.
# Home page is: https://www.smartmontools.org
...
# The word DEVICESCAN will cause any remaining lines in this
# configuration file to be ignored: it tells smartd to scan for all
# ATA and SCSI devices.  DEVICESCAN may be followed by any of the
# Directives listed below, which will be applied to all devices that
# are found.  Most users should comment out DEVICESCAN and explicitly
# list the devices that they wish to monitor.
DEVICESCAN -H -m root

La directiva DEVICESCAN ordena a smartd buscar y supervisar automáticamente todos los dispositivos ATA y SCSI del sistema, ignorando cualquier otra configuración posterior en el archivo. Para personalizar la supervisión, debe comentar (deshabilitar) esta línea anteponiendo una almohadilla (#) y añadir configuraciones explícitas para cada dispositivo.

Opciones de configuración comunes

Ejemplos prácticos de configuración

Ejemplo 1: Supervisar el estado de salud (-H), el registro de errores y el registro de auto-pruebas de /dev/sda y /dev/sdb, realizando seguimiento de cambios en todos los atributos excepto en la temperatura (ID 194).

# DEVICESCAN -H -m root
/dev/sda -H -l error -l selftest -t -I 194
/dev/sdb -H -l error -l selftest -t -I 194

Ejemplo 2: Supervisión exhaustiva con control de temperatura y alertas por correo. Se supervisan todos los atributos (-a) excepto el 194, se reportan cambios de temperatura ≥4°C y se envían advertencias y fallos a los 45°C y 55°C respectivamente.

# DEVICESCAN -H -m root
/dev/sda -a -I 194 -W 4,45,55 -m root@ejemplo.com
/dev/sdb -a -I 194 -W 4,45,55 -m root@ejemplo.com

Ejemplo 3 (Avanzado): Configuración para un servidor. Se deshabilita DEVICESCAN y se configura un dispositivo específico para que realice una prueba corta todos los viernes a las 11 a.m., una prueba larga los viernes a la 1 p.m. y una prueba de transporte los viernes a las 3 p.m. (-s). Ante cualquier error, se ejecuta un guion de instrucciones de respuesta.

# DEVICESCAN -H -m root
/dev/sda -H -l error -l selftest -f -s (O/../../5/11|L/../../5/13|C/../../5/15) -m root@dominio.com -M exec /ruta/al/guion.sh

Después de modificar /etc/smartd.conf, debe reiniciar el servicio para que los cambios surtan efecto. El servicio se encargará entonces de ejecutar las pruebas programadas en segundo plano y enviar los reportes correspondientes.

Procedimientos manuales con smartctl

El mandato smartctl permite interactuar directamente con las unidades para obtener información y ejecutar pruebas bajo demanda.

Obtención de información básica y verificación de soporte SMART

Para verificar si una unidad es compatible con SMART y ver su información básica (modelo, serial, programación en firme), utilice:

smartctl -i /dev/sda

La salida debe incluir líneas que confirmen el soporte:

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Si el soporte está deshabilitado (Unavailable), puede activarlo con:

smartctl -s on /dev/sda

Para conocer las capacidades de prueba soportadas y el tiempo estimado de cada una:

smartctl -c /dev/sda

Estado de salud y reportes detallados

Para obtener un veredicto inmediato sobre la salud de la unidad:

smartctl -H /dev/sda

Una salida saludable se ve así:

smartctl 7.5 2025-04-30 r5714 [x86_64-linux-5.10.246-40.aldos.x86_64] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Para generar un reporte instantáneo, completo y detallado de todos los datos SMART, utilice el mandato -a. Dado que la salida es extensa, se recomienda canalizarla a un paginador como less:

smartctl -a /dev/sda | less

Ejecución de pruebas manuales

Puede ejecutar tres tipos principales de pruebas:

  1. Prueba corta (Short) – Verificación rápida (2-5 minutos) de componentes eléctricos, mecánicos y de lectura en un sector limitado del disco.

    smartctl --test=short /dev/sda

  2. Prueba larga (Extended/Long) – Verificación exhaustiva que escanea toda la superficie del disco. Puede durar varias horas, dependiendo de la capacidad.

    smartctl --test=long /dev/sda

  3. Prueba de transporte (Conveyance) – Diseñada para detectar daños causados durante el transporte del dispositivo.

    smartctl --test=conveyance /dev/sda

Tras iniciar cualquier prueba, smartctl mostrará un mensaje indicando que la prueba ha comenzado y un estimado de su tiempo de finalización. Los resultados estarán disponibles una vez finalizada la prueba. Ejemplo de la salida:

smartctl 7.5 2025-04-30 r5714 [x86_64-linux-5.10.246-40.aldos.x86_64] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.
Test will complete after Tue Dec 30 09:30:18 2025 CST
Use smartctl -X to abort test.

Consulta de resultados y registros

Para consultar los resultados de las auto-pruebas ejecutadas:

smartctl -l selftest /dev/sda

Para revisar el registro de errores de la unidad:

smartctl -l error /dev/sda

Para abortar una prueba en progreso:

smartctl -X /dev/sda

Interpretación básica de atributos clave

El reporte detallado (smartctl -a) incluye una tabla de atributos SMART. Dos de los más críticos para el diagnóstico son:

🔍 Nota pedagógica: La reasignación de sectores es una función automática de la programación en firme (firmware), pero sólo ocurre al intentar escribir en un sector defectuoso. Una unidad de almacenamiento con sectores pendientes puede parecer "recuperarse" si una sobreescritura fuerza la reasignación exitosa.

Nota sobre tipos de dispositivo y solución de problemas

En sistemas modernos, smartctl suele detectar automáticamente el tipo de dispositivo (-d auto). Si un mandato falla con un error de tipo de dispositivo ambiguo o incorrecto, debe especificarlo manualmente. Algunos tipos comunes son:

Por ejemplo:

smartctl -a -d sat /dev/sdb

Bibliografía