Como Diagnosticar Discos com SMART e Bad Sectors em 2026?

✎ Duarte Spínola  |  13 de Julho de 2026

O sistema SMART (Self-Monitoring, Analysis and Reporting Technology) existe há mais de duas décadas, mas continua a ser subutilizado: a maioria dos administradores só verifica o estado dos discos quando uma falha já ocorreu. Em 2026, com discos NVMe Gen5, SSDs de alta densidade e arrays RAID em ambientes de produção, o diagnóstico proactivo não é opcional — é a diferença entre uma janela de manutenção planeada e uma perda de dados às 3 da manhã. Este artigo cobre os atributos SMART críticos para HDDs SATA, SSDs e NVMe, o uso de smartmontools/smartctl no Linux, CrystalDiskInfo no Windows, ferramentas como badblocks e dd_rescue para recuperação de sectores, detecção de degradação em mdadm e ZFS, indicadores de wear leveling em SSDs, monitorização contínua com Nagios/Zabbix/Checkmk e scripts para automatizar a verificação SMART. Tudo em português de Portugal, sem rodeios, com comandos práticos prontos a executar.

1. O que é o SMART e como funciona em 2026

O SMART é um sistema de monitorização integrado no firmware do disco que regista e reporta atributos de saúde — temperatura, sectores realocados, horas de utilização, erros de leitura/escrita, entre dezenas de outros. O padrão original (SMART ATA, definido na especificação S.M.A.R.T. da smartmontools) evoluiu, mas o princípio mantém-se: cada atributo tem um valor normalizado (RAW_VALUE), um valor actual (VALUE), um pior valor registado (WORST) e um limite de falha (THRESH). Quando o VALUE cai abaixo do THRESH, o disco sinaliza falha iminente.

Em 2026, existem três ecossistemas SMART distintos:

Tecnologia Protocolo Estrutura SMART Ferramenta principal
HDD SATA ATA/SATA Atributos ID 1-254 com RAW_VALUE smartctl -a /dev/sdX
SSD SATA ATA/SATA Atributos ID 1-254 + atributos específicos SSD smartctl -a /dev/sdX
NVMe NVMe (PCIe) Log pages SMART (sem IDs de atributos) smartctl -a /dev/nvmeXnY

O ponto crítico: SMART não prevê todas as falhas. Estudos históricos (documentação smartmontools, man page smartctl) indicam que 30-40% das falhas de disco ocorrem sem qualquer aviso prévio do SMART. O SMART é um indicador necessário, mas não suficiente — deve ser complementado com verificação de bad sectors, monitorização de RAID/ZFS e backups funcionais.

2. Atributos SMART críticos para discos SATA/HDD

Nem todos os mais de 50 atributos SMART têm significado prático. Para diagnóstico de discos mecânicos SATA, os seguintes são os que realmente importam:

ID Nome Interpretação Acção recomendada
5 Reallocated Sector Count Sectores remapeados para área de reserva. RAW > 0 indica desgaste físico. Monitorizar tendência; substituir se crescer rapidamente
9 Power-On Hours Horas totais de utilização. Indica idade do disco. Comparar com MTBF do fabricante
12 Power Cycle Count Número de ciclos ligar/desligar. Referência contextual
187 Reported Uncorrectable Errors Erros de leitura não corrigíveis reportados. Investigar com badblocks; considerar substituição
188 Command Timeout Timeout de comandos. Pode indicar cabo SATA defeituoso. Verificar cabos antes de condenar o disco
194 Temperature Celsius Temperatura actual em °C. Investigar se > 50°C (refrigeração)
197 Current Pending Sector Count Sectores pendentes de realocação — não lêem correctamente mas ainda não foram remapeados. Crítico: executar badblocks ou dd_rescue; risco de perda de dados
198 Offline Uncorrectable Sectores que não podem ser corrigidos offline. Mais grave que 197. Substituir disco iminentemente
199 UDMA CRC Error Count Erros CRC na interface. Indica problema de cabo, não de disco. Substituir cabo SATA
200 Write Error Rate Taxa de erros de escrita (alguns fabricantes). Monitorizar tendência

Os três atributos que ditam substituição imediata

