Disaster Recovery para SQL Server: o guia completo

Disaster Recovery não é sinônimo de backup — é o plano completo pra voltar a operar depois de perder um datacenter, um servidor, ou um banco inteiro. Backup é uma peça desse plano, não o plano inteiro.

RPO e RTO definem a arquitetura, não o contrário

RPO (Recovery Point Objective) é quanto dado você aceita perder — medido em tempo desde o último ponto recuperável. RTO (Recovery Time Objective) é quanto tempo até voltar a operar. Um RPO de poucos minutos exige log shipping frequente, Always On síncrono ou algo equivalente — backup diário sozinho nunca entrega isso, porque o RPO dele é "desde o último backup", que pode ser até 24 horas.

As opções mais comuns, do mais simples ao mais robusto

• Backup + restore manual — RPO/RTO mais altos, mas mais simples de manter. Adequado quando o negócio tolera horas de indisponibilidade e perda.
• Log shipping — RPO na casa de minutos (intervalo de envio do log), RTO de minutos a horas (restore manual do secundário). Mais barato que Always On, sem failover automático.
• Always On Availability Groups — RPO próximo de zero em modo síncrono, RTO de segundos com failover automático. Exige mais infraestrutura e licenciamento.
• Backup geograficamente distribuído — independente da estratégia acima, backup replicado pra outra região protege contra perda do datacenter inteiro, não só do servidor.

O plano sem teste não é um plano

Um restore que nunca foi testado é uma aposta, não uma garantia — arquivo de backup corrompido, permissão faltando no servidor de destino, ou uma etapa manual esquecida só aparecem no dia do incidente real se ninguém testou antes. Teste de restore programado (mensal ou trimestral, dependendo da criticidade) é a diferença entre um plano de DR e um documento guardado numa pasta.