Dos siglas resumen toda una estrategia de continuidad, y casi todo el mundo las confunde o las usa mal. RTO y RPO son las dos preguntas que definen tu plan de recuperación ante desastres, y entenderlas bien es la diferencia entre un DR proporcionado y uno que cuesta el triple de lo necesario, o que no te salva cuando hace falta.
Vamos a explicarlas sin abstracciones y, sobre todo, a enseñarte a calcular las tuyas. Porque pedir “RTO y RPO a cero” para todo, que es la reacción instintiva, es una de las decisiones más caras y peor pensadas que se ven en infraestructura.
Una imagen que lo fija: imagina una línea de tiempo con el desastre en el centro. El RPO mira a la izquierda (cuántos datos perdidos antes del incidente). El RTO mira a la derecha (cuánto tiempo hasta recuperar después). No son lo mismo y se diseñan con tecnologías distintas.
Un RPO bajo se consigue con replicación frecuente de datos: copias cada minuto, o replicación síncrona para RPO cero. Eso cuesta en almacenamiento, red y, sobre todo, en ancho de banda entre sitios.
Un RTO bajo se consigue con infraestructura lista para arrancar: nodos en espera, orquestación de failover, recursos reservados en el sitio secundario. Eso cuesta en hardware que está ahí “por si acaso”.
Son dos facturas distintas. Puedes querer RPO casi cero pero tolerar un RTO de unas horas (no pierdo datos, pero tardo en levantar todo), o al revés. Tratarlos como una sola cosa, o pedir ambos a cero indiscriminadamente, multiplica el coste sin necesidad.
El error más común es definir un único RTO/RPO para toda la organización. No todas las cargas valen lo mismo. El ERP que factura no es el servidor de pruebas. Clasifica:
| Carga | RTO razonable | RPO razonable | Mecanismo |
|---|---|---|---|
| ERP / facturación crítica | Minutos | Casi 0 | Replicación síncrona + failover automático |
| Aplicaciones de negocio | 1-4 horas | 15-60 min | Replicación asíncrona + DR orquestado |
| Servicios internos | 4-24 horas | Varias horas | Backup + restauración planificada |
| Entornos de prueba | Días | Último backup | Backup estándar |
Asignar a cada carga el nivel que de verdad necesita es lo que hace que un DR sea sostenible. Pagar replicación síncrona para el servidor de pruebas es tirar dinero; tolerar 24 horas de caída en el ERP puede cerrar la empresa.
RTO y RPO no son decisiones técnicas, son decisiones de negocio que luego se implementan con tecnología. Las preguntas que hay que hacer, carga por carga:
Cuando cruzas el coste de la caída con el coste de la protección, el RTO/RPO correcto aparece casi solo. Es un ejercicio de proporcionalidad, no de aspiración.
Un RTO sobre el papel no vale nada hasta que lo cronometras en un simulacro real. El día del desastre siempre aparecen sorpresas: dependencias no documentadas, un orden de arranque equivocado, una credencial caducada. Un plan de DR que nunca se ha ensayado es un RTO teórico, no real. Ensaya, mide el tiempo de verdad y ajusta.
RTO y RPO no son jerga: son las dos preguntas que definen cuánto puedes perder y cuánto puedes esperar. Defínelos por carga, calcúlalos cruzando coste de caída con coste de protección, y luego, esto es lo importante, pruébalos. Pedir todo a cero es caro e innecesario; no medirlo es jugársela.
Si quieres dimensionar tu DR con cabeza (el nivel justo para cada carga, ni de más ni de menos) y operarlo y probarlo periódicamente, eso es exactamente lo que hacemos en Disaster Recovery. Partimos de tus cargas reales, no de un catálogo.