Agendando Scrubs do ZFS e Testes SMART, e Sendo Alertado Quando Eles Falham

Meu NAS sempre esteve saudável desde que o tenho. Sei disso porque nunca vi um erro. Isso não é o mesmo que o pool ter sido verificado. Por muito tempo, meu plano de monitoramento para o ZFS foi "eu vou perceber", e eu só percebia as coisas quando por acaso rodava zpool status por algum outro motivo.

Este post cobre as três camadas que estou colocando em prática: scrubs agendados, testes SMART agendados e um caminho de alerta que não depende de eu lembrar de olhar. Ainda não rodei isso por um ano inteiro, então trate como uma configuração em funcionamento. Vou sinalizar onde estou em dúvida.

O que cada verificação realmente detecta

Elas se sobrepõem, mas não são a mesma coisa.

• Um scrub lê todos os blocos do pool e os verifica contra o checksum. Com redundância (mirror, RAIDZ), o ZFS repara o que puder a partir da cópia boa. Ele encontra corrupção silenciosa em dados que ninguém lê há meses.
• Um teste SMART pede ao drive que examine a si mesmo. Um teste curto é uma verificação rápida do básico. Um teste longo lê a superfície inteira. O SMART pode avisar sobre um disco falhando antes de o ZFS ver um único erro de checksum. Ele também pode não dizer nada até o momento em que o disco morre, então eu o trato como uma dica, não como uma garantia.
• O ZED, o ZFS Event Daemon, reage a eventos conforme eles acontecem: um dispositivo ficando offline, um erro de checksum, um scrub terminando. É a peça que pode enviar uma mensagem para você.

Se eu pudesse ter só um, escolheria os scrubs. Mas um scrub que roda e encontra erros é inútil se ninguém ficar sabendo.

Scrubs: verifique o que você já tem

Em sistemas baseados em Debian (Proxmox incluído), os pacotes do ZFS normalmente trazem uma entrada de cron que faz scrub dos pools mensalmente. Eu verificaria isso na sua própria máquina em vez de assumir:

cat /etc/cron.d/zfsutils-linux
zpool status tank | grep -A2 scan:

A linha scan: mostra quando o último scrub terminou e se ele reparou alguma coisa. Se ela disser none requested, nada nunca rodou. Em um Synology ou TrueNAS, o agendamento fica na interface, então verifique lá.

Se você precisar adicionar seu próprio agendamento, uma linha simples de cron funciona:

# /etc/cron.d/zfs-scrub-custom
0 2 1 * * root /usr/sbin/zpool scrub tank

Mensal é um ponto de partida comum. Não tenho uma opinião forte sobre semanal versus mensal para um pool doméstico de 20 a 40 TB. Um scrub lê o pool inteiro, então adiciona carga de I/O e um pouco de calor, e prefiro não rodar um enquanto o Immich está processando uma importação grande. Eu agendo para o meio da madrugada e deixo assim.

Se você quiser um pool para experimentar antes de mexer no real, este lab mostra como montar um mirror ZFS durante a instalação do Proxmox:

Você vai praticar o espelhamento de dois SSDs com ZFS como parte da instalação do Proxmox VE, o que te dá um pool para rodar zpool status.

Testes SMART com smartd

O pacote smartmontools inclui o smartd, que executa autotestes agendados e monitora atributos. A configuração fica em /etc/smartd.conf. Uma entrada resumida para um disco fica assim:

/dev/sda -a -o on -S on -s (S/../.././02|L/../01/./03) -m [email protected]

Em linhas gerais: monitorar todos os atributos, rodar um teste curto todo dia às 2h, rodar um teste longo no dia 1º do mês às 3h e enviar e-mail em caso de problemas. A regex de agendamento é a parte que eu sempre preciso reler no man smartd.conf, então confira com a sua versão em vez de confiar na minha memória.

Dois cuidados que encontrei ou li a respeito:

• HBAs e controladoras RAID. Atrás de algumas controladoras, você precisa de -d sat ou de um tipo de dispositivo específico da controladora para alcançar os dados SMART do drive. Teste primeiro com smartctl -a /dev/sdX e só depois coloque o dispositivo no smartd.conf.
• Não sobreponha com o scrub. Testes SMART longos em todos os discos ao mesmo tempo, durante um scrub, são muitas leituras simultâneas. Eu escalono com um dia ou mais de diferença.

ZED: deixe o pool avisar você

A configuração do ZED em sistemas estilo Debian fica em /etc/zfs/zed.d/zed.rc. As opções que me interessam:

ZED_EMAIL_ADDR="[email protected]"
ZED_NOTIFY_VERBOSE=1

Com as notificações verbose ativadas, você recebe uma mensagem quando um scrub termina, não só quando algo quebra. Isso importa mais do que parece. Se o e-mail mensal de "scrub concluído, sem erros" para de chegar, esse silêncio é um sinal por si só.

O problema é que o e-mail do ZED precisa de um caminho de envio funcionando a partir do host. Um homelab geralmente não tem servidor de e-mail, então isso significa configurar um relay (msmtp, Postfix com smarthost, o que você já usar). Já vi histórias demais de "o e-mail nunca funcionou e ninguém percebeu", então agora mando uma mensagem de teste para mim mesmo antes de confiar:

echo "zed test" | mail -s "nas test" [email protected]

Se isso não chegar, nada mais neste post vai chegar também.

Um heartbeat, porque o e-mail falha em silêncio

Alertas só ajudam se o caminho de alerta funcionar. O modo de falha que me preocupa não é o barulhento: é o NAS ficar offline, o job do cron ser desativado ou o relay de e-mail quebrar, e tudo continuar calmo.

Por isso estou adicionando um heartbeat. O Uptime Kuma tem um tipo de monitor push: você recebe uma URL e, se ela não for acessada dentro do intervalo que você definir, o Kuma marca o monitor como fora do ar e notifica você. Um pequeno script no NAS verifica a saúde do pool e só faz o ping quando está tudo limpo:

#!/usr/bin/env bash
# /usr/local/bin/zfs-heartbeat.sh
set -u
PUSH_URL="https://kuma.lab.example/api/push/REPLACE_WITH_TOKEN"

if [ "$(zpool status -x)" = "all pools are healthy" ]; then
  curl -fsS -m 10 "${PUSH_URL}?status=up&msg=OK" > /dev/null
fi

Rode pelo cron a cada 15 minutos mais ou menos, e configure o intervalo de heartbeat do monitor no Kuma um pouco maior que isso. A lógica é deliberada: o script nunca reporta um problema por conta própria. Ele só reporta saúde, e a ausência do ping é o alarme. Isso cobre um pool degradado, um host morto, um job de cron quebrado e um caminho de rede quebrado com a mesma regra.

A comparação de string com all pools are healthy corresponde ao que o zpool status -x imprime quando nada está errado. Na minha experiência isso tem sido estável, mas eu testaria em um pool de teste deliberadamente degradado antes de depender disso.

O que eu ainda não testei

• Não tirei um disco de um mirror para ver toda a cadeia de alertas disparar de ponta a ponta. Isso pertence ao mesmo exercício dos meus testes de restauração, e vou fazer em um pool de teste, não no real.
• Não tenho certeza de quão barulhento o ZED_NOTIFY_VERBOSE=1 fica ao longo de meses. Posso reduzir.
• Não sei se o heartbeat deveria verificar também o status SMART, ou se isso seria um script a mais.

Perguntas para vocês

Com que frequência vocês fazem scrub em um pool desse tamanho, e já mudaram o agendamento depois de ver o impacto no I/O? Vocês confiam o suficiente nos avisos do SMART para trocar um disco por causa deles, ou esperam os erros do ZFS? E alguém encontrou um caminho de alerta mais limpo do que um relay de e-mail para um homelab?