Reallocated Sector Count (ID 5): quando o firmware encontra um sector que não consegue ler ou escrever, remapeia-o para uma área de reserva. Cada realocação reduz a capacidade de reserva. Se o RAW_VALUE for diferente de zero, o disco já tem sectores físicos danificados. Uma tendência crescente (novos realocados em semanas ou dias) indica falha mecânica em curso.

Current Pending Sector Count (ID 197): sectores que falharam na leitura mas ainda não foram realocados. Isto é diferente do ID 5 — o disco ainda não decidiu remapear porque pode conseguir ler os dados numa tentativa posterior. Se uma escrita for bem-sucedida nesse sector, ele deixa de ser pendente. Se falhar novamente, torna-se realocação (ID 5). Um valor > 0 não é necessariamente fatal, mas exige verificação com badblocks ou leitura completa do disco.

Offline Uncorrectable (ID 198): sectores onde o scan offline do SMART detectou erros irrecuperáveis. Estes são os mais graves — o disco tentou corrigir e não conseguiu. Se o valor for diferente de zero, o disco deve ser substituído o mais rapidamente possível, idealmente antes do próximo reboot.

3. Atributos NVMe SMART — diferenças e métricas específicas

Os discos NVMe não usam o sistema de atributos ID 1-254 do ATA. Em vez disso, usam log pages SMART com métricas normalizadas pela especificação NVMe. As ferramentas como smartctl já suportam leitura destes log pages, mas a interpretação é diferente:

Métrica NVMe Descrição Acção recomendada
Critical Warning Flags de aviso (bitmask): spare baixo, temperatura alta, fiabilidade degradada, modo só de leitura. Se diferente de 0, investigar imediatamente
Composite Temperature Temperatura composta (pode incluir sensor interno). Investigar se > 70°C
Available Spare Percentagem de blocos de reserva disponíveis. Se < threshold (normalmente 10%), plano substituição
Available Spare Threshold Limite mínimo de reserva que acciona aviso. Referência do fabricante
Percentage Used Percentagem de vida útil usada (0-100%). A 100% o disco atingiu endurance nominal; substituir
Data Units Written Dados escritos em unidades de 512000 bytes. Comparar com TBW nominal do SSD
Power On Hours Horas totais ligado. Contextual
Power Cycles Ciclos ligar/desligar. Contextual
Media Errors Erros de media não corrigíveis. Se > 0, avaliar substituição
Unsafe Shutdowns Encerramentos sem comando shutdown correcto. Investigar fonte de alimentação/UPS

Diferenças práticas HDD vs NVMe

# HDD SATA — atributos individuais com IDs
sudo smartctl -A /dev/sda | grep -E “^( 5|197|198|199)”

# NVMe — log page SMART completo
sudo smartctl -a /dev/nvme0n1

O comando NVMe não precisa de -A porque o SMART é um log page único, não uma lista de atributos separados. A métrica mais importante em NVMe é Percentage Used — um valor de 80% significa que o SSD já consumiu 80% da sua endurance nominal (definida em TBW — Terabytes Written). Diferente dos HDDs onde Reallocated Sector Count é o indicador principal, em NVMe a vida útil é predominantemente função de escrita acumulada, não de sectores físicos danificados.

4. smartmontools e smartctl no Linux — instalação e comandos práticos

O smartmontools é o pacote standard para diagnóstico SMART em Linux e inclui duas ferramentas: smartctl (execução manual) e smartd (daemon de monitorização contínua). A instalação varia por distribuição:

# Debian/Ubuntu
sudo apt install smartmontools

# RHEL/Rocky/Alma/Fedora
sudo dnf install smartmontools

# Arch/Manjaro
sudo pacman -S smartmontools

# openSUSE
sudo zypper install smartmontools

Comandos essenciais

# Listar todos os discos detectados pelo smartctl
sudo smartctl –scan

# Visão geral completa do disco (informações + SMART + atributos)
sudo smartctl -a /dev/sda

# Apenas atributos SMART (tabela com VALUE/WORST/THRESH/RAW)
sudo smartctl -A /dev/sda

# Apenas estado de saúde (PASS/FAIL)
sudo smartctl -H /dev/sda

# Verificar erros registados no log de erros SMART
sudo smartctl -l error /dev/sda

