APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Redundância só ajuda contra falhas que os componentes não partilham. Duas instâncias podem depender do mesmo armazenamento, identidade, rede ou configuração defeituosa. Identifica modos de falha, dependências necessárias e capacidade remanescente. Disponibilidade observada, objetivo de recuperação e tolerância a perda de dados são medidas diferentes. Um RTO define quanto tempo de indisponibilidade é tolerado no âmbito acordado; um RPO define a janela tolerada de perda de dados. Ter backups ou réplicas não demonstra que esses objetivos serão cumpridos. O percurso de recuperação deve incluir dados, aplicação, acesso, integrações e validação funcional por quem consegue reconhecer o resultado correto.
Aplicação guiada
Num exercício original, o RTO é 90 minutos e o RPO é 15. A recuperação demora 70 minutos, mas só existe um ponto recuperável das 03:00 para uma falha às 03:22. Sob a hipótese de não haver logs ou outra recuperação posterior, o tempo cumpre o RTO e a janela de perda de 22 minutos falha o RPO. Não marques o ensaio como totalmente bem-sucedido. Regista lacunas e responsáveis, confirma capacidade do destino e prepara retorno após operação no local alternativo. Nos cenários de APS, inclui dependências batch e ficheiros em trânsito: recuperar servidores sem reconciliar trabalho pode deixar o negócio num estado inconsistente.
70≤90 cumpre o prazo; 22>15 excede a perda tolerada neste exercício.
Armadilhas comuns
Duas réplicas como ausência de falha comum; backup como restauro provado; RTO cumprido como RPO cumprido.
Tópicos relacionados: Requisitos e decisões de arquitetura · Capacidade e latência · Dados e consistência
Valida a recuperação contra cada objetivo e o estado final do negócio.
Referência: Defining reliability targets · System design patterns; PostgreSQL18 scoped examples; primary guidance consulted 2026-09-30