smartctl e smartmontools: O Guia Completo de Monitoramento de Saúde de Drives Linux

smartctl é a principal interface de linha de comando do pacote smartmontools, projetada para consultar, testar e interpretar dados S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) incorporados no firmware de HDDs, SSDs e unidades NVMe. Ele se comunica diretamente com o firmware da unidade através das interfaces ATA, SCSI ou NVMe para expor telemetria de diagnóstico bruta que o próprio sistema operacional não expõe através dos caminhos de I/O padrão.

Para qualquer administrador Linux que gerencie armazenamento físico ou virtual — seja em um servidor bare-metal, um Servidor Dedicado, ou um array de discos conectado localmente — o smartctl é a ferramenta mais confiável para detectar falhas iminentes de unidade antes que causem perda irrecuperável de dados.

O Que É S.M.A.R.T. e Por Que É Importante

S.M.A.R.T. é um sistema de monitoramento integrado em praticamente todos os dispositivos de armazenamento para consumidores e empresas fabricados após 1996. Opera ao nível do firmware, rastreando continuamente dezenas de parâmetros internos: taxas de erros de leitura/escrita, indicadores de stress mecânico, níveis de desgaste de NAND, contagens de setores realocados e leituras térmicas.

A distinção crítica que a maioria dos guias ignora: os dados S.M.A.R.T. são preditivos, não reativos. Uma unidade pode passar numa verificação de sistema de ficheiros e servir I/O normalmente enquanto simultaneamente acumula setores realocados a uma taxa que estatisticamente prevê falha em semanas. O smartctl expõe este estado oculto de degradação.

S.M.A.R.T. opera em três famílias de interfaces de armazenamento:

• ATA/SATA — a especificação S.M.A.R.T. original, com mais atributos
• SCSI/SAS — usa um modelo de atributos diferente (páginas de log de Exceções Informacionais)
• NVMe — expõe dados de saúde através do NVMe Health Information Log (Log Page 0x02), com métricas como capacidade de reserva disponível, percentagem utilizada e desligamentos não seguros

Instalando o smartmontools no Linux

O pacote smartmontools está disponível nos repositórios oficiais de todas as principais distribuições Linux. Instale a versão adequada para o seu ambiente:

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

“`

Após a instalação, verifique a versão e confirme que o suporte a NVMe está compilado:

“`bash

smartctl –version

“`

Procure por `NVMe` na lista de tipos de dispositivos suportados. Versões anteriores à 6.6 têm suporte NVMe incompleto — em servidores modernos com SSDs NVMe, certifique-se de que está a executar o smartmontools 7.x ou posterior.

Identificando os Seus Dispositivos de Armazenamento

Antes de executar qualquer comando smartctl, identifique o nó de dispositivo correto. Confundir identificadores de dispositivos num sistema com múltiplos discos é um erro comum e dispendioso.

“`bash

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

“`

Isto apresenta os nomes dos dispositivos juntamente com o tipo de transporte (sata, nvme, usb), o que informa diretamente quais flags do smartctl serão necessárias. Para dispositivos NVMe, o nó aparecerá como `/dev/nvme0`, `/dev/nvme1`, etc. — não `/dev/sdX`.

Para controladores RAID de hardware (LSI MegaRAID, Adaptec, HP Smart Array), as unidades estão ocultas atrás do controlador e requerem flags explícitas de pass-through, abordadas na secção avançada abaixo.

Comandos Principais do smartctl

Visualizando Informações de Identidade do Dispositivo

“`bash

sudo smartctl -i /dev/sda

“`

Isto consulta a página IDENTIFY DATA do dispositivo e retorna o número do modelo, número de série, revisão do firmware, capacidade, tamanho do setor (512 bytes lógicos vs. 4096 bytes físicos — importante para alinhamento) e os flags de capacidade S.M.A.R.T. Em dispositivos NVMe:

“`bash

sudo smartctl -i /dev/nvme0

“`

Executando uma Avaliação Completa de Saúde

“`bash

sudo smartctl -H /dev/sda