# Verificar testes SMART self-test executados e resultados
sudo smartctl -l selftest /dev/sda

# Iniciar teste curto (~2 minutos, não destrutivo)
sudo smartctl -t short /dev/sda

# Iniciar teste longo (pode levar várias horas, não destrutivo)
sudo smartctl -t long /dev/sda

# Verificar progresso de teste em execução
sudo smartctl -a /dev/sda | grep -A5 “Self-test execution status”

# Para NVMe
sudo smartctl -a /dev/nvme0n1
sudo smartctl -H /dev/nvme0n1

Configurar smartd para monitorização automática

O smartd lê SMART periodicamente e regista alertas no syslog. A configuração está em /etc/smartd.conf (Debian/Ubuntu) ou /etc/smartmontools/smartd.conf:

# Monitorizar todos os discos, alertar por email em falha, executar teste curto diário e teste longo semanal
DEVICESCAN -d auto -m [email protected] -s (S/../.././01|L/../../6/03) -M test

A linha acima escaneia automaticamente todos os discos, envia email para [email protected] se detectar degradação, executa teste curto todos os dias às 01h00 e teste longo aos sábados às 03h00. O -M test envia um email de teste ao iniciar para confirmar que o envio funciona. Em Debian/Ubuntu, activar o daemon:

sudo systemctl enable –now smartmontools

Para mais detalhes sobre a sintaxe de agendamento (-s), consultar a man page do smartd.

5. CrystalDiskInfo no Windows — diagnóstico gráfico

Em ambientes Windows, CrystalDiskInfo é a ferramenta de referência para leitura de SMART. Lê os mesmos atributos que smartctl, mas apresenta-os numa interface gráfica com código de cores:

  • Azul (Bom): todos os atributos estão dentro dos limites.
  • Amarelo (Atenção): um ou mais atributos indicam desgaste (ex: Reallocated Sector Count > 0, ou SSD Percentage Used > 90%).
  • Vermelho (Mau): um atributo crítico ultrapassou o limite de falha (THRESH).

Configuração recomendada para sysadmins

  1. Descarregar CrystalDiskInfo (versão Shizuku ou Standard) de crystalmark.info/downloads.
  2. No menu “Function”, activar “Auto Refresh” e definir intervalo (ex: 5 minutos).
  3. Em “Alert Options”, configurar alerta por email se um disco passar a estado “Caution” ou “Bad”.
  4. Em “Startup”, activar “Resident” para iniciar com o Windows.
  5. Para discos NVMe, o CrystalDiskInfo 9.x suporta leitura nativa de log pages SMART NVMe — confirmar que a versão instalada é 9.0 ou superior.

CrystalDiskInfo vs smartctl — quando usar cada um

Critério CrystalDiskInfo smartctl
Plataforma Windows Linux (também existe porta Windows)
Interface GUI, código de cores CLI, output tabular
Alertas automáticas Sim (email, pop-up) Via smartd (email/syslog)
NVMe suporte Versão 9.x+ Nativo desde smartmontools 6.5+
Scripts de automação Limitado (CLI mode existe mas limitado) Total (bash, cron, Nagios)
Custo Gratuito (Shizuku) / Opensource Gratuito (GPL)

Em ambientes mistos Windows/Linux, a combinação CrystalDiskInfo (estações Windows) + smartd (servidores Linux) é o padrão recomendado.

6. Badblocks e dd_rescue — detecção e recuperação de sectores

Quando o SMART reporta Current Pending Sector Count (ID 197) ou Offline Uncorrectable (ID 198) diferente de zero, é necessário verificar fisicamente o disco para localizar e isolar os sectores danificados.

badblocks — detecção de sectores danificados

O badblocks faz parte do e2fsprogs e procura sectores defeituosos. Existem dois modos principais:

# Modo não destrutivo (read-only) — segura, não altera dados
sudo badblocks -sv -b 4096 -c 128 /dev/sda

# Modo de escrita (DESTRUTIVO — apaga todos os dados)
# USAR APENAS EM DISCOS NOVOS OU APÓS BACKUP COMPLETO
sudo badblocks -wsv -b 4096 /dev/sda

# Modo read-write não destrutivo (requer filesystem desmontado)
# Escreve padrão, lê, compara — detecta sectores inconsistentes
sudo badblocks -nsv -b 4096 /dev/sda

