APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
RTO mede o objetivo de tempo para recuperar serviço; RPO trata a perda de dados tolerada. Um restauro de 18 minutos seguido de oito de configuração e dez de validação demora 36 minutos, se as etapas forem sequenciais. Não pode ser apresentado como cumprimento de um RTO de 30 minutos só porque os dados regressaram depressa. Inclui identidade, quotas, capacidade e dependências. Warm standby mantém uma aplicação funcional com capacidade reduzida; pilot light conserva elementos essenciais mas ainda exige ativar mais componentes. Os rótulos ajudam a comparar desenho e custo, mas não garantem os tempos reais do teu serviço.
Aplicação guiada
Em Aurora Global Database, distingue switchover planeado com regiões saudáveis de failover após desastre. A promoção de emergência pode envolver perda associada à replicação assíncrona; a última medição de lag não prova exatamente quais as transações perdidas. Prepara autoridade de escrita e reconciliação. Nas releases blue/green, mover tráfego não reverte alterações destrutivas de esquema. Uma sequência de expansão, código compatível, migração e remoção posterior permite manter alternativas durante a transição, desde que ensaiadas. Para eliminação lógica replicada, a segunda região pode conter o mesmo erro. É necessário um ponto histórico recuperável e uma forma validada de restaurar, não apenas outra cópia do estado atual.
Blue continua disponível, mas green eliminou uma coluna que blue utiliza. Voltar o tráfego não restaura essa coluna.
Armadilhas comuns
Replicação como backup histórico; lag como perda exata; promoção como prontidão completa; rollback de tráfego como rollback de dados.
Tópicos relacionados: Segurança, desempenho e custo no desenho · Operação, evidência e remediação
Desenha e ensaia a recuperação do estado e do serviço, com critérios de decisão explícitos.
Referência: Disaster recovery options on AWS · SAP-C02