| Nível (proposto) | Disponibilidade | Padrão | RPO / RTO |
|---|---|---|---|
| Padrão | 99,7% | Banco de dados de alta disponibilidade (HA) multizona, backups isolados da internet (air-gapped) | Zona: RPO ≈ 0. Região: restaurar do cofre. |
| Live DR | 99,9% | Uma segunda região em funcionamento ao vivo | RPO segundos, RTO ≤ 15 min |
| Live DR | 99,95% | Trânsito em ambas as regiões, prioridade 24 horas por dia, 7 dias por semana. | RPO em segundos, RTO ≤ 5 min |
A inatividade é de 95%. A disponibilidade é medida mensalmente na entrada da TRANXACT, excluindo o período de manutenção acordado (proposto de 4 horas por mês).
Defina a camada antes de dimensionar. O Live DR (Recuperação de Desastres em Tempo Real) ocupa uma segunda região completa e praticamente dobra o custo da infraestrutura em tempo de execução; mostre-o como uma linha separada, referente ao custo de inatividade que ele elimina.
Viva, não seja passivo
Um sistema de espera passivo permanece ocioso, é testado apenas uma vez por ano, se tanto, e realiza o failover restaurando e escalando. Um sistema de recuperação Live DR executa um cluster completo e um banco de dados replicado continuamente, que atende a leituras, relatórios, ASK e postagens sintéticas o dia todo. O failover é uma prática comum — nada é reconstruído — e sua integridade é comprovada a cada minuto.
| Teste | Impacto | Com que frequência | Categoria |
|---|---|---|---|
| Verificação contínua — lançamentos sintéticos, alertas de atraso, soma de verificação do livro-razão entre regiões | Nenhum | A cada minuto | Padrão (TO_4.10.01) |
| Simulação de transição planejada — pausa nas escritas, promoção, mudança, verificação; troca de funções | A escrita foi pausada por alguns segundos. | Trimestral | Padrão (TO_4.10.03) |
| Exercício adicional de transição | A escrita foi pausada por alguns segundos. | Sob encomenda, com 2 semanas de antecedência. | Adicional (TO_4.10.04) |
| Drill isolado — um clone cercado com integrações desativadas | Nenhum em produção | Sob encomenda, com 2 semanas de antecedência. | Adicional (TO_4.10.05) |
| Teste de restauração de sala limpa | Nenhum em produção | Anual | Padrão (TO_4.9.07) |
| Validação do negócio após um teste | Esforço do cliente | Cada exercício | Excluído (TO_4.10.06) |
Cópias de segurança
| Banco de dados de produção | Banco de dados não produtivo | |
|---|---|---|
| Levado | Captura instantânea diária + registros contínuos | Resumo diário |
| Recuperar para | Em qualquer momento dentro de 30 dias | Última foto, 14 dias atrás |
| Cópia do cofre | Diário, imutável, 90 dias | Semanal, imutável, 30 dias |
Os documentos são versionados continuamente e copiados diariamente para o cofre para produção. A infraestrutura como código e a configuração também estão no cofre, portanto, o ambiente de execução é reconstruído a partir do código, em vez de restaurado.
Por que o cofre?
A replicação protege contra interrupções, não contra corrupção. Ransomware ou dados corrompidos são replicados para o ambiente de espera e para a região de recuperação de desastres em segundos. O cofre é uma conta separada com identidades e chaves distintas, sem caminho de rede a partir da produção, retenção de dados única que nem mesmo os administradores podem reduzir e exclusão com dupla aprovação. As restaurações a partir dele são feitas em um ambiente isolado — são verificadas, reconciliadas e, em seguida, promovidas — nunca diretamente para a produção.
Uma vez definido, o período de retenção não pode ser reduzido. Estenda-o antecipadamente se houver necessidade de auditoria ou retenção legal, e dimensione as cópias de longo prazo com base no crescimento do livro-razão e no volume de documentos, não no tamanho atual do banco de dados.
A Calderwood escolheu o Live DR com 99,9% de disponibilidade em uma segunda região do Azure na mesma jurisdição. Seu primeiro teste de transição e uma restauração em ambiente controlado estão agendados antes da entrada em produção, como etapas de verificação de prontidão. Seus parceiros bancários e de folha de pagamento estão incluídos no plano de transição para que seus endpoints sigam o gerenciador de tráfego.
Experimente Um processo em lote corrompeu 4.000 faturas da Calderwood às 14h05. O ambiente de recuperação de desastres Live DR está íntegro, com um atraso de 2 segundos. A migração para o ambiente de DR resolveria o problema?
Não. A corrupção se replicou ao servidor de standby e à região de recuperação de desastres segundos após ocorrer — o failover leva você aos mesmos dados corrompidos. A solução é uma restauração pontual para as 14h04 (TO_4.9.05, Standard) ou, se o histórico em si for suspeito, uma restauração limpa a partir do cofre (TO_4.9.06), com o controlador financeiro aprovando os dados restaurados (TO_4.9.11).