RTO & RPO Desmistificados
RTO e RPO são os dois números que transformam "temos backups e réplicas" em uma promessa real e testável sobre o quão ruim uma interrupção pode ficar.
//
Busque em todas as páginas da documentação
RTO e RPO são os dois números que transformam "temos backups e réplicas" em uma promessa real e testável sobre o quão ruim uma interrupção pode ficar.
Esta página analisa esses dois acrônimos mecanicamente: o que cada um realmente mede, quais mecanismos do PostgreSQL os determinam e por que tratá-los como um único alvo de design em vez de dois controles independentes leva a planos de recuperação falhos.
RPO, objetivo de ponto de recuperação, responde a uma única pergunta: no momento em que o serviço é restaurado, quanta informação de dados recentemente confirmada pode estar faltando.
RTO, objetivo de tempo de recuperação, responde a uma pergunta diferente: do momento em que a falha começa, quanto tempo até que o serviço esteja utilizável novamente.
Estas são medições independentes do mesmo incidente, e um mecanismo que é excelente para um pode ser medíocre para o outro.
Uma réplica síncrona, por exemplo, pode levar o RPO para perto de zero porque nenhuma transação confirmada é reconhecida até que ela exista em dois lugares, mas não faz nada por si só para encurtar o tempo necessário para detectar uma falha e fazer o cutover.
Um backup lógico noturno, por outro lado, pode ser restaurado em qualquer hardware em minutos, proporcionando um RTO razoável para bancos de dados pequenos, mas seu RPO é limitado por quantas horas de escritas ocorreram desde o último dump.
Ambos os números existem no que é melhor entendido como um contínuo de proteção, indo de um snapshot local sem replicação em uma ponta, passando por alta disponibilidade na mesma região, até recuperação de desastres cross-region na outra.
Mover-se mais adiante nesse contínuo geralmente reduz tanto o RTO quanto o RPO, mas cada passo custa mais em infraestrutura, latência e disciplina operacional.
O resultado prático desse pensamento é um registro de níveis (tier registry): uma tabela mapeando cada serviço para um RPO e RTO aceitos, de modo que "quanto podemos perder" e "quanto tempo podemos ficar indisponíveis" se tornem números explícitos e assinados em vez de suposições.
RPO não é um único controle, é limitado pelo elo mais fraco em qualquer cadeia de proteção que realmente exista para um determinado serviço.
-- As entradas em tempo real que definem seu RPO atual, não a política no papel
SELECT now() - pg_last_xact_replay_timestamp() AS replica_replay_lag;
SELECT last_archived_time, failed_count FROM pg_stat_archiver;Se a replicação síncrona garante perda próxima de zero para falha de nó, mas o arquivo WAL que alimenta o PITR cross-region tem um segmento falho, seu RPO cross-region efetivo é a antiguidade dessa lacuna no arquivo, independentemente do que a réplica mostra.
O RTO é ainda mais comumente subestimado porque as pessoas medem apenas a etapa técnica de restauração e ignoram tudo ao redor dela.
O relógio real do RTO começa no momento da falha e inclui o tempo de detecção, a decisão de declarar um desastre, a execução técnica da restauração ou failover, e a validação de que a aplicação está realmente servindo corretamente novamente.
Um script de restauração que termina em dez minutos ainda pode produzir um RTO de noventa minutos se a detecção levou quarenta minutos e a propagação do DNS e o aquecimento da aplicação levaram mais quarenta.
É por isso que uma simulação de PITR ou um jogo de dia de DR mede o tempo de relógio de parede desde uma falha simulada até uma aplicação validada e funcionando, não apenas a duração do próprio comando de restauração.
Alta disponibilidade e recuperação de desastres são frequentemente enquadradas como estratégias separadas, mas mecanicamente são o mesmo contínuo aplicado em diferentes escopos de falha: HA lida com perda de nó ou zona de disponibilidade com failover automatizado, em sub-minutos, enquanto DR lida com perda em escala de região ou provedor com um cutover mais lento e deliberado.
Os mecanismos se compõem em vez de competir, porque um sistema bem projetado usa replicação síncrona ou assíncrona rápida dentro de uma região para RTO em nível de HA, e um caminho cross-region separado e deliberadamente assíncrono para RPO e RTO em nível de DR, aceitando que o segundo caminho sempre será mais lento que o primeiro.
Escolher um mecanismo de recuperação significa escolher um ponto na curva de custo RTO/RPO, e a comparação honesta deve incluir o que cada mecanismo custa para construir e operar, não apenas o que ele promete no papel.
| Mecanismo | RPO Típico | RTO Típico | Custo/Complexidade |
|---|---|---|---|
| Réplica síncrona na mesma região | Próximo de zero | Segundos a minutos (failover automatizado) | Alto custo de latência, operações moderadas |
| Réplica assíncrona cross-region | Segundos a minutos (lag de replay) | Minutos a uma hora (promoção manual ou scriptada) | Alto custo de infra, dependência de WAN |
| PITR a partir de backup base + arquivo WAL | Minutos (intervalo de arquivo) | Dezenas de minutos a horas (limitado pelo replay) | Custo moderado, preciso, mas mais lento |
| Restauração de backup frio, sem réplica | Horas (intervalo de backup) | Horas (restauração completa) | Menor custo, garantias mais fracas |
O padrão de registro de níveis só se torna confiável quando é apoiado por números de simulação medidos em vez de teóricos, porque um alvo de RTO documentado de uma hora não significa nada se a última simulação de PITR real levou quatro.
Arquiteturas multirregionais adicionam uma sutileza que os números RTO/RPO planos escondem: a latência da rede entre regiões define um piso para o lag de replicação que nenhum esforço de engenharia abaixo da camada de aplicação pode remover, então o RPO cross-region sempre tem um limite inferior físico.
Frameworks de conformidade como SOC 2 geralmente se importam menos com os números específicos do que com evidências de que RTO e RPO foram deliberadamente escolhidos, documentados e testados periodicamente, o que significa que o histórico de simulação importa tanto quanto o próprio alvo.
O erro mais caro neste espaço é otimizar o número que é fácil de medir, geralmente a frequência de backup, enquanto ignora o número que realmente determina o impacto no cliente, que é quase sempre o RTO, uma vez que a detecção e a sobrecarga de coordenação são contadas honestamente.
RPO mede a perda de dados, expressa como tempo ou transações, enquanto RTO mede o tempo de inatividade, expresso como tempo decorrido da falha até o serviço restaurado.
O script de restauração cobre apenas a fase de execução, enquanto o RTO real também inclui o tempo de detecção, a decisão de declarar um desastre e a validação pós-restauração antes que o tráfego seja confiável.
Ela oferece perda próxima de zero para transações confirmadas dentro do conjunto de réplicas síncronas, mas não protege contra um erro que tanto o primário quanto a réplica síncrona já confirmaram.
Eles estão no mesmo contínuo de proteção, com HA cobrindo falha de nó ou zona de disponibilidade através de failover automatizado rápido, e DR cobrindo perda em escala de região através de um cutover mais lento e deliberado.
Um alvo de RTO ou RPO declarado sem evidência de teste é invificável, então auditores procuram simulações documentadas que mostram que o alvo foi realmente alcançado sob falha simulada.
Apenas com arquiteturas especializadas que aceitam latência de escrita significativa, porque o tempo de ida e volta da rede entre regiões define um piso físico para quão atual uma cópia cross-region pode ser.
O tiering por impacto de negócios mantém os gastos com recuperação de desastres proporcionais ao risco, já que um caminho de pagamentos e um caminho de análise interna não carregam o mesmo custo de tempo de inatividade ou perda de dados.
Tempo de detecção e decisão, porque engenheiros frequentemente medem apenas a etapa técnica de restauração ou failover e esquecem os minutos gastos notando a falha e declarando um desastre.
Não, eles são independentes, e um mecanismo que minimiza a perda de dados, como replicação síncrona, não encurta por si só o tempo de detecção, decisão ou validação.
O PITR geralmente oferece um RPO melhor para erros lógicos, pois pode mirar em uma transação exata, mas um RTO pior do que uma réplica pré-aquecida porque requer replay de WAL antes que a instância esteja utilizável.
Definir um alvo uma vez e nunca executar uma simulação para confirmá-lo, o que transforma uma promessa documentada em uma suposição não testada que falha exatamente quando mais importa.
Versões do Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), PgBouncer 1.x e Patroni 3.x.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026