Backup no SQL Server: como monitorar e garantir execução

Um job de backup que "sempre rodou" e um dia parou de rodar é um dos incidentes mais silenciosos que existem — ninguém percebe até precisar restaurar. A boa notícia é que o SQL Server já registra tudo o que precisa pra você nunca ser pego de surpresa.

Quando foi o último backup de cada banco

SELECT
  d.name AS banco,
  MAX(b.backup_finish_date) AS ultimo_backup,
  DATEDIFF(HOUR, MAX(b.backup_finish_date), GETDATE()) AS horas_desde_ultimo
FROM sys.databases d
LEFT JOIN msdb.dbo.backupset b
  ON b.database_name = d.name AND b.type = 'D' -- 'D' = full; use 'L' pra log
WHERE d.database_id > 4 -- ignora bancos de sistema
GROUP BY d.name
ORDER BY ultimo_backup ASC;

Rode isso e olhe primeiro os bancos com NULL em ultimo_backup — significa que nunca tiveram um backup FULL registrado no msdb. É a checagem mais importante da lista.

Falhas recentes de job

SELECT TOP 20
  j.name AS job,
  h.run_date, h.run_time, h.message
FROM msdb.dbo.sysjobhistory h
JOIN msdb.dbo.sysjobs j ON j.job_id = h.job_id
WHERE h.run_status = 0 -- 0 = falhou
  AND j.name LIKE '%backup%'
ORDER BY h.run_date DESC, h.run_time DESC;

O que monitorar continuamente

• Idade do último FULL backup por banco (alerta se passar do RPO combinado — ex.: 24h).
• Idade do último log backup em bancos com recovery model FULL — se o log não é feito, ele cresce indefinidamente além de aumentar o risco de perda de dados.
• Falha do job de backup, não só a ausência — um job que roda e falha silenciosamente é pior que um job que nunca existiu, porque dá falsa sensação de segurança.
• Espaço em disco no destino do backup — backup que falha por disco cheio é a causa mais comum e mais evitável.

Backup sem teste de restore periódico é uma aposta, não uma garantia. Mas o primeiro passo — saber que o backup rodou — é o que mais gente ainda faz manualmente ou nem faz. O codeDB monitora a idade do último backup de cada banco e alerta antes de virar um problema real, sem precisar rodar essas queries à mão toda manhã.