“`

Retorna um veredicto numa única linha: `PASSED` ou `FAILED`. Um resultado `FAILED` significa que o próprio firmware da unidade determinou que um ou mais limites críticos foram ultrapassados. Uma unidade que reporta FAILED deve ser tratada como falha — não espere por confirmação adicional.

No entanto, um resultado `PASSED` não significa que a unidade está saudável. Significa apenas que nenhum limite foi formalmente ultrapassado. É por isso que a análise de atributos brutos é essencial.

Exibindo Todos os Atributos S.M.A.R.T.

“`bash

sudo smartctl -A /dev/sda

“`

Este é o comando com maior densidade de informação em uso rotineiro. A tabela de saída contém várias colunas que requerem interpretação precisa:

O RAW_VALUE é o que deve analisar principalmente. O sistema normalizado VALUE/WORST/THRESH é útil para deteção automática de limites, mas pode ser enganoso — alguns fabricantes utilizam curvas de normalização não padronizadas.

Saída Abrangente: Combinando Flags

Para uma visão completa num único comando, combine os flags de informação, saúde e atributos:

“`bash

sudo smartctl -a /dev/sda

“`

O flag em minúsculas `-a` é equivalente a `-H -i -c -A -l error -l selftest`. Este é o comando padrão a executar ao diagnosticar uma unidade desconhecida.

Para uma saída ainda mais detalhada incluindo todas as páginas de log:

“`bash

sudo smartctl -x /dev/sda

“`

Atributos S.M.A.R.T. Críticos e Como Interpretá-los

Nem todos os atributos S.M.A.R.T. têm o mesmo peso diagnóstico. Os seguintes são os atributos que engenheiros de armazenamento experientes tratam como indicadores primários de falha:

Indicadores de Falha de Alta Prioridade

Reallocated_Sector_Ct (ID 5)

A contagem de setores que a unidade remapeou para a área de reserva devido a erros de leitura/escrita/verificação. Qualquer valor diferente de zero numa unidade com menos de dois anos merece atenção imediata. Uma contagem em constante aumento — mesmo de 1 para 5 ao longo de um mês — é um forte preditor de falha iminente. Em unidades empresariais, um pequeno número pode ser aceitável dependendo da especificação do fabricante.

Current_Pending_Sector (ID 197)

Setores sinalizados como instáveis e a aguardar remapeamento. Estes setores produziram erros durante leituras mas ainda não foram remapeados com sucesso. Um valor diferente de zero aqui significa que a unidade está ativamente com dificuldades em ler dados. Se um setor pendente for posteriormente escrito com sucesso, pode ser remapeado ou limpo — mas o suporte físico subjacente é suspeito.

Uncorrectable_Sector_Count (ID 198) / Offline_Uncorrectable

Setores que não puderam ser corrigidos pelo ECC e não puderam ser remapeados. Este é o atributo mais grave. Um valor diferente de zero aqui significa que os dados já foram perdidos nesses setores. Backup imediato e substituição da unidade é a única resposta adequada.

Reported_Uncorrect (ID 187)

Em unidades modernas, conta erros que o ECC interno da unidade não conseguiu corrigir. Valores elevados indicam degradação grave do suporte físico.

Spin_Retry_Count (ID 10)

Para HDDs, falhas repetidas ao fazer girar os pratos até à velocidade de operação. Indica stress mecânico no motor do fuso ou nos rolamentos. Qualquer valor diferente de zero numa unidade sob uso intenso é um sinal de alerta.

Command_Timeout (ID 188)

A contagem de comandos que foram abortados devido a timeout. Valores elevados frequentemente indicam problemas de interface (cabo, controlador ou fornecimento de energia) em vez de falha no suporte físico — mas também podem preceder uma falha total da unidade.

Atributos de Monitoramento Secundário

Raw_Read_Error_Rate (ID 1)

Frequentemente mal interpretado: nas unidades Seagate, este atributo tem um valor bruto muito elevado por design, pois representa uma razão codificada num campo de 48 bits. Um valor bruto de vários milhões numa unidade Seagate é normal. Nas unidades Western Digital e outros fabricantes, o valor bruto deve ser próximo de zero. Consulte sempre a documentação do fabricante antes de alarmar com este atributo.

Power_On_Hours (ID 9)

Total de horas de operação. Os HDDs para consumidores são tipicamente classificados para 20.000–25.000 horas (aproximadamente 2–3 anos de operação contínua). As unidades empresariais são classificadas para 55.000+ horas. Use isto para contextualizar outros valores de atributos.

Temperature_Celsius (ID 194)

A temperatura atual da unidade. O intervalo de operação ideal para a maioria dos HDDs é 25–45°C. Temperaturas sustentadas acima de 55°C aceleram o desgaste dos rolamentos e a degradação do suporte magnético. Para SSDs, a tolerância térmica é geralmente maior, mas temperaturas sustentadas acima de 70°C irão acelerar o desgaste do NAND. Em servidores sem fluxo de ar adequado — um problema comum em implementações de rack densas — o throttling térmico pode disfarçar-se como latência de I/O antes que o atributo de temperatura ultrapasse qualquer limite formal.

Wear_Leveling_Count (ID 177) / Media_Wearout_Indicator (ID 233)

Atributos específicos de SSD que rastreiam o consumo de endurance do NAND. Quando o VALUE normalizado se aproxima do valor THRESH, o SSD está a aproximar-se da sua endurance de escrita classificada. Planeie a substituição proativamente.

Power_Cycle_Count (ID 12)

Ciclos de energia frequentes causam stress mecânico nos HDDs (estacionamento/desestacionamento da cabeça, stress no motor do fuso) e, em menor grau, stress elétrico nos SSDs. Contagens incomumente altas em relação ao Power_On_Hours podem indicar um ambiente de energia instável.

Executando Testes de Autodiagnóstico

Os autotestes S.M.A.R.T. são executados pelo próprio firmware da unidade, não pelo sistema operacional. A unidade continua a servir I/O durante os testes (com um impacto menor no desempenho), tornando estes testes seguros para executar em sistemas de produção.

Autoteste Curto

“`bash

