RTO y RPO desmitificados
RTO y RPO son los dos números que convierten "tenemos copias de seguridad y réplicas" en una promesa real y comprobable sobre cuán grave puede ser una interrupción.
//
Busca en todas las páginas de la documentación
RTO y RPO son los dos números que convierten "tenemos copias de seguridad y réplicas" en una promesa real y comprobable sobre cuán grave puede ser una interrupción.
Esta página desglosa esos dos acrónimos mecánicamente: qué mide realmente cada uno, qué mecanismos de PostgreSQL los determinan y por qué tratarlos como un único objetivo de diseño en lugar de dos controles independientes conduce a planes de recuperación fallidos.
RPO, objetivo de punto de recuperación, responde a una única pregunta: en el momento en que se restaura el servicio, ¿cuántos datos confirmados recientemente podrían faltar?
RTO, objetivo de tiempo de recuperación, responde a una pregunta diferente: desde el momento en que comienza el fallo, ¿cuánto tiempo hasta que el servicio vuelva a estar utilizable?
Estas son mediciones independientes del mismo incidente, y un mecanismo que es excelente para uno puede ser mediocre para el otro.
Una réplica síncrona, por ejemplo, puede llevar el RPO cerca de cero porque ninguna transacción confirmada se reconoce hasta que existe en dos lugares, pero no hace nada por sí sola para acortar el tiempo que se tarda en detectar un fallo y realizar el corte (cutover).
Una copia de seguridad lógica nocturna, por el contrario, puede restaurarse en cualquier hardware en minutos, proporcionando un RTO razonable para bases de datos pequeñas, pero su RPO está limitado por cuántas horas de escrituras ocurrieron desde la última copia.
Ambos números existen en lo que se entiende mejor como un continuo de protección, que va desde una instantánea local sin replicación en un extremo, pasando por alta disponibilidad en la misma región, hasta recuperación ante desastres cross-region en el otro.
Moverse más allá en ese continuo generalmente reduce tanto el RTO como el RPO, pero cada paso cuesta más en infraestructura, latencia y disciplina operativa.
El resultado práctico de este pensamiento es un registro de niveles (tier registry): una tabla que mapea cada servicio a un RPO y RTO aceptados, de modo que "cuánto podemos perder" y "cuánto tiempo podemos estar inactivos" se convierten en números explícitos y aprobados en lugar de suposiciones.
El RPO no es un único control, está limitado por el eslabón más débil en cualquier cadena de protección que exista realmente para un servicio determinado.
-- Las entradas en tiempo real que definen tu RPO actual, no la política en papel
SELECT now() - pg_last_xact_replay_timestamp() AS replica_replay_lag;
SELECT last_archived_time, failed_count FROM pg_stat_archiver;Si la replicación síncrona garantiza una pérdida cercana a cero para el fallo de un nodo, pero el archivo WAL que alimenta el PITR cross-region tiene un segmento fallido, tu RPO efectivo cross-region es la antigüedad de esa brecha en el archivo, independientemente de lo que muestre la réplica.
El RTO es aún más comúnmente subestimado porque la gente mide solo el paso técnico de restauración e ignora todo lo que lo rodea.
El reloj real del RTO comienza en el momento del fallo e incluye el tiempo de detección, la decisión de declarar un desastre, la ejecución técnica de la restauración o el failover, y la validación de que la aplicación está sirviendo correctamente de nuevo.
Un script de restauración que termina en diez minutos aún puede producir un RTO de noventa minutos si la detección tardó cuarenta minutos y la propagación de DNS y el calentamiento de la aplicación tardaron otros cuarenta.
Es por eso que un simulacro de PITR o un día de juego de DR mide el tiempo de reloj de pared desde un fallo simulado hasta una aplicación validada y funcional, no solo la duración del comando de restauración en sí.
La alta disponibilidad y la recuperación ante desastres a menudo se enmarcan como estrategias separadas, pero mecánicamente son el mismo continuo aplicado en diferentes alcances de fallo: HA maneja la pérdida de un nodo o zona de disponibilidad con failover automatizado en menos de un minuto, mientras que DR maneja la pérdida a escala de región o proveedor con un corte más lento y deliberado.
Los mecanismos se componen en lugar de competir, porque un sistema bien diseñado utiliza replicación síncrona o asíncrona rápida dentro de una región para RTO a nivel de HA, y una ruta cross-region separada y deliberadamente asíncrona para RPO y RTO a nivel de DR, aceptando que la segunda ruta siempre será más lenta que la primera.
Elegir un mecanismo de recuperación significa elegir un punto en la curva de costo RTO/RPO, y la comparación honesta debe incluir lo que cuesta construir y operar cada mecanismo, no solo lo que promete en el papel.
| Mecanismo | RPO Típico | RTO Típico | Costo/Complejidad |
|---|---|---|---|
| Réplica síncrona en la misma región | Casi cero | Segundos a minutos (failover automatizado) | Alto costo de latencia, operaciones moderadas |
| Réplica asíncrona cross-region | Segundos a minutos (retraso de reproducción) | Minutos a una hora (promoción manual o con script) | Alto costo de infraestructura, dependencia de WAN |
| PITR desde backup base + archivo WAL | Minutos (intervalo de archivo) | Decenas de minutos a horas (limitado por la reproducción) | Costo moderado, preciso pero más lento |
| Restauración de backup en frío, sin réplica | Horas (intervalo de backup) | Horas (restauración completa) | Costo más bajo, garantías más débiles |
El patrón de registro de niveles solo se vuelve confiable una vez que está respaldado por números de simulacros medidos en lugar de teóricos, porque un objetivo de RTO documentado de una hora no significa nada si el último simulacro de PITR real tardó cuatro.
Las arquitecturas multiregión agregan una sutileza que los números planos de RTO/RPO ocultan: la latencia de red entre regiones establece un piso en el retraso de replicación que ningún esfuerzo de ingeniería por debajo de la capa de aplicación puede eliminar, por lo que el RPO cross-region siempre tiene un límite inferior físico.
Los marcos de cumplimiento como SOC 2 típicamente se preocupan menos por los números específicos que por la evidencia de que el RTO y el RPO fueron elegidos deliberadamente, documentados y probados periódicamente, lo que significa que el historial de simulacros importa tanto como el objetivo en sí.
El error más costoso en este espacio es optimizar el número que es fácil de medir, generalmente la frecuencia de las copias de seguridad, mientras se ignora el número que realmente determina el impacto en el cliente, que es casi siempre el RTO una vez que se cuentan honestamente los gastos generales de detección y coordinación.
El RPO mide la pérdida de datos, expresada como tiempo o transacciones, mientras que el RTO mide el tiempo de inactividad, expresado como tiempo transcurrido desde el fallo hasta el servicio restaurado.
El script de restauración solo cubre la fase de ejecución, mientras que el RTO real también incluye el tiempo de detección, la decisión de declarar un desastre y la validación posterior a la restauración antes de que se confíe en el tráfico.
Proporciona una pérdida cercana a cero para las transacciones confirmadas dentro del conjunto de réplicas síncronas, pero no protege contra un error que tanto el primario como la réplica síncrona ya hayan confirmado.
Se encuentran en el mismo continuo de protección, con HA cubriendo la pérdida de un nodo o zona de disponibilidad a través de failover automatizado rápido, y DR cubriendo la pérdida a escala de región a través de un corte más lento y deliberado.
Un objetivo de RTO o RPO declarado sin evidencia de prueba es inverificable, por lo que los auditores buscan simulacros documentados que demuestren que el objetivo se logró realmente bajo fallo simulado.
Solo con arquitecturas especializadas que aceptan una latencia de escritura significativa, porque el tiempo de ida y vuelta de la red entre regiones establece un límite físico en cuán actualizada puede ser una copia cross-region.
La segmentación por impacto comercial mantiene el gasto en recuperación ante desastres proporcional al riesgo, ya que una ruta de pagos de nivel 0 y una ruta de análisis interno no tienen el mismo costo de inactividad o pérdida de datos.
El tiempo de detección y decisión, porque los ingenieros a menudo miden solo el paso técnico de restauración o failover y olvidan los minutos dedicados a notar el fallo y declarar un desastre.
No, son independientes, y un mecanismo que minimiza la pérdida de datos, como la replicación síncrona, no acorta por sí solo el tiempo de detección, decisión o validación.
PITR típicamente ofrece un mejor RPO para errores lógicos ya que puede apuntar a una transacción exacta, pero un peor RTO que una réplica precalentada porque requiere la reproducción de WAL antes de que la instancia sea utilizable.
Establecer un objetivo una vez y nunca realizar un simulacro para confirmarlo, lo que convierte una promesa documentada en una suposición no probada que falla exactamente cuando más importa.
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), PgBouncer 1.x, y Patroni 3.x.
Revisado por Chris St. John·Última actualización: 15 jul 2026