Seu backup do SQL Server restaura dentro do prazo do negócio?

Só há uma forma de saber: restaurando. Um backup de SQL Server só está provado quando alguém já o restaurou em outro servidor, cronometrou o processo e comparou o resultado com o prazo que a operação aceita ficar parada. Enquanto esse teste não acontece, o que existe é um job verde — e job verde mede se o arquivo foi escrito, não se a empresa volta a operar.

Essa diferença aparece sempre no pior momento. O time abre o histórico, vê meses de execuções bem-sucedidas, começa o restore e só então descobre o que estava faltando: a cadeia de log quebrada semanas atrás, o arquivo que leva quatro horas para vir do storage, a página corrompida que foi copiada fielmente para dentro de cada backup.

O job verde responde a pergunta errada

BACKUP DATABASE retorna sucesso quando terminou de gravar o arquivo. Ele não afirma que o conteúdo é restaurável, que a cadeia está íntegra, que as páginas estão consistentes ou que o destino ainda existe.

RESTORE VERIFYONLY melhora um pouco o quadro, mas menos do que a maioria supõe: ele confere se o conjunto de mídia é legível e, quando o backup foi gerado WITH CHECKSUM, revalida esses checksums. Não monta o banco, não roda recovery e não olha a consistência lógica das estruturas. Um banco com corrupção pode gerar backups que passam em VERIFYONLY indefinidamente — a corrupção viaja junto.

O único teste que responde à pergunta do negócio é o restore completo, seguido de DBCC CHECKDB no banco restaurado.

RPO e RTO: os dois números que definem tudo

Antes de mexer em qualquer job, o ambiente precisa de dois números vindos da operação, não da TI:

• RPO (Recovery Point Objective): quanto de dado a empresa aceita perder, medido em tempo. É o teto da janela entre backups.
• RTO (Recovery Time Objective): quanto tempo a empresa aceita ficar sem o sistema. É o teto do tempo total de recuperação.

A configuração técnica é consequência direta desses dois. RPO de quinze minutos exige recovery model FULL com BACKUP LOG a cada quinze minutos — não há como chegar lá com backup full diário. RTO de duas horas exige que cópia, restore, recovery e validação caibam, somados, em menos de duas horas.

Quando esses números não existem por escrito, o backup foi desenhado por hábito, e ninguém sabe dizer se está certo.

Onde o RPO real se perde

O RPO que o ambiente entrega costuma ser pior que o planejado, por motivos que não aparecem em nenhum alerta:

Recovery model incompatível com a promessa. Um banco em SIMPLE não aceita backup de log. O ponto de recuperação passa a ser o último full ou diferencial, independentemente do que o desenho previa. Vale conferir explicitamente:

SELECT name, recovery_model_desc, log_reuse_wait_descFROM sys.databasesWHERE database_id > 4;

Cadeia de log interrompida. Alternar para SIMPLE e voltar para FULL quebra a cadeia, e a partir dali os backups de log só voltam a ser úteis depois de um novo full. Uma segunda ferramenta fazendo backup de log em paralelo — um agente de VM, um appliance de storage — divide a cadeia entre dois repositórios, e o restore precisa dos dois.

Backup do banco certo, no lugar errado. Cópias que vivem no mesmo host, na mesma LUN ou na mesma conta que o servidor de produção compartilham o mesmo domínio de falha. Ransomware e erro humano não distinguem produção de backup quando ambos estão ao alcance da mesma credencial.

Para ver o que está de fato sendo gerado, msdb já tem a resposta:

SELECT    bs.database_name,    bs.type,                                  -- D = full, I = diferencial, L = log    MAX(bs.backup_finish_date) AS ultimo,    COUNT(*)                    AS execucoes_30d,    MAX(bs.backup_size / 1048576.0)      AS maior_mb,    MAX(DATEDIFF(SECOND, bs.backup_start_date, bs.backup_finish_date)) AS pior_duracao_sFROM msdb.dbo.backupset AS bsWHERE bs.backup_finish_date > DATEADD(DAY, -30, GETDATE())  AND bs.is_copy_only = 0GROUP BY bs.database_name, bs.typeORDER BY bs.database_name, bs.type;

O intervalo entre backups de log dessa consulta é o RPO real. Se ele diverge do RPO combinado, o desenho está descrito num documento e não no servidor.

Onde o RTO real estoura

O tempo de recuperação raramente é dominado pelo comando RESTORE. Ele se acumula em etapas que quase nunca entram na conta:

Cada linha dessa tabela é tempo de indisponibilidade, e nenhuma delas aparece no histórico do job de backup. Por isso o RTO não se estima — se cronometra.

Como medir, na prática

Um teste honesto cabe numa manhã e usa um servidor que não seja o de produção.

Restaure a partir do repositório real, não de uma cópia local já disponível. Boa parte do tempo perdido em incidente está justamente em trazer o arquivo de onde ele mora.

RESTORE DATABASE Vendas_Teste    FROM DISK = 'Z:\bkp\Vendas_FULL.bak'    WITH MOVE 'Vendas'     TO 'D:\dados\Vendas_Teste.mdf',         MOVE 'Vendas_log' TO 'L:\log\Vendas_Teste.ldf',         NORECOVERY, STATS = 5; RESTORE LOG Vendas_Teste    FROM DISK = 'Z:\bkp\Vendas_LOG_202607241200.trn'    WITH NORECOVERY; RESTORE DATABASE Vendas_Teste WITH RECOVERY; DBCC CHECKDB (Vendas_Teste) WITH NO_INFOMSGS, ALL_ERRORMSGS;

Cronometre do começo ao fim, incluindo a busca pelos arquivos e o CHECKDB. O número que sai daí é o RTO real do ambiente hoje. Compare com o RTO que a operação declarou: ou eles conversam, ou existe um risco em aberto que ninguém contratou.

Confirme o ponto de recuperação alcançado. Restaurar até o último log disponível responde ao RPO real. Em uma falha com o servidor ainda acessível, um BACKUP LOG ... WITH NORECOVERY (o tail-log backup) reduz a perda ao que ficou no log ativo — mas só se a cadeia estiver íntegra.

O que costuma aparecer no primeiro teste

Ambientes que nunca restauraram costumam descobrir a mesma família de problemas: bancos críticos em SIMPLE sem que ninguém tenha decidido isso, retenção que expira antes da janela de detecção de um erro lógico, credencial única com acesso de escrita a produção e a backup, arquivos que só existem no mesmo storage do servidor, e CHECKDB que nunca rodou — de modo que a idade real de uma corrupção é desconhecida.

Nenhum desses itens dispara alerta — e é justamente por isso que a idade do último backup validado precisa entrar no monitoramento, junto com os outros sinais que discutimos em quais métricas realmente antecipam um incidente. Todos aparecem no primeiro restore cronometrado.

Próximo passo

Se a resposta para "quanto tempo levamos para voltar" hoje é uma estimativa, e não um número medido, o teste vale mais que qualquer ajuste de job. Escolha o banco mais crítico, restaure em outro servidor, cronometre e rode CHECKDB.

Se preferir que essa leitura seja feita junto com quem faz isso todo dia, a H1 Data oferece um diagnóstico gratuito do ambiente SQL Server: levantamento de RPO e RTO reais, integridade da cadeia de backup e priorização do que precisa mudar primeiro.