sudo smartctl -t short /dev/sda

“`

Duração: tipicamente 1–5 minutos. Testa os componentes elétricos e mecânicos e uma pequena percentagem da superfície do disco. Útil para uma verificação rápida de sanidade. Veja os resultados após a conclusão:

“`bash

sudo smartctl -l selftest /dev/sda

“`

Autoteste Longo (Teste Estendido)

“`bash

sudo smartctl -t long /dev/sda

“`

Duração: proporcional à capacidade da unidade — espere 1 hora por terabyte num HDD típico de 7200 RPM, e 20–60 minutos na maioria dos SSDs. Realiza uma verificação completa da superfície de cada setor. Este é o teste definitivo para detetar setores defeituosos em toda a superfície do suporte físico.

Monitorize o progresso sem aguardar a conclusão:

“`bash

sudo smartctl -c /dev/sda

“`

A saída inclui uma percentagem de conclusão e um tempo estimado de finalização.

Autoteste de Transporte

“`bash

sudo smartctl -t conveyance /dev/sda

“`

Disponível na maioria das unidades ATA. Projetado para detetar danos ocorridos durante o transporte ou manuseamento físico. Verifica problemas causados por choque mecânico. A duração é tipicamente de 5 minutos. Este teste é subutilizado — é particularmente valioso ao colocar novo hardware em funcionamento ou após um servidor ter sido fisicamente relocado.

Autoteste Seletivo

“`bash

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

“`

Permite testar um intervalo LBA específico em vez de toda a unidade. Inestimável quando as verificações do sistema de ficheiros sinalizaram erros numa região específica e precisa confirmar se o suporte físico subjacente é responsável.

Monitoramento de Saúde Específico para NVMe

As unidades NVMe utilizam um modelo de atributos fundamentalmente diferente. O comando principal de saúde:

“`bash

sudo smartctl -a /dev/nvme0

“`

Campos específicos de NVMe a monitorizar:

• Available Spare: Percentagem de blocos NAND de reserva restantes. Abaixo de 10% justifica planeamento de substituição.
• Available Spare Threshold: O limite definido pelo fabricante abaixo do qual a unidade pode reportar fiabilidade degradada.
• Percentage Used: Percentagem estimada de endurance de escrita classificada consumida. A 100%, a unidade atingiu o seu TBW (Terabytes Written) classificado — pode continuar a funcionar, mas as garantias de fiabilidade já não se aplicam.
• Data Units Read / Written: I/O cumulativo em unidades de 512.000 bytes. Útil para calcular a carga de trabalho real vs. TBW classificado.
• Media and Data Integrity Errors: Erros de suporte físico não recuperados ou erros de integridade de dados detetados pelo controlador NVMe. Qualquer valor diferente de zero é grave.
• Number of Error Information Log Entries: Contagem de entradas no log de erros. Uma contagem em rápido crescimento indica problemas persistentes.
• Power State: Estado de energia NVMe atual — relevante para cargas de trabalho sensíveis à latência onde a unidade pode estar num estado de poupança de energia profundo.

RAID de Hardware e Acesso Pass-Through

Quando as unidades estão ligadas através de um controlador RAID de hardware, o SO vê o disco virtual do controlador, não as unidades físicas. O smartctl requer pass-through explícito para aceder diretamente ao firmware da unidade.

LSI MegaRAID:

“`bash

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

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

