RPO y RTO a fondo

La lección de recuperación ante desastres define RPO y RTO y compara las cuatro estrategias. Decir «nuestro RPO es de 15 minutos» es fácil. Saber cuántos datos perderías si todo fallara ahora mismo exige medir, y saber cuánto tardarías en volver exige descomponer ese tiempo y practicarlo.

La línea de tiempo de un desastre

Una tienda en línea respalda su base de datos cada hora. La última copia buena terminó a las 14:00. A las 14:40 la base se corrompe. El servicio vuelve a las 16:10.

El RPO mira hacia atrás desde la falla: perdiste 40 minutos de pedidos. El RTO mira hacia adelante: estuviste 90 minutos sin vender. Son independientes. Puedes tener un RPO de segundos (réplica al día) y un RTO de horas (nadie sabe cómo promoverla), o al revés.

Objetivo contra valor real

El caso típico: el objetivo dice 15 minutos de RPO, pero los respaldos corren cada hora. En el peor momento, justo antes del siguiente respaldo, el RPO efectivo es de casi 60 minutos. Nadie mintió; nadie midió.

De qué está hecho el RTO

Los 90 minutos del ejemplo se reparten así:

1. 1

   Detección · 12 min

   Desde la falla hasta que una alarma suena y alguien la mira. Depende de qué tan bien mides y de quién está de guardia.
2. 2

   Evaluación y decisión · 33 min

   Entender qué pasó y decidir: ¿esperar a que se arregle o recuperar? ¿Desde qué copia? ¿Quién lo autoriza?
3. 3

   Recuperación de datos · 20 min

   Restaurar el respaldo o promover la réplica. Restaurar crea un recurso nuevo y tarda más mientras más datos haya.
4. 4

   Recuperación de la aplicación · 10 min

   Apuntar la aplicación a la base nueva, actualizar secretos y configuración, reiniciar procesos.
5. 5

   Redirección del tráfico · 5 min

   Cambiar DNS o rutas para que los usuarios lleguen al lugar correcto, y esperar a que los clientes lo noten.
6. 6

   Validación · 10 min

   Comprobar con transacciones de prueba que todo funciona antes de anunciar que volviste.

La decisión suele ser la parte más grande. Nadie quiere declarar un desastre con información incompleta, y si no está escrito quién decide y con qué criterio, la reunión se alarga. Lo que acorta el RTO no es un servicio más rápido, sino un criterio acordado de antemano: «si la base no responde en 15 minutos y AWS confirma un problema en la región, recuperamos». Eso va en el runbook; lo verás en runbooks y simulacros.

Medir el RPO efectivo todo el tiempo

Si te protegen réplicas, tu RPO efectivo es el retraso de replicación: lo que aún no cruzó a la copia. Si te protegen respaldos, es el tiempo desde el último punto consistente que puedes restaurar. Ambos se pueden graficar y alarmar en CloudWatch:

Objetivos por nivel de criticidad

No todo merece el mismo RPO y RTO. Clasifica tus sistemas en niveles (tiers) y asigna a cada uno un objetivo, una estrategia y un presupuesto. Estos valores son un ejemplo inventado; los tuyos salen de cuánto cuesta cada hora caída o perdida:

La curva de costo no es lineal. Pasar de 24 horas a 1 hora de RPO es barato: respaldos más frecuentes. Pasar de 1 minuto a casi cero exige replicación continua, una segunda región con capacidad lista y aplicaciones preparadas para cambiar de región. Mientras más cerca de cero, más caro cada segundo que ganas.

Disponibilidad no es RPO ni RTO

Un SLA de 99,9 % dice cuánto tiempo puede estar caído el servicio en un periodo (unos 43 minutos al mes, ver la tabla de alta disponibilidad). No dice cuántos datos pierdes. Un sistema con 99,99 % de disponibilidad puede perder un día entero de datos si alguien ejecuta un borrado masivo y la única copia es una réplica que copió el borrado. Y un solo incidente con 4 horas de RTO consume casi la mitad del presupuesto anual de un 99,9 % (8,76 horas). Son tres números distintos y necesitas los tres.

Qué ofrece AWS para cada objetivo

El RPO depende de cómo replicas: sigue con replicación y consistencia. El RTO depende de qué tan rápido y seguro cambias de región: lo verás en failover y failback.