El RTO (objetivo de tiempo de recuperación) es el tiempo máximo que un sistema puede permanecer caído tras una interrupción. El RPO (objetivo de punto de recuperación) es la mayor cantidad de datos que puede permitirse perder, medida como el tiempo transcurrido desde la última copia utilizable. Un RTO de 4 horas y un RPO de 15 minutos significan: volver a estar operativo en un máximo de 4 horas, perdiendo como mucho 15 minutos de datos.
Puntos clave
- El RTO mira hacia delante desde la caída (cuánto falta para recuperar el servicio). El RPO mira hacia atrás (qué antigüedad tiene la última copia válida de los datos).
- Ambos son decisiones de negocio. Defínalos por sistema mediante un análisis de impacto en el negocio y elija después la tecnología que los cumpla.
- La frecuencia de las copias de seguridad limita su RPO: con copias cada 4 horas, la pérdida de datos en el peor caso es de unas 4 horas.
- Cuanto más bajos son los objetivos, más cuestan. Un RTO/RPO cercano a cero exige replicación y capacidad en espera en una segunda ubicación.
- Los objetivos sobre el papel valen poco hasta que una prueba ha medido el tiempo de recuperación y la pérdida de datos reales.
¿Qué es el RTO en la recuperación ante desastres?
El RTO es el tiempo máximo aceptable entre la caída de un servicio y su restablecimiento. AWS lo define como «el retraso máximo aceptable entre la interrupción del servicio y su restablecimiento» en su documento técnico Disaster Recovery of Workloads on AWS. NIST lo plantea desde el negocio: el tiempo que un sistema puede estar en recuperación «antes de afectar negativamente a la misión de la organización o a sus procesos de misión y de negocio».
El RTO abarca toda la recuperación, no solo la restauración técnica. La detección, la decisión de activar el plan de DR, la restauración de los datos, la validación de la aplicación y el traspaso de los usuarios cuentan contra él. Los equipos que solo cronometran la restauración suelen incumplir su RTO en un incidente real.
¿Qué es el RPO en la recuperación ante desastres?
El RPO es la pérdida máxima aceptable de datos, expresada en tiempo. AWS lo llama «la cantidad máxima aceptable de tiempo desde el último punto de recuperación de datos». Si su RPO es de 1 hora, tras un fallo debe poder restaurar datos con una antigüedad máxima de 1 hora.
El RPO depende de la frecuencia con que se copian los datos. Las copias nocturnas dan un RPO de unas 24 horas en el peor caso. Las copias de registros de la base de datos cada 15 minutos dan aproximadamente 15 minutos. La replicación continua puede acercarlo a cero, con una salvedad que se explica más abajo: la replicación copia también la corrupción y los borrados.
RTO frente a RPO: la diferencia de un vistazo
| RTO | RPO | |
|---|---|---|
| Pregunta que responde | ¿Cuánto tiempo podemos estar caídos? | ¿Cuántos datos podemos perder? |
| Dirección en el tiempo | Hacia delante desde la caída | Hacia atrás desde la caída |
| Se mide como | Tiempo hasta restablecer el servicio | Antigüedad del último punto de recuperación utilizable |
| Palancas principales | Capacidad en espera, automatización, infraestructura como código, runbooks | Frecuencia de copias, replicación, recuperación a un punto en el tiempo |
| Fallo típico | Pasos manuales, accesos que faltan, DNS y dependencias | Copias que fallan sin avisar o réplicas que copiaron la corrupción |
Ejemplos prácticos
Ejemplo 1: un sistema de pedidos. Una tienda en línea fija un RTO de 4 horas y un RPO de 15 minutos. La base de datos falla a las 10:00. La tienda debe volver a aceptar pedidos a las 14:00 y, como máximo, pueden faltar los pedidos realizados entre las 09:45 y las 10:00. Las copias nocturnas no lo permiten; la tienda necesita copias de registros de transacciones o replicación al menos cada 15 minutos, además de una forma automatizada de reconstruir la capa de aplicación en menos de 4 horas.
Ejemplo 2: revisar un calendario de copias. Un sistema financiero tiene copia cada 6 horas y una restauración completa lleva 3 horas. Si el negocio pide un RPO de 1 hora y un RTO de 2 horas, no se cumple ninguno de los dos: la pérdida de datos en el peor caso es de unas 6 horas y solo la restauración ya supera el RTO. La solución es aumentar la frecuencia de las copias y usar un método de recuperación más rápido, o bien que el negocio decida aceptar objetivos más holgados.
Ejemplo 3: clasificar un portafolio por niveles. La mayoría de las empresas agrupa los sistemas en niveles en lugar de fijar objetivos uno por uno. Las cifras de la tabla son ilustrativas, no un estándar.
| Nivel | Sistemas de ejemplo | RTO ilustrativo | RPO ilustrativo | Estrategia de DR probable |
|---|---|---|---|---|
| 1. Crítico para la misión | Pagos, plataforma SaaS de cara al cliente | Minutos | De casi cero a minutos | Warm standby o multisitio activo/activo |
| 2. Crítico para el negocio | ERP, CRM, gestión de pedidos | De 1 a 4 horas | De 15 a 60 minutos | Pilot light o warm standby |
| 3. Importante | Informes, herramientas internas | 24 horas | 24 horas | Copia de seguridad y restauración |
| 4. No crítico | Pruebas y desarrollo | Días | Días, o reconstrucción desde el código | Copia de seguridad y restauración o nuevo despliegue |
La columna de estrategia sigue los cuatro enfoques del documento técnico de AWS, donde la copia y restauración recupera en horas y el multisitio activo/activo en casi tiempo real. Nuestra guía sobre el plan de recuperación ante desastres explica cada estrategia y cómo elegir.
¿Cómo se relacionan el RTO y el RPO con el tiempo máximo tolerable de inactividad?
El tiempo máximo tolerable de inactividad (MTD) es el tiempo que un proceso de negocio puede estar interrumpido antes de que el daño sea grave. NIST SP 800-34 explica que el RTO «normalmente debe ser más corto que el MTD», porque, una vez restablecidos los sistemas, el personal aún necesita tiempo para ponerse al día con el trabajo acumulado y volver a introducir los datos perdidos. El RPO no forma parte del MTD: describe cuántos datos puede permitirse perder el proceso (NIST SP 800-34 Rev. 1).
En la práctica: si el proceso de pedidos puede sobrevivir 8 horas sin sistemas y ponerse al día lleva 2 horas, el RTO de TI debe ser de 6 horas o menos.
Cómo definir el RTO y el RPO
- Enumere los procesos de negocio y sus dependencias. Asocie cada proceso con las aplicaciones, bases de datos, servicios de identidad y terceros que necesita.
- Estime el impacto de la inactividad y la pérdida de datos a lo largo del tiempo. Ingresos, penalizaciones contractuales, exposición regulatoria, seguridad y reputación. AWS señala que el impacto puede depender del momento: una caída de la nómina justo antes del día de pago importa mucho más que una justo después.
- Proponga objetivos por nivel y deje que el responsable de negocio los apruebe. TI no debe elegirlos por sí sola.
- Calcule el coste de las opciones. AWS aconseja que, si la estrategia de recuperación cuesta más que el fallo del que protege, «no debe implantarse salvo que exista un motivo secundario, como requisitos regulatorios».
- Diseñe y pruebe. Construya los mecanismos de copia, replicación y conmutación por error, ejecute una prueba y registre el tiempo y el punto de recuperación logrados.
- Revise cada año y tras los cambios importantes. Los sistemas pasan de un nivel a otro a medida que cambia el negocio.
¿Qué tecnologías cumplen qué objetivos?
- Las copias programadas y las instantáneas sirven para RPO de horas. Protegen bien frente a la corrupción y el borrado, porque cada copia es un punto fijo en el tiempo.
- La recuperación a un punto en el tiempo (copias de registros de la base de datos) reduce el RPO a minutos en las bases de datos.
- La replicación asíncrona a otra región da un RPO de segundos a minutos, según el retardo de replicación.
- La replicación síncrona entre zonas de disponibilidad da un RPO cercano a cero, a costa de la latencia de escritura. La guía de recuperación ante desastres de Azure Well-Architected de Microsoft sugiere replicación síncrona entre zonas para los datos de alta prioridad y replicación asíncrona entre regiones para los de menor prioridad.
- Los entornos en espera y la automatización (pilot light, warm standby, infraestructura como código, conmutación de DNS automatizada) reducen el RTO.
Cuidado con la trampa de la replicación. AWS señala que la replicación continua «puede no proteger frente a desastres como la corrupción de datos o un ataque malicioso» tan bien como las copias a un punto en el tiempo. Una base de datos cifrada por ransomware se replica igual de rápido que una sana, así que conserve copias a un punto en el tiempo junto a las réplicas.
Cómo demostrar que cumple sus objetivos
Mida, no suponga. En cada prueba de DR, anote cuándo empezó la caída, cuándo se activó el plan, cuándo volvió el servicio y la marca de tiempo de la última transacción recuperada. Eso le da el RTO y el RPO logrados. La guía de Microsoft recomienda combinar ejercicios de mesa, simulacros en entornos de no producción y simulacros a nivel de producción. Siga los resultados a lo largo del tiempo y corrija primero el paso más lento.
Cómo ayuda Opsio
Opsio organiza talleres de impacto en el negocio, define el RTO/RPO por nivel con sus responsables de negocio y construye y prueba el diseño de recuperación correspondiente en AWS y Azure mediante su servicio de recuperación ante desastres en la nube. Para la plataforma SaaS de reclutamiento WorkBuster, un enfoque de inactividad casi nula era un requisito imprescindible cuando Opsio migró la plataforma a AWS. El diseño utiliza una base de datos MySQL multi-AZ de alta disponibilidad en Amazon RDS, con la infraestructura definida en plantillas de CloudFormation.
Preguntas frecuentes
¿Cuál es la diferencia entre RTO y RPO?
El RTO es el tiempo que un sistema puede estar no disponible tras una interrupción. El RPO es la cantidad de datos, medida en tiempo, que puede permitirse perder. El RTO trata de la inactividad; el RPO, de la pérdida de datos.
¿Qué es un buen RTO y RPO?
No hay una cifra universal. Un sistema de pagos puede necesitar minutos en ambos, mientras que una herramienta interna de informes puede aceptar 24 horas. Obtenga los objetivos del coste de la inactividad y de la pérdida de datos de cada proceso de negocio y compruebe después el coste de cumplirlos.
¿Puede ser cero el RPO?
Casi cero, sí, con replicación síncrona o diseños multisitio activo/activo. Garantizar una pérdida de datos exactamente nula entre regiones es difícil por la distancia y la latencia, y la replicación por sí sola no protege frente a la corrupción.
¿Es el RTO lo mismo que un SLA?
No. Un SLA es una promesa a los clientes sobre disponibilidad o tiempo de respuesta. El RTO es un objetivo interno de recuperación para un escenario de desastre. Su RTO debe respaldar sus SLA, pero se miden de forma distinta.
¿Con qué frecuencia deben revisarse los objetivos de recuperación?
Al menos una vez al año y tras cambios importantes en los sistemas, los proveedores o el negocio. Vuelva a medirlos en cada prueba de DR, porque lo que cuenta son los valores logrados.
Lectura relacionada: Qué es Rto y Rpo en Aws.
Escrito por
Group COO & CISO
Fredrik es el COO y CISO del grupo en Opsio. Se centra en la excelencia operativa, la gobernanza y la seguridad de la información, trabajando estrechamente con los equipos de entrega y liderazgo para alinear tecnología, riesgo y resultados de negocio en entornos de TI complejos. Lidera la práctica de seguridad de Opsio, incluyendo servicios SOC, pruebas de penetración y marcos de cumplimiento.
Normas editoriales: Este artículo lo ha escrito el profesional cloud indicado arriba. Lo actualizamos cuando cambia la tecnología o la normativa que trata; las fechas de esta página indican la última actualización. Opsio mantiene su independencia editorial.