Cuando una empresa diseña su plan de continuidad, la conversación tiende a saltar directo a la tecnología: qué replicar, qué región usar, qué herramienta comprar. Es el orden equivocado. Todo plan de continuidad y de disaster recovery se apoya en dos números que define el negocio: el RTO y el RPO. Sin esos dos valores, cualquier decisión de arquitectura es una apuesta.
Este artículo explica qué son, en qué se diferencian y cómo se fijan — en lenguaje de negocio, porque son una decisión de negocio antes que técnica.
¿Qué es el RTO?
El RTO (Recovery Time Objective) es el tiempo máximo aceptable entre la interrupción de un servicio y su restauración. Responde a una pregunta directa: ¿cuánto tiempo podemos estar caídos sin que el daño sea inaceptable?
Si el RTO de tu plataforma de ventas es de una hora, significa que, ocurra lo que ocurra, el negocio necesita que ese servicio vuelva a operar en menos de sesenta minutos. Ese objetivo condiciona todo lo demás: la arquitectura, el nivel de automatización de la recuperación y el presupuesto que la sostiene.
El RTO no es una aspiración técnica; es un límite de tolerancia. Cuanto más corto, más infraestructura lista y más automatización se necesitan para cumplirlo — y más cuesta mantenerlo.
¿Qué es el RPO?
El RPO (Recovery Point Objective) es la cantidad máxima de datos que el negocio puede permitirse perder, medida en tiempo. Responde a otra pregunta: si tenemos que recuperar, ¿hasta qué punto hacia atrás podemos volver?
Un RPO de cinco minutos quiere decir que, tras un incidente, en el peor caso se pierden los últimos cinco minutos de transacciones. Para cumplirlo, los datos deben copiarse o replicarse al menos con esa frecuencia. Un RPO de veinticuatro horas — un respaldo diario — es mucho más barato de sostener, pero implica aceptar que un desastre puede borrar un día entero de operación.
El RPO traduce una pregunta incómoda en un número concreto: ¿cuántos datos estamos dispuestos a perder? La respuesta honesta casi nunca es “ninguno”, porque el costo de un RPO de cero es altísimo. La respuesta correcta es la que equilibra el valor de esos datos contra lo que cuesta protegerlos.
RTO y RPO: la diferencia que importa
Es la confusión más común. Los dos son objetivos de recuperación, pero miden cosas distintas:
| Aspecto | RTO | RPO |
|---|---|---|
| Qué mide | Tiempo de indisponibilidad | Pérdida de datos |
| Pregunta que responde | ¿Cuánto podemos estar caídos? | ¿Cuántos datos podemos perder? |
| Se expresa en | Tiempo hasta restaurar el servicio | Tiempo de datos “hacia atrás” |
| Lo que exige para bajar | Infraestructura lista y automatización de failover | Replicación de datos más frecuente |
| Ejemplo | ”El core debe volver en 15 minutos" | "No podemos perder más de 1 minuto de transacciones” |
Un mismo sistema puede tener un RTO holgado y un RPO exigente, o al revés. Un almacén de datos analítico quizá tolere estar caído medio día (RTO alto) pero no puede perder registros contables (RPO bajo). Una web institucional puede tolerar perder los últimos cambios (RPO alto) pero necesita volver rápido a estar en línea (RTO bajo). Separarlos es lo que permite proteger cada cosa por lo que realmente vale.
Los números los define el negocio, no TI
El error de fondo más caro es tratar el RTO y el RPO como parámetros técnicos. No lo son: salen del costo que tiene para el negocio cada hora de caída y cada dato perdido.
Ese costo incluye ingresos que dejan de entrar, penalidades contractuales, impacto reputacional y, en sectores regulados, exposición frente al supervisor. Es una conversación de dirección, riesgo y finanzas — TI la traduce después en arquitectura, pero no la origina.
De ahí una regla práctica: definir RTO y RPO por carga de trabajo, no para toda la empresa. Clasificar los sistemas por criticidad y asignar a cada grupo los objetivos que su valor justifica evita el doble error de proteger de más lo que no lo necesita y de más de menos lo que sostiene el negocio.
Un ejemplo concreto
Una empresa de consumo masivo con operación digital podría clasificar así sus cargas:
- Canal de ventas y pagos: cada minuto caído es venta perdida y clientes frustrados. RTO de minutos, RPO cercano a cero. Justifica una arquitectura de recuperación robusta y de mayor costo permanente.
- Sistemas de back office (facturación, inventario): toleran una interrupción breve, pero no pueden perder registros. RTO de decenas de minutos, RPO bajo.
- Reporting y analítica interna: pueden esperar; su caída no detiene la operación ni la venta. RTO de horas, RPO de horas. Un esquema de respaldo y restauración es suficiente.
Tres perfiles de negocio, tres pares de RTO/RPO, tres estrategias. Forzar a todos al estándar del canal de ventas dispararía el costo sin agregar valor; forzarlos al del reporting pondría en riesgo la operación. La disciplina está en asignar a cada carga lo que le corresponde.
Errores comunes al definir RTO y RPO
- Pedir “cero y cero” por defecto. RTO cero y RPO cero son técnicamente posibles, pero su costo rara vez se justifica fuera de las cargas más críticas. La pregunta útil no es “¿queremos perder datos?” sino “¿cuánto vale evitar perderlos?”.
- Definirlos una vez y archivarlos. El valor de cada sistema cambia con el negocio. Los objetivos de recuperación se revisan periódicamente, no se fijan para siempre.
- Confundir tener respaldos con tener un plan. Un backup protege los datos (ayuda al RPO), pero no garantiza el RTO: sin infraestructura donde restaurar y sin un procedimiento probado, volver a operar puede tardar mucho más de lo tolerable.
- No probar la recuperación. Un RTO y un RPO en un documento son una promesa; solo un ensayo real demuestra que la arquitectura los cumple de verdad.
De los números a la estrategia
Una vez fijados el RTO y el RPO de cada carga, la pregunta siguiente es qué arquitectura los cumple al menor costo. AWS define cuatro estrategias oficiales de recuperación — backup & restore, pilot light, warm standby y multi-sitio activo-activo — ordenadas justamente por el RTO y el RPO que alcanzan y por su costo relativo.
El detalle de cómo elegir entre ellas está en nuestra guía de decisión: disaster recovery en AWS: cómo elegir entre las 4 estrategias oficiales. Y cuando la exigencia de RTO/RPO lleva a operar en más de una región, esa paridad se diseña y se sostiene con arquitectura multi-región e infraestructura como código.
Cómo empezar
El primer paso no es comprar tecnología: es saber qué RTO y qué RPO puede cumplir hoy tu arquitectura, y qué distancia hay entre eso y lo que el negocio necesita. Una revisión Well-Architected sobre el pilar de confiabilidad entrega exactamente ese diagnóstico: los riesgos priorizados y la brecha entre el plan escrito y la capacidad real.
En Caleidos ayudamos a traducir el valor de cada sistema en objetivos de recuperación concretos, y a construir la arquitectura que los cumple sobre AWS. Conversemos sobre tu continuidad de negocio y te decimos, con evidencia, qué RTO y RPO puede cumplir tu operación actual.
