Cuando un sistema cae, dos preguntas deciden el nivel de impacto: cuánto tiempo puede estar parado y cuántos datos se pueden perder. Tanto si diseñas cloud backup como un CPD de respaldo, todo empieza por fijar RTO y RPO con el cliente.
Esas dos cifras convierten un plan de recuperación en un compromiso medible. Sin ellas, cualquier plan es una declaración de intenciones que nadie puede auditar ni comprobar.
Qué es el RTO y qué es el RPO, con un ejemplo práctico
RTO y RPO son los dos objetivos que fijan cuánto puede durar una interrupción y cuántos datos se pueden perder en ella.
- RTO (Recovery Time Objective): tiempo máximo que un sistema puede estar parado antes de causar un daño inaceptable.
- RPO (Recovery Point Objective): cantidad máxima de datos, medida en tiempo, que la organización acepta perder.
Un ejemplo: una tienda online vende sobre todo por las tardes y registra sus pedidos en una base de datos. Si el negocio acepta como máximo dos horas sin vender, su RTO es de dos horas. Si puede reconstruir a mano los pedidos de los últimos 15 minutos, pero no más, su RPO es de 15 minutos.
Con esas dos cifras, el diseño técnico se deduce solo: una copia o réplica cada 15 minutos y un procedimiento capaz de devolver la tienda al aire en menos de dos horas.
Diferencias entre RTO y RPO que conviene no confundir
La diferencia entre RTO y RPO es de dirección en el tiempo: el RPO mira hacia atrás, al último punto de recuperación válido, mientras que el RTO mira hacia delante, al momento en que el servicio vuelve a funcionar.
- Qué mide: el RPO mide datos perdidos y el RTO mide tiempo de inactividad.
- De qué depende: el RPO, de la frecuencia de copia, y el RTO, de la velocidad de restauración.
- Qué lo encarece: bajar el RPO exige copiar más a menudo, y bajar el RTO exige infraestructura preparada.
Entender los dos conceptos es clave: una copia diaria con restauración rápida ofrece un RTO bajo, pero un RPO de hasta 24 horas, siempre que esa copia sobreviva a un ataque, por eso conviene que sea un backup inmutable.
Cómo calcular las dos cifras para cada aplicación
RTO y RPO se calculan por aplicación, no por empresa. Un correo interno y una pasarela de pago no toleran lo mismo, y tratarlos igual lleva a pagar de más en unos sistemas y a quedarse corto en otros.
La herramienta estándar para hacerlo es el análisis de impacto en el negocio (BIA, por sus siglas en inglés). Un proceso básico sigue estos pasos:
- Inventaria las aplicaciones y los datos que sostienen cada proceso de negocio.
- Estima el coste de una hora de parada y de una hora de datos perdidos, en ventas, reputación y sanciones, como las que prevé la NIS2 en España.
- Clasifica los sistemas por criticidad: crítico, importante o diferible.
- Asigna a cada nivel un RTO y un RPO objetivo, acordados con dirección.
- Traduce el RPO en frecuencia de copia y el RTO en tecnología de recuperación.
Una vez clasificados, cada sistema recibe su RTO y RPO de forma coherente con lo que cuesta protegerlo. Como referencia orientativa, sin valor de norma, los niveles suelen quedar así:
- Sistemas críticos: RTO y RPO de minutos, con réplica continua o casi continua.
- Sistemas importantes: objetivos de pocas horas, con copias frecuentes y restauración ágil.
- Sistemas diferibles: uno o varios días, con copias diarias o semanales.
Qué papel juegan el disaster recovery y el DRP en esos objetivos
El disaster recovery es la capacidad técnica de recuperar sistemas tras un incidente grave, y el DRP (Disaster Recovery Plan) es el documento que describe cómo hacerlo. Ambos existen para cumplir el RTO y el RPO acordados.
El DRP forma parte de un marco más amplio, el plan de continuidad de negocio, que abarca también personas, proveedores y comunicación. La norma ISO 22301 es la referencia internacional para gestionarlo.
La relación entre ambos es directa: el RPO decide la tecnología de copia o réplica, y el RTO decide dónde y cómo se levantan los sistemas. Un RTO de minutos casi siempre exige un segundo entorno ya preparado en otra ubicación.
El tipo de réplica marca el RPO alcanzable:
- Réplica síncrona: cada escritura se confirma en los dos sitios, con un RPO cercano a cero y límites de distancia.
- Réplica asíncrona: los datos viajan con segundos o minutos de retraso, con más margen geográfico y menor coste.
- Copia periódica: el RPO equivale al intervalo entre copias, de una hora a un día.
Elegir entre ellas es, en el fondo, decidir cuánto vale cada minuto de datos para el negocio, por eso la frecuencia de copia nunca debería fijarse antes que el RPO.
La infraestructura física también entra en el cálculo. Un centro de datos con autonomía eléctrica de 72 horas reduce la probabilidad de tener que activar el DRP ante un corte de suministro prolongado.
Errores habituales al fijar RTO y RPO con un cliente
La mayoría de los fallos en continuidad no vienen de la tecnología, sino de objetivos mal definidos. Estos son los errores que más se repiten al fijar RTO y RPO:
- Decidir los objetivos solo desde el equipo técnico, sin implicar a dirección.
- Pedir cero minutos de parada para todo, sin calcular lo que cuesta.
- Olvidar las dependencias: una aplicación no arranca si falla su directorio activo o su red.
- Medir el tiempo de restauración de los datos y no el de puesta en servicio completa.
- No probar nunca el plan, o probarlo con una muestra pequeña de sistemas.
El último punto es el más grave. Un RTO que nunca se ha probado es una suposición, y la única forma de conocer su funcionamiento real es restaurar, cronometrar y documentar. Una prueba anual completa, con al menos un sistema crítico restaurado de principio a fin, es un mínimo razonable.
Conviene también contrastar los objetivos con los niveles de servicio que el proveedor de infraestructura publica cada año, y no solo con sus compromisos comerciales.
Cómo llevar el RTO y el RPO a un acuerdo de nivel de servicio realista
Un acuerdo de nivel de servicio (SLA) útil traduce RTO y RPO en compromisos medibles. Eso implica escribir cifras, no adjetivos, y dejar claro qué ocurre si no se cumplen.
- Disponibilidad comprometida en porcentaje y su equivalente en minutos de parada al mes.
- Frecuencia de copia y retención alineadas con el RPO de cada sistema.
- Tiempos de respuesta y resolución por prioridad de incidencia.
- Penalizaciones automáticas y calendario de pruebas del plan de recuperación.
Como referencia, un 99,995% de disponibilidad mensual equivale a unos dos minutos de parada al mes. Poner esa traducción delante del cliente evita malentendidos y ajusta expectativas desde el primer día.
Definir RTO y RPO es el primer paso de cualquier estrategia de continuidad, y también el más barato. El siguiente es contar con una infraestructura capaz de cumplir esas cifras.
En Walhalla Cloud ayudamos al canal a convertirlas en un servicio real: Cloud Backup para las copias, Housing con un 99,995% de disponibilidad garantizada por contrato para los sistemas críticos y Walhalla Cloud como segundo entorno de recuperación.
Si estás diseñando un plan de continuidad para un cliente, escríbenos a comercial@walhallacloud.com con tu nombre, empresa, teléfono y una breve descripción del proyecto, y te ayudaremos a dimensionarlo.