Para discos em produção com filesystems ext4/xfs, a abordagem mais segura é executar badblocks read-only e depois usar e2fsck para marcar os blocos como bad:

# Verificar e marcar bad blocks no filesystem ext4 (disco desmontado)
sudo e2fsck -cc /dev/sda1

O -cc executa badblocks em modo read-only e marca os blocos encontrados como bad no bitmap do filesystem, evitando que sejam usados. Para xfs, usar xfs_repair com opções de verificação.

dd_rescue / ddrescue — recuperação de dados de discos com falhas

Quando um disco tem sectores danificados e é necessário recuperar dados antes de o retirar de serviço, o GNU ddrescue (não confundir com dd_rescue antigo) é a ferramenta de eleição. Copia dados de um disco com falhas para outro, saltando blocos com erros e voltando depois para tentar recuperar o máximo possível:

# Instalar GNU ddrescue
sudo apt install gddrescue # Debian/Ubuntu
sudo dnf install ddrescue # Fedora/RHEL

# Copiar disco com falhas para ficheiro imagem (primeira passagem rápida)
sudo ddrescue -n /dev/sda /mnt/backup/sda.img /mnt/backup/sda.map

# Segunda passagem — tentar recuperar blocos que falharam na primeira
sudo ddrescue -d -r3 /dev/sda /mnt/backup/sda.img /mnt/backup/sda.map

# Copiar directamente para disco novo (mesma capacidade ou maior)
sudo ddrescue -n /dev/sda /dev/sdb /mnt/backup/sdb.map

O ficheiro .map (mapfile) é essencial — regista que blocos foram copiados com sucesso, quais falharam e onde retomar. Nunca executar ddrescue sem mapfile. A primeira passagem (-n) copia rapidamente saltando erros; a segunda (-d -r3) usa acesso directo ao disco e tenta cada bloco falhado até 3 vezes.

Quando usar cada ferramenta

Cenário Ferramenta Justificação
Disco novo, verificar antes de colocar em produção badblocks -wsv Teste destrutivo aceitável em disco vazio
Disco em produção, ID 197 > 0 badblocks -sv (read-only) + e2fsck -cc Marcar bad blocks sem perder dados
Disco com falha, recuperar dados ddrescue -n + ddrescue -r3 Recuperar máximo antes de retirar disco
Disco com ID 198 > 0 Substituir disco, usar ddrescue para backup Risco de falha iminente

7. Degradação de RAID com mdadm e ZFS pool — detecção e resposta

mdadm — RAID software Linux

Quando um disco falha num array mdadm, o array degrada (passa de “clean” para “degraded”). A detecção rápida é essencial porque um array degradado não tem tolerância a falhas — uma segunda falha causa perda de dados.

# Verificar estado de todos os arrays
sudo mdadm –detail –scan

# Verificar estado de um array específico
sudo mdadm –detail /dev/md0

# Verificar se há discos com falha no array
cat /proc/mdstat

# Exemplo de output degradado:
# md0 : active raid1 sda1[0] sdb1[1](F)
# 2095360 blocks super 1.2 [2/1] [U_]
# O [U_] indica que o segundo disco falhou (underscore = falha, U = activo)

# Marcar disco como faulty e remover do array
sudo mdadm –fail /dev/md0 /dev/sdb1
sudo mdadm –remove /dev/md0 /dev/sdb1

# Adicionar disco novo ao array (rebuild inicia automaticamente)
sudo mdadm –add /dev/md0 /dev/sdc1

# Monitorizar progresso do rebuild
cat /proc/mdstat
# Ou, com detalhe:
sudo mdadm –detail /dev/md0 | grep -i rebuild

# Verificar tempo estimado de rebuild
sudo mdadm –detail /dev/md0 | grep -i “rebuild\|finish”

Importante: verificar SMART dos discos restantes

Após uma falha de disco, verificar o SMART de TODOS os discos restantes do array. Falhas correlacionadas (discos do mesmo lote, mesma idade, mesma temperatura) são comuns:

# Verificar SMART de todos os discos do array
for dev in /dev/sda /dev/sdb /dev/sdc; do
echo “=== $dev ===”
sudo smartctl -H $dev
sudo smartctl -A $dev | grep -E “^ 5|^197|^198|^199”
done

ZFS pool — degradação e diagnóstico

O ZFS tem uma vantagem sobre o mdadm: detecta silenciosamente corrupção de dados através de checksums. Um pool degradado é visível com zpool status:

# Estado geral do pool
sudo zpool status

# Estado detalhado com eventos recentes
sudo zpool status -v
sudo zpool events

# Exemplo de output degradado:
# pool: tank
# state: DEGRADED
# status: One or more devices has been removed by the administrator.
# action: Attach the missing device or replace it.
# scan: resilver requested, but not started
# config:
# tank DEGRADED
# mirror-0 DEGRADED
# sda1 ONLINE
# sdb1 UNAVAIL (was removed)

Substituir disco em pool ZFS

# Verificar identificação do disco falhado
sudo zpool status

# Offline o disco (se ainda estiver parcialmente acessível)
sudo zpool offline tank sdb1

# Substituir fisicamente o disco e identificar o novo dispositivo
lsblk

# Substituir no pool
sudo zpool replace tank sdb1 /dev/sdc1

# Ou, se o disco novo já está no mesmo slot (mesmo nome):
sudo zpool replace tank sdb1

# Monitorizar resilver
sudo zpool status tank

# Verificar erros de leitura/escrita no pool
sudo zpool status -v tank | grep -E “errors|CKSUM”

Scrub periódico em ZFS

O scrub é a verificação activa de todos os blocos do pool — lê todos os dados e compara com checksums. Em 2026, a recomendação é executar scrub mensalmente em pools de produção:

# Iniciar scrub manual
sudo zpool scrub tank

# Verificar progresso
sudo zpool status tank

# Verificar histórico de scrubs
sudo zpool history tank | grep scrub

Comparação mdadm vs ZFS para diagnóstico

Critério mdadm ZFS
Detecção de corrupção silenciosa Não (bit rot não detectado) Sim (checksum em todos os blocos)
Notificação de degradação mdadm –monitor (email) zpool events + zfs events
Reparação automática Apenas reconstrói paridade Resilver + auto-repair com checksums
Verificação activa badblocks manual zpool scrub (automático)
Comando de estado cat /proc/mdstat zpool status
Substituir disco mdadm –remove + –add zpool replace

8. SSD Wear Leveling e quando substituir um disco

Os SSDs não têm sectores físicos no sentido tradicional — usam células NAND flash que se desgastam com ciclos de escrita/apagação. O wear leveling distribui as escritas por todas as células para evitar desgaste desigual. Os atributos SMART específicos de SSDs que indicam desgaste:

Atributos SMART específicos de SSDs SATA

ID Nome Interpretação
5 Reallocated Sector Count Blocos reformados (bad blocks substituídos por reserves)
177 Wear Leveling Count Contador de ciclos de wear leveling (alguns fabricantes)
179 Used Reserved Block Count Blocos de reserva já consumidos
180 Unused Reserved Block Count Blocos de reserva ainda disponíveis
231 SSD Life Left Percentagem de vida útil restante (Samsung)
233 Media Wearout Indicator Indicador de desgaste (Intel/Samsung)
241 Total LBAs Written Total de sectores lógicos escritos
242 Total LBAs Read Total de sectores lógicos lidos

NVMe — Percentage Used é o indicador principal

Em NVMe, a métrica Percentage Used (do log page SMART) é a mais directa: representa a percentagem de endurance nominal já consumida. Um valor de 100% não significa que o disco vai falhar imediatamente, mas que atingiu o limite de garantia do fabricante (TBW nominal).

# Verificar Percentage Used em NVMe
sudo smartctl -a /dev/nvme0n1 | grep -i “percentage used”

Critérios para substituir um disco — quando age

Sinal Ferramenta Quando substituir
Reallocated Sector Count (ID 5) > 0 e a crescer smartctl -A Substituir quando RAW exceder threshold do fabricante ou crescer > 10% por semana
Current Pending Sector (ID 197) > 0 smartctl -A + badblocks Após badblocks não resolver, substituir
Offline Uncorrectable (ID 198) > 0 smartctl -A Substituir imediatamente
SSD Percentage Used > 80% smartctl -a (NVMe) Planear substituição; > 95% substituir
SSD Wear Leveling Count alto smartctl -A Verificar documentação do fabricante para threshold
mdadm array degradado sem causa óbvia mdadm –detail + smartctl Verificar SMART de todos os discos; substituir o com problema
ZFS pool com erros CKSUM crescentes zpool status -v Investigar disco; substituir se erros persistirem após scrub
Temperatura > 55°C consistente smartctl -A (ID 194) Melhorar refrigeração; se persistir, verificar se disco está em falha
Discos com > 5 anos (HDD) ou > endurance TBW (SSD) smartctl -a + datasheet Substituir proactivamente em ambientes críticos

Calculadora prática de TBW

A endurance nominal de um SSD é expressa em TBW (Terabytes Written). Por exemplo, um Samsung 990 Pro 1TB tem ~600 TBW. Para estimar vida útil:

# Total LBAs Written (ID 241) em sectores de 512 bytes
sudo smartctl -A /dev/sda | awk ‘/^241/ {print $10 * 512 / 1024^4 ” TB escritos”}’

Se um SSD com 600 TBW já tem 500 TB escritos (83%), está perto do fim da vida nominal. Em NVMe, o Percentage Used já incorpora esta relação automaticamente.

9. Monitorização com Nagios, Zabbix e Checkmk + scripts de automação SMART

A verificação manual de SMART é insuficiente em ambientes com múltiplos servidores. A monitorização contínua garante que alertas são gerados antes que a falha se torne crítica.

Nagios — plugin check_smart

O check_smart é o plugin standard para integração de smartctl com Nagios:

# Instalar o plugin
wget https://raw.githubusercontent.com/NagiosEnterprises/nagios-plugins/master/plugins/check_smart
sudo cp check_smart /usr/local/nagios/libexec/
sudo chmod +x /usr/local/nagios/libexec/check_smart

# Testar manualmente
sudo /usr/local/nagios/libexec/check_smart -d /dev/sda -i ata

# Output exemplo:
# SMART OK – 197 Current_Pending_Sector = 0, 198 Offline_Uncorrectable = 0, 5 Reallocated_Sector_Ct = 0

Configuração no Nagios (commands.cfg):

define command {
command_name check_smart
command_line $USER1$/check_smart -d $ARG1$ -i $ARG2$
}

Configuração no host (host.cfg):

define service {
use generic-service
host_name servidor-prod
service_description SMART /dev/sda
check_command check_smart!/dev/sda!ata
}

Zabbix — template SMART via smartctl

O Zabbix não tem um template nativo para SMART, mas a abordagem standard usa descoberta de discos (LLD) com user parameters:

# Configuração em /etc/zabbix/zabbix_agentd.conf.d/smart.conf
UserParameter=smart.discovery[*],sudo smartctl –scan | awk ‘NR>0 {print “{#DISK}:”$1}’ | jq .
UserParameter=smart.health[*],sudo smartctl -H $1 | grep -i “result” | awk ‘{print $$NF}’
UserParameter=smart.attr[*],sudo smartctl -A $1 | awk ‘/^ $2/ {print $$10}’

Para que o Zabbix consiga executar smartctl com sudo, adicionar ao sudoers:

echo “zabbix ALL=(root) NOPASSWD: /usr/sbin/smartctl” | sudo tee /etc/sudoers.d/zabbix-smart

Configurar a descoberta de discos e itens (triggers) no template Zabbix para alertar quando:

  • smart.health[/dev/sda] != “PASSED”
  • smart.attr[/dev/sda,5] > 0 (Reallocated Sector Count)
  • smart.attr[/dev/sda,197] > 0 (Current Pending Sector)
  • smart.attr[/dev/sda,198] > 0 (Offline Uncorrectable)

Checkmk — plugin nativo de SMART

O Checkmk tem um plugin de SMART que monitoriza automaticamente os discos detectados. Para activar:

  1. No Checkmk, ir a Setup > Services > Service monitoring > Host service rules.
  2. Adicionar regra “SMART monitoring”.
  3. Seleccionar discos a monitorizar (ou “all” para auto-descoberta).
  4. Configurar níveis de alerta para atributos críticos (ID 5, 197, 198).

O Checkmk também monitoriza mdadm automaticamente se o agente Linux estiver instalado. Os arrays em estado “degraded” accionam automaticamente um alerta WARN.

Script de verificação SMART para cron ou execução ad-hoc

O seguinte script Bash verifica todos os discos do sistema e reporta atributos críticos. Pode ser executado manualmente ou via cron:

#!/bin/bash
# smart_check.sh — Verificação SMART automatizada
# Verifica todos os discos detectados e reporta atributos críticos
# Uso: sudo ./smart_check.sh [–alert] [–email [email protected]]

ALERT_EMAIL=””
SEND_ALERT=false

while [[ $# -gt 0 ]]; do
case $1 in
–alert) SEND_ALERT=true; shift ;;
–email) ALERT_EMAIL=”$2″; shift 2 ;;
*) shift ;;
esac
done

# Atributos críticos a verificar (ID:Nome:Threshold)
CRITICAL_ATTRS=(
“5:Reallocated_Sector_Ct:0”
“197:Current_Pending_Sector:0”
“198:Offline_Uncorrectable:0”
“199:UDMA_CRC_Error_Count:0”
)

# Discos NVMe — métricas diferentes
NVME_CRITICALS=(“Media_and_Data_Integrity_Errors:0” “Available_Spare:10″)

REPORT=””
PROBLEMS_FOUND=false

# Descobrir discos
DISKS=$(sudo smartctl –scan | awk ‘{print $1}’ | sort -u)

for disk in $DISKS; do
# Determinar se é NVMe ou ATA
if echo “$disk” | grep -q “nvme”; then
disk_type=”nvme”
else
disk_type=”ata”
fi

# Estado de saúde geral
health=$(sudo smartctl -H “$disk” 2>/dev/null | grep -i “result” | awk ‘{print $NF}’)
REPORT+=”— $disk (tipo: $disk_type, saúde: $health) —“$’\n’

if [[ “$health” != “PASSED” && “$health” != “OK” ]]; then
PROBLEMS_FOUND=true
REPORT+=” ALERTA: Estado de saúde não é PASSED”$’\n’
fi

if [[ “$disk_type” == “nvme” ]]; then
# Verificar métricas NVMe
for metric in “${NVME_CRITICALS[@]}”; do
name=”${metric%%:*}”
threshold=”${metric##*:}”
value=$(sudo smartctl -a “$disk” 2>/dev/null | grep -i “$name” | awk ‘{print $NF}’)
if [[ -n “$value” && “$value” -gt “$threshold” ]]; then
PROBLEMS_FOUND=true
REPORT+=” ALERTA: $name = $value (threshold: $threshold)”$’\n’
fi
done
else
# Verificar atributos ATA
for attr in “${CRITICAL_ATTRS[@]}”; do
id=”${attr%%:*}”
rest=”${attr#*:}”
name=”${rest%%:*}”
threshold=”${rest##*:}”
raw=$(sudo smartctl -A “$disk” 2>/dev/null | awk -v id=”^${id} ” ‘$0 ~ id {print $10}’)
if [[ -n “$raw” && “$raw” -gt “$threshold” ]]; then
PROBLEMS_FOUND=true
REPORT+=” ALERTA: ID $id ($name) RAW=$raw (threshold: $threshold)”$’\n’
fi
done
fi
REPORT+=$’\n’
done

# Output do relatório
echo “$REPORT”

# Enviar email se houver problemas e –alert estiver activo
if [[ “$PROBLEMS_FOUND” == true && “$SEND_ALERT” == true && -n “$ALERT_EMAIL” ]]; then
echo “$REPORT” | mail -s “[SMART ALERT] Problemas detectados em $(hostname)” “$ALERT_EMAIL”
echo “Email enviado para $ALERT_EMAIL”
fi

# Exit code para integração com monitoring
if [[ “$PROBLEMS_FOUND” == true ]]; then
exit 1
else
exit 0
fi

Instalação do script:

sudo cp smart_check.sh /usr/local/bin/smart_check.sh
sudo chmod +x /usr/local/bin/smart_check.sh

# Execução manual
sudo /usr/local/bin/smart_check.sh

# Cron — verificação diária às 06h00 com alerta por email
echo “0 6 * * * root /usr/local/bin/smart_check.sh –alert –email [email protected]” | sudo tee /etc/cron.d/smart-check

# systemd timer (alternativa ao cron)
sudo tee /etc/systemd/system/smart-check.service << ‘EOF’
[Unit]
Description=SMART disk health check
After=local-fs.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/smart_check.sh –alert –email [email protected]
EOF

sudo tee /etc/systemd/system/smart-check.timer << ‘EOF’
[Unit]
Description=Run SMART check daily

[Timer]
OnCalendar=*-*-* 06:00:00
Persistent=true

[Install]
WantedBy=timers.target
EOF

sudo systemctl enable –now smart-check.timer

Script adicional — verificação de arrays mdadm

#!/bin/bash
# mdadm_check.sh — Verifica estado de todos os arrays mdadm
# Gera alerta se algum array não estiver “clean”

PROBLEMS=false
REPORT=””

# Verificar estado de cada array
for md in /dev/md/*; do
[[ -e “$md” ]] || continue
state=$(sudo mdadm –detail “$md” 2>/dev/null | grep “State :” | awk ‘{print $3}’)
active=$(sudo mdadm –detail “$md” 2>/dev/null | grep “Active Devices” | awk ‘{print $4}’)
working=$(sudo mdadm –detail “$md” 2>/dev/null | grep “Working Devices” | awk ‘{print $4}’)
failed=$(sudo mdadm –detail “$md” 2>/dev/null | grep “Failed Devices” | awk ‘{print $4}’)

REPORT+=”$md: estado=$state, activos=$active, a funcionar=$working, falhados=$failed”$’\n’

if [[ “$state” != “clean” || “$failed” -gt 0 ]]; then
PROBLEMS=true
REPORT+=” ALERTA: Array $md em estado $state com $failed discos falhados”$’\n’
fi
done

echo “$REPORT”
[[ “$PROBLEMS” == true ]] && exit 1 || exit 0

Checklist Pré-Produção

Antes de colocar um servidor em produção, verificar os seguintes pontos de diagnóstico de discos:

  • [ ] Instalar smartmontools em todos os servidores Linux (apt install smartmontools / dnf install smartmontools)
  • [ ] Configurar smartd em /etc/smartd.conf com DEVICESCAN e email de alerta configurado
  • [ ] Activar e iniciar o serviço: sudo systemctl enable --now smartmontools
  • [ ] Executar smartctl -H em todos os discos e confirmar resultado PASSED antes de aceitar o servidor
  • [ ] Verificar que Reallocated Sector Count (ID 5), Current Pending Sector (ID 197) e Offline Uncorrectable (ID 198) são todos 0 em discos novos
  • [ ] Em NVMe, verificar que Percentage Used < 5% e Available Spare > threshold
  • [ ] Para discos com ID 197 > 0, executar badblocks -sv e e2fsck -cc antes de colocar em produção
  • [ ] Configurar teste SMART curto diário e teste longo semanal em smartd (-s (S/../.././01|L/../../6/03))
  • [ ] Instalar CrystalDiskInfo em todas as estações Windows com auto-refresh e alertas por email activados
  • [ ] Para arrays mdadm, configurar mdadm --monitor --scan com email de alerta (MAILADDR [email protected] em /etc/mdadm/mdadm.conf)
  • [ ] Para pools ZFS, agendar scrub mensal via cron ou systemd timer
  • [ ] Integrar SMART no Nagios (check_smart), Zabbix (user parameters + LLD) ou Checkmk (plugin nativo)
  • [ ] Instalar o script smart_check.sh em /usr/local/bin/ e configurar cron ou systemd timer diário
  • [ ] Verificar que alertas de SMART chegam ao administrador (teste com -M test em smartd ou email de teste manual)
  • [ ] Documentar TBW nominal de cada SSD e Percentage Used actual para baseline de monitorização
  • [ ] Configurar sudoers para Nagios/Zabbix poder executar smartctl sem password
  • [ ] Em ambientes com discos hot-swap, verificar que a substituição de disco é testada (mdadm –add / zpool replace) antes de uma falha real
  • [ ] Confirmar que backups 3-2-1 estão operacionais — SMART previne, mas não substitui backups

Artigos Relacionados

Fontes

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário