Quem Vigia o Monitor? Como Usar o Dead-Man's Switch para Saberes Imediatamente se os Teus Backups Noturnos Não Correram

A Ilusão do Silêncio: Porque Não Haver Avisos Quase Sempre é Péssimo Sinal

Pergunta a qualquer gestor de sistemas como garante que os backups da base de dados e os scripts no cron estão a correr bem, e vais ouvir muitas vezes a mesma justificação:

“O nosso script de backup tem código de tratamento de erros. Se a cópia falhar ou o envio para a nuvem der erro, ele envia uma mensagem para o nosso canal de Slack. Como o canal tem estado calmo, os backups estão a correr sem problemas.”

Esta forma de pensar é uma das maiores armadilhas no mundo dos servidores.

Três meses depois, um colega apaga uma tabela de clientes na base de dados por engano. A equipa corre para a pasta de cópias de segurança para repor o ficheiro da noite anterior e depara-se com uma catástrofe: o último backup gravado com sucesso tem quase três meses de idade.

A CASCATA DA FALHA SILENCIOSA DE BACKUPS

• Dia 1: O Backup Corre com Sucesso → Guarda o Ficheiro (O Slack está calmo)
• Dia 2: O Backup Corre com Sucesso → Guarda o Ficheiro (O Slack está calmo)
• Dia 3: O CRON CONGELA / FALTA A LUZ / O DISCO ESGOTA OS INODES!
• O script de backup NUNCA chega a arrancar!
• O bloco de tratamento de erro NUNCA é executado!
• O vosso canal de alertas continua no mais absoluto SILÊNCIO!
• Dia 84: Acontece um Desastre na Base de Dados!
• A equipa descobre: NÃO HÁ BACKUPS HÁ QUASE 3 MESES!

O modelo tradicional depende de notificações ativas de erro: o script tem de arrancar, detetar o seu próprio problema, montar uma mensagem e enviá-la pela rede com sucesso.

Se a máquina foi desligada, a placa de rede falhou, a pasta do cron encravou ou o kernel do Linux suspendeu o processo por falta de memória, o script nem sequer começou a correr. Ele não conseguiu pedir ajuda. Para o teu painel de alertas, estava tudo perfeito porque não recebeu nenhum sinal de perigo.

A única forma de teres a certeza matemática de que uma tarefa correu é inverter o modelo: Não esperes por notícias de erro; fica em alerta se não receberes notícias de sucesso.

Este método chama-se Dead-Man’s Switch (ou interruptor de homem-morto).

Nas rotinas que desenhamos no nosso serviço de alojamento gerido e nas intervenções de manutenção preventiva, consideramos a monitorização reversa um requisito obrigatório em todos os servidores com Debian GNU/Linux.

O Que É um Dead-Man’s Switch: O Princípio do Batimento Cardíaco Invertido

O nome vem dos comboios antigos: o maquinista tinha de manter o pé pressionado num pedal especial. Se sofresse um ataque cardíaco ou adormecesse, o pedal subia e o comboio travava sozinho de emergência.

Na infraestrutura de servidores, o dead-man’s switch corre num serviço externo completamente independente (como o Healthchecks.io, um projeto de código aberto alojado no GitHub):

O CICLO OPERACIONAL DO DEAD-MAN’S SWITCH

• O Teu Servidor de Produção Monitor Externo na Nuvem
• (Horário Previsto: Todos os dias às 03:00)
• 03:00 → GET /ping/codigo/start → Inicia o cronómetro
• Corre o Script de Cópia (Demora 8 minutos)
• 03:08 → GET /ping/codigo → Reinicia a contagem (Estado: SAUDÁVEL)
• NA NOITE SEGUINTE (AVARIA GRAVE: Servidor Bloqueado / Sem Eletricidade)
• 03:00 — (Silêncio… A máquina não enviou nenhum pacote!)
• Janela de Tolerância Expirou!
• O Monitor Dispara o Alarme Geral!
• Aviso enviado por SMS e Slack: “ALERTA: O backup falhou a chamada!”

Repara na diferença fundamental: o monitor externo está fora do teu servidor. Não precisa de aceder por SSH à tua máquina nem de senhas. Apenas fica à espera do teu sinal. Se esse sinal não chegar na hora combinada (mais uma margem de segurança configurada), o monitor externo dá o alarme imediatamente.

Mesmo que o teu servidor arda ou perca a ligação à internet, o alerta vai tocar sem falta no telemóvel da tua equipa.

Mãos à Obra: Como Blindar o Teu Script de Backup com o Curl

Vamos transformar um script de cópia de segurança em bash comum numa rotina profissional com telemetria reversa:

#!/usr/bin/env bash
set -euo pipefail

# Definições de Telemetria
CODIGO_PING="b892a01f-4421-4b11-9a2c-10842f9a12bc"
URL_PING="https://hc-ping.com/${CODIGO_PING}"
PASTA_BACKUP="/var/backups/postgres"
DATA_HORA=$(date -u +"%Y%m%d_%H%M%S")
FICHEIRO_DUMP="${PASTA_BACKUP}/producao_${DATA_HORA}.sql.gz"

# 1. Avisa o monitor externo de que o trabalho começou
curl -fsS -m 10 --retry 3 "${URL_PING}/start" > /dev/null || true

# 2. Interceta qualquer falha no script e avisa o monitor de imediato
trap 'curl -fsS -m 10 --retry 3 "${URL_PING}/fail" > /dev/null || true' ERR

echo "[$(date -u)] A iniciar backup da base de dados..."
mkdir -p "${PASTA_BACKUP}"

# 3. Executa a extração da base de dados PostgreSQL
pg_dump -U postgres -h 127.0.0.1 -Fc producao | gzip > "${FICHEIRO_DUMP}"

# 4. Confirma que o ficheiro foi mesmo criado e não está vazio
if [ ! -s "${FICHEIRO_DUMP}" ]; then
  echo "Erro Crítico: O ficheiro de backup não existe ou tem 0 bytes!" >&2
  exit 1
fi

echo "[$(date -u)] Backup terminado com sucesso. Tamanho: $(du -h "${FICHEIRO_DUMP}" | cut -f1)"

# 5. Envia o sinal final de sucesso para reiniciar o contador do monitor
curl -fsS -m 10 --retry 3 "${URL_PING}" > /dev/null

OS TRÊS SINAIS DE TELEMETRIA NO TEU SCRIPT

• Sinal 1: /start → Avisa o monitor: “Comecei agora. Mede o tempo da tarefa.”
• Sinal 2: /fail → Disparado pelo trap ERR se algum comando devolver erro
• Sinal 3: /0 (OK) → Enviado só se tudo correr bem: confirma que a cópia existe!

O Que Fazem as Opções do Curl:

• -f: Não cospe erros de HTML se o servidor remoto tiver um soluço temporário.
• -sS: Corre em silêncio mas mostra mensagens no terminal se a rede falhar.
• -m 10: Timeout máximo de 10 segundos. Nunca deixes o teu script encravar à espera de um ping.
• --retry 3: Faz até três tentativas automáticas se houver uma micro-quebra na internet.

Como Integrar com Timers Nativos do Systemd

Se estás a usar timers modernos no systemd em vez do crontab tradicional, podes embutir a monitorização diretamente no ficheiro da unidade de serviço:

1. Criar o Serviço: /etc/systemd/system/backup-base-dados.service

[Unit]
Description=Serviço Noturno de Cópia da Base de Dados
After=network-online.target
OnFailure=backup-falha-alerta.service

[Service]
Type=oneshot
User=postgres
ExecStartPre=/usr/bin/curl -fsS -m 10 --retry 3 https://hc-ping.com/codigo-start
ExecStart=/usr/local/bin/executar-copia.sh
ExecStartPost=/usr/bin/curl -fsS -m 10 --retry 3 https://hc-ping.com/codigo

2. Criar a Ação de Falha: /etc/systemd/system/backup-falha-alerta.service

[Unit]
Description=Envia aviso explícito de falha para o Healthchecks

[Service]
Type=oneshot
ExecStart=/usr/bin/curl -fsS -m 10 https://hc-ping.com/codigo/fail

Se a tarefa correr bem, o systemd executa o ExecStartPre (início) e o ExecStartPost (sucesso). Se houver um erro a meio, o systemd suspende a rotina e aciona a unidade de OnFailure=, avisando o monitor que houve um problema.

Se a máquina inteira desligar, o monitor externo dispara o alarme sozinho assim que a hora limite for ultrapassada.

Instalação Própria: Como Ter o Teu Próprio Servidor de Pings

Se a tua empresa tem políticas rígidas de privacidade e não queres usar serviços na nuvem, podes alojar a tua própria instância do Healthchecks num pequeno servidor VPS dedicado com Docker:

# docker-compose.yml - Instalação Própria do Healthchecks
services:
  monitor:
    image: healthchecks/healthchecks:latest
    container_name: monitor-pings
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000"
    environment:
      - SITE_ROOT=https://status.oteudominio-interno.com
      - PING_ENDPOINT=https://status.oteudominio-interno.com/ping/
      - DEFAULT_FROM_EMAIL=alertas@oteudominio-interno.com
    volumes:
      - ./dados-monitor:/data

Colocas o Nginx à frente com certificado SSL e ficas com um sistema de telemetria interna totalmente privado e soberano.

As Regras de Ouro para a Tua Equipa de Operações

Para nunca mais seres apanhado de surpresa com falhas silenciosas, segue estas diretrizes:

1. Nunca Assumas que Correu Bem Apenas Porque Não Tiveste Avisos: O silêncio é o pior sintoma num servidor.
2. Qualquer Tarefa Crítica Tem de Ter um Dead-Man’s Switch: Backups, certificados SSL, limpezas de base de dados e relatórios financeiros têm de enviar batimentos cardíacos.
3. Define Margens Realistas: Se um backup demora 10 minutos a correr, coloca a tolerância em 30 minutos. Uma margem demasiado curta gera falsos alarmes; uma margem muito longa atrasa a tua reação.
4. Faz Simulacros: A cada três meses, desativa o script de propósito e confirma se o teu telemóvel recebe a chamada ou o SMS de emergência.

Com base na nossa filosofia de anti-over-engineering, a monitorização reversa entrega-te paz de espírito total com zero ferramentas pesadas. Aliando esta postura preventiva à nossa consultoria técnica, garantes que os teus sistemas estão verdadeiramente protegidos contra qualquer imprevisto.

No terreno, em conjunto com a experiência acumulada na Webxtek Studio, aplicamos exatamente estes padrões operacionais em setores exigentes como especialistas em devops e arquitetura cloud e provedores de cloud computing e iaas. Quando alinhas a tua estrutura através de alojamento gerido para websites e aplicações e consultoria técnica antes de construir, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.