“`

HP Smart Array (driver hpsa):

“`bash

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

“`

3ware RAID:

“`bash

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

“`

Se não tiver a certeza de qual tipo de pass-through utilizar, o smartctl pode tentar a deteção automática:

“`bash

sudo smartctl –scan

“`

Isto verifica todos os dispositivos de armazenamento detetáveis e apresenta o caminho de dispositivo recomendado e o flag de tipo para cada um.

Ativando e Desativando o S.M.A.R.T.

O S.M.A.R.T. está ativado por padrão em praticamente todas as unidades modernas. Em casos raros — tipicamente unidades mais antigas ou certos ambientes virtualizados — pode estar desativado:

“`bash

sudo smartctl -s on /dev/sda

“`

Para desativar (não recomendado exceto para cenários de teste específicos):

“`bash

sudo smartctl -s off /dev/sda

“`

Nota: Em ambientes virtualizados como KVM ou VMware, o pass-through S.M.A.R.T. para VMs convidadas depende da configuração do hipervisor. Num ambiente de VPS Hosting, o hipervisor tipicamente abstrai a unidade física, e o smartctl dentro do convidado pode retornar dados limitados ou nenhum dado. Para acesso completo ao S.M.A.R.T., é necessário monitoramento ao nível do host físico ou um Servidor Dedicado.

Monitoramento Automatizado com smartd

O daemon smartd é o componente de nível de produção do smartmontools. Executa em segundo plano, verificando periodicamente as unidades e executando testes agendados, alertando os administradores quando os limites são ultrapassados ou ocorrem falhas nos testes.

Configurando /etc/smartd.conf

A configuração padrão monitoriza todas as unidades detetadas com configurações básicas. Uma configuração reforçada para produção tem este aspeto:

“`

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

“`

Diretivas principais explicadas:

Ativando e Iniciando o smartd

“`bash

sudo systemctl enable smartd

sudo systemctl start smartd

sudo systemctl status smartd

“`

Verifique se o daemon está a monitorizar ativamente:

“`bash

sudo journalctl -u smartd -f

“`

Configuração de Alertas por Email

Para que os alertas de email do smartd funcionem, o sistema requer um MTA (agente de transferência de correio) a funcionar. Em instalações de servidor mínimas, instale e configure `postfix` ou `msmtp` para relay. Se estiver a utilizar uma infraestrutura de correio dedicada, considere combinar os alertas do smartd com um serviço de Email Hosting devidamente configurado para garantir que a entrega de alertas não seja bloqueada por filtros de spam.

Comparação de Atributos S.M.A.R.T.: HDD vs. SSD vs. NVMe

Fluxo de Trabalho Prático: Diagnosticando uma Unidade Suspeita

Quando uma unidade exibe sintomas — erros de I/O em `dmesg`, corrupção do sistema de ficheiros, latência incomum — siga esta sequência de diagnóstico:

Passo 1: Confirmar a disponibilidade do S.M.A.R.T.

“`bash

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

“`

Passo 2: Verificar o veredicto geral de saúde

“`bash

sudo smartctl -H /dev/sda

“`

Passo 3: Inspecionar o log de erros

“`bash

sudo smartctl -l error /dev/sda

“`

O log de erros regista os últimos 5 erros ATA com timestamps e endereços LBA. Faça referência cruzada dos endereços LBA com os mapas de blocos do sistema de ficheiros usando `debugfs` ou `xfs_db` para determinar se os erros afetam estruturas críticas do sistema de ficheiros.

Passo 4: Analisar atributos críticos

“`bash

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

“`

Passo 5: Executar um teste curto para confirmação imediata

“`bash

sudo smartctl -t short /dev/sda

sleep 120

sudo smartctl -l selftest /dev/sda

“`

Passo 6: Se o teste curto passar e os sintomas persistirem, execute um teste longo durante uma janela de manutenção

“`bash

sudo smartctl -t long /dev/sda

“`

Passo 7: Rever o log de autoteste para endereços LBA de falha

“`bash

sudo smartctl -l selftest /dev/sda

“`

Os testes falhados reportam o LBA do primeiro erro encontrado. Isto identifica a localização exata do dano no suporte físico.

Armadilhas Comuns e Casos Extremos

Unidades ligadas via USB: o smartctl frequentemente não consegue comunicar com unidades ligadas através de adaptadores USB-para-SATA porque o chip de ponte USB não encaminha comandos ATA. Use o flag `-d sat` ou `-d usb`, ou especifique o tipo de ponte explicitamente (ex.: `-d usb,0x0bc2,0x2312`). O flag `–scan` tentará identificar o tipo correto automaticamente.

Ambientes virtualizados: Dentro de um convidado KVM ou VMware, `/dev/sda` é um disco virtual. O smartctl pode retornar `Device does not support SMART` ou dados fabricados passados pelo hipervisor. Não confie na saída do smartctl dentro do convidado para avaliação da saúde física da unidade em infraestrutura de alojamento partilhado.

Falsos positivos no Raw_Read_Error_Rate: Como referido acima, a codificação deste atributo pela Seagate causa valores brutos alarmantes que são completamente normais. Verifique sempre com a documentação de atributos do fabricante antes de agir com base neste valor.

Unidades atrás de RAID de software (mdadm): o smartctl acede às unidades componentes diretamente (`/dev/sda`, `/dev/sdb`), não ao dispositivo RAID (`/dev/md0`). Monitorize cada unidade membro individualmente.

Namespace NVMe vs. controlador: Use `/dev/nvme0` (controlador) para dados de saúde, não `/dev/nvme0n1` (namespace/dispositivo de bloco). Algumas versões do smartctl aceitam ambos, mas o nó do controlador é autoritativo para acesso ao log de saúde.

Unidades que mentem: Alguns SSDs para consumidores, particularmente unidades NAND QLC de nível inferior, foram documentados a reportar atributos S.M.A.R.T. saudáveis até à falha completa e repentina. S.M.A.R.T. é um indicador forte mas não uma garantia — não substitui backups regulares.

Implementando o smartmontools em Ambientes de Servidor

Para administradores que gerem múltiplos servidores físicos — como aqueles que executam cargas de trabalho em Servidores Dedicados — centralizar o monitoramento S.M.A.R.T. é essencial. Considere a seguinte arquitetura:

• Prometheus + node_exporter: O `node_exporter` inclui um script coletor de ficheiros de texto `smartmon` que exporta atributos S.M.A.R.T. como métricas Prometheus. Isto permite alertas via Alertmanager e visualização em dashboards Grafana.
• Nagios / Icinga2: O plugin `check_smart` fornece integração de monitoramento S.M.A.R.T. para stacks de monitoramento tradicionais.
• Scripts smartd personalizados: A diretiva `-M exec` no smartd.conf pode acionar qualquer script em caso de alerta — útil para integração com PagerDuty, webhooks Slack ou sistemas de tickets personalizados.
• Agregação de ficheiros de log: Configure o smartd para escrever no syslog, depois encaminhe para um agregador de logs centralizado (stack ELK, Loki) para análise de tendências históricas numa frota.

Para ambientes de alojamento web que utilizam painéis de controlo, as implementações de VPS com cPanel beneficiam do monitoramento S.M.A.R.T. ao nível do host configurado pelo fornecedor de infraestrutura, uma vez que o próprio cPanel não expõe dados de saúde da unidade nativamente.

Lista de Verificação de Pontos Principais

Use isto como referência de pré-implementação e operacional contínua:

• Instale o smartmontools 7.x ou posterior para garantir suporte completo a NVMe e SSDs modernos
• Execute `smartctl –scan` em novo hardware para identificar todas as unidades e os seus flags de interface necessários
• Verifique primeiro o veredicto de saúde `-H` — um resultado `FAILED` requer ação imediata independentemente de outros atributos
• Trate qualquer Reallocated_Sector_Ct, Current_Pending_Sector ou Uncorrectable_Sector_Count diferente de zero como sinal de falha — não espere que a contagem aumente
• Não confie apenas no Raw_Read_Error_Rate — valide com a documentação do fabricante antes de alarmar
• Agende testes longos automatizados semanalmente via smartd em todas as unidades de produção; testes curtos diariamente
• Configure alertas de email do smartd e verifique a entrega antes de confiar neles
• Para RAID de hardware, use sempre o flag de pass-through adequado — monitorizar o disco virtual não é equivalente a monitorizar as unidades físicas
• Em ambientes virtualizados, realize o monitoramento S.M.A.R.T. ao nível do hipervisor/host, não dentro das VMs convidadas
• Combine o monitoramento S.M.A.R.T. com uma estratégia de backup — S.M.A.R.T. prevê falhas, não previne a perda de dados
• Para unidades NVMe, monitorize o Available Spare e o Percentage Used além das contagens de erros
• Em servidores com múltiplas unidades, integre o smartd com uma plataforma de alertas centralizada em vez de depender da entrega de email local

Perguntas Frequentes

O smartctl funciona dentro de um VPS ou instância cloud?

Na maioria dos ambientes VPS, o hipervisor apresenta um dispositivo de bloco virtual ao convidado. O smartctl dentro do convidado retornará sem dados ou retornará dados sintetizados pelo hipervisor, que não refletem a saúde real da unidade física. O monitoramento S.M.A.R.T. significativo requer acesso ao host físico. Para visibilidade completa ao nível da unidade, um Servidor Dedicado é a solução adequada.

Qual é a diferença entre `smartctl -a` e `smartctl -x`?

O flag `-a` apresenta o conjunto padrão de dados S.M.A.R.T.: informações do dispositivo, veredicto de saúde, flags de capacidade, todos os atributos, log de erros e log de autoteste. O flag `-x` apresenta tudo o que `-a` fornece mais páginas de log adicionais incluindo o log de autoteste seletivo, log de estatísticas do dispositivo, log de defeitos pendentes e estatísticas do dispositivo ATA — fornecendo uma visão mais completa do histórico da unidade. Use `-x` para diagnósticos completos; `-a` para verificações de rotina.

Quanto tempo demora um autoteste longo e é seguro executá-lo numa unidade de produção?

A duração depende da capacidade e velocidade da unidade: aproximadamente 1 hora por terabyte para um HDD de 7200 RPM, e 20–60 minutos para a maioria dos SSDs. O teste é executado em segundo plano no firmware da unidade, e a unidade continua a servir I/O durante o teste. O impacto no desempenho é tipicamente menor (redução de 5–15% no throughput). É seguro executar em sistemas de produção durante períodos de baixo tráfego, mas é recomendado agendar durante uma janela de manutenção para cargas de trabalho sensíveis à latência.

O que significa quando Current_Pending_Sector é diferente de zero mas Reallocated_Sector_Ct não aumentou?

A unidade identificou setores que estão a produzir erros de leitura mas ainda não os remapeou com sucesso. O remapeamento ocorre quando a unidade consegue escrever no setor — seja através de uma operação de escrita ou de uma verificação offline. Se a contagem permanecer estática, os setores podem estar numa região somente de leitura ou a unidade pode não ter setores de reserva disponíveis para remapeamento. Uma contagem Current_Pending_Sector diferente de zero e em aumento, com Reallocated_Sector_Ct a permanecer estável, frequentemente indica que a unidade esgotou o seu conjunto de setores de reserva — uma condição de falha crítica.

O smartctl consegue detetar o desgaste de SSDs antes de a unidade falhar?

Sim, para SSDs SATA, os atributos Wear_Leveling_Count (ID 177), Media_Wearout_Indicator (ID 233) e Available_Reservd_Space (ID 232) rastreiam o consumo de endurance do NAND. Para SSDs NVMe, os campos Percentage Used e Available Spare no NVMe Health Information Log servem o mesmo propósito. Quando o Available Spare cai abaixo do seu limite ou o Percentage Used atinge 100%, a unidade consumiu a sua endurance de escrita classificada. Ao contrário das falhas mecânicas repentinas, a degradação por desgaste de SSD é gradual e altamente previsível — tornando-a um dos casos de uso mais fortes para o monitoramento proativo S.M.A.R.T.