Qué es el RPO y qué es el RTO
El RPO, Recovery Point Objective u objetivo de punto de recuperación, responde a la pregunta: ¿cuánta información puede permitirse perder la empresa en el peor de los casos? Se mide en tiempo, no en volumen de datos, porque expresa la distancia máxima aceptable entre el momento del incidente y la copia de seguridad más reciente disponible. Un RPO de una hora significa que, como máximo, se puede perder una hora de trabajo o de transacciones.
El RTO, Recovery Time Objective u objetivo de tiempo de recuperación, responde a una pregunta distinta: ¿cuánto tiempo puede estar un sistema o un servicio parado antes de que el impacto en el negocio sea inaceptable? Incluye todo el proceso de recuperación: detectar el incidente, decidir activar el plan, restaurar los sistemas y verificar que vuelven a funcionar correctamente.
La diferencia entre ambos conceptos suele resumirse así: el RPO mira hacia atrás en el tiempo, hacia cuánta información se pierde; el RTO mira hacia delante, hacia cuánto tiempo se tarda en volver a estar operativo. Ambos son necesarios porque responden a preguntas de negocio distintas, y una empresa puede tener un RPO muy exigente en un sistema y muy relajado en otro.
Cómo se calculan en la práctica
El RPO y el RTO no se fijan mirando la tecnología disponible, sino analizando el impacto económico y operativo de perder información o de estar parado durante distintos periodos de tiempo. La pregunta de partida es siempre la misma: ¿qué ocurre si este sistema deja de funcionar durante una hora, un día o una semana, y qué ocurre si perdemos los últimos quince minutos, la última hora o el último día de datos?
Para un sistema de facturación o de pedidos online, perder una hora de transacciones puede significar pedidos duplicados, cobros perdidos o clientes afectados de forma directa, lo que empuja el RPO hacia minutos. Para un repositorio de documentación interna que se actualiza poco, perder un día de cambios puede ser perfectamente asumible, con un RPO de veinticuatro horas.
El RTO se calcula de forma parecida, cuantificando el coste de cada hora de parada: ventas no realizadas, penalizaciones contractuales por incumplimiento de nivel de servicio, coste del personal parado o daño reputacional frente a clientes. Cruzando ambos análisis, sistema por sistema, se obtiene una tabla de prioridades que es la que realmente debe guiar el diseño técnico del backup y de la recuperación.
Cómo determinan el diseño técnico
Un RPO exigente, de minutos, obliga a mecanismos de copia mucho más frecuentes que un backup diario tradicional: replicación continua, copias incrementales cada pocos minutos o bases de datos en alta disponibilidad con réplicas síncronas. Un RPO de veinticuatro horas, en cambio, se cubre perfectamente con una copia diaria bien verificada.
Un RTO exigente, de minutos u horas, requiere tener infraestructura de recuperación ya preparada y probada: servidores en espera (standby), plantillas de recuperación automatizadas o servicios de recuperación ante desastres como servicio (DRaaS) que permiten levantar sistemas completos en la nube en cuestión de minutos. Un RTO de varios días, en cambio, puede resolverse con una restauración manual desde backup sobre hardware que se aprovisiona en el momento del incidente.
- RPO bajo (minutos) + RTO bajo (minutos-horas): replicación continua y recuperación automatizada, propio de sistemas críticos de facturación o e-commerce.
- RPO medio (horas) + RTO medio (horas): copias incrementales frecuentes y procedimientos de restauración documentados y ensayados.
- RPO alto (24 h) + RTO alto (días): copia diaria y restauración manual sobre infraestructura aprovisionada en el momento, adecuado para sistemas no críticos.
El error más común: un RPO y RTO únicos para toda la empresa
Muchas empresas definen, sin analizarlo con detalle, un único objetivo de recuperación para toda su infraestructura, normalmente calcado de lo que ofrece por defecto su proveedor de backup. El resultado suele ser doblemente ineficiente: se sobreprotegen sistemas poco críticos, pagando por una frecuencia de copia que no es necesaria, y se infraprotegen los sistemas realmente críticos, que necesitarían objetivos mucho más exigentes de los que reciben.
El enfoque correcto es clasificar los sistemas por niveles de criticidad —crítico, importante, secundario— y asignar a cada nivel su propio RPO y RTO, de modo que el presupuesto de protección se concentre donde el impacto de un fallo es realmente mayor.