Valluris · Blog
RTO y RPO explicados: los objetivos de recuperación que definen tu plan
Cuando un sistema se cae, siempre hay dos preguntas a las que la empresa necesita dar respuesta inmediata: cuánto tiempo tardaremos en volver a estar operativos y cuánta información perderemos por el camino. Estas dos preguntas tienen nombre propio en continuidad de negocio: RTO y RPO. Y son, probablemente, los dos conceptos peor entendidos —y más decisivos— de cualquier plan de recuperación.
Para una pyme, definir bien estos objetivos de recuperación no es un ejercicio académico. Es lo que separa un incidente resuelto en pocas horas de un incidente que paraliza la empresa durante días, con pérdidas que a menudo nunca se recuperan del todo.
Qué es el RTO (Recovery Time Objective)
El RTO es el tiempo máximo que la empresa acepta estar sin un determinado sistema o servicio hasta que este vuelva a funcionar. Responde a la pregunta: «¿cuánto tiempo podemos estar parados antes de que esto se vuelva inaceptable?»
Si el RTO del sistema de facturación es de 4 horas, significa que la empresa ha decidido, de antemano, que 4 horas de indisponibilidad son gestionables —y que cualquier tiempo superior empezará a causar daños graves al negocio, ya sean financieros, contractuales o de reputación.
Qué es el RPO (Recovery Point Objective)
El RPO es diferente: mide la cantidad de datos que la empresa está dispuesta a perder, expresada en tiempo. Responde a la pregunta: «¿hasta qué punto en el pasado podemos retroceder sin que ello comprometa la operativa?»
Si el RPO de una base de datos de pedidos es de 1 hora, significa que, en el peor de los casos, la empresa acepta perder hasta 1 hora de pedidos registrados entre la última copia de seguridad válida y el momento del incidente. Un RPO de 1 hora exige copias de seguridad (o replicación) al menos cada hora, no cada día.
Por qué RTO y RPO no son lo mismo
Es habitual ver estos dos conceptos mezclados, pero miden cosas completamente diferentes:
| Objetivo | Qué mide | Pregunta a la que responde |
|---|---|---|
| RTO | Tiempo de indisponibilidad | ¿Cuánto tiempo tardaremos en volver a estar operativos? |
| RPO | Pérdida de datos | ¿Cuánto podemos perder desde el último punto seguro? |
Una empresa puede tener un RTO corto y un RPO largo (se recupera rápido, pero con datos de hace varios días) o todo lo contrario: tarda en recuperarse, pero sin perder prácticamente nada. Cada combinación implica una arquitectura técnica y un coste diferentes.
Cómo definir el RTO y el RPO adecuados para tu pyme
El error más común es definir estos objetivos partiendo de la tecnología disponible («la copia de seguridad se ejecuta cada noche, luego el RPO es de 24 horas») en lugar de definirlos a partir del impacto real en el negocio. El camino correcto es el inverso:
- Identificar los sistemas críticos: ¿cuáles son los sistemas sin los cuales la empresa no puede operar, facturar o atender a sus clientes?
- Cuantificar el impacto de la indisponibilidad: ¿qué ocurre tras 1 hora de parón? ¿Y tras 1 día? ¿Pérdidas financieras, incumplimiento de contratos, riesgo legal?
- Cuantificar el coste de perder datos: ¿perder 1 hora de ventas no registradas es grave? ¿Y perder un día entero de producción?
- Definir RTO y RPO por sistema, no para toda la empresa: el correo electrónico puede soportar un RTO de 8 horas; el sistema de pedidos, probablemente no.
- Comprobar si la infraestructura actual puede cumplir esos objetivos: solo tras definir lo que se necesita se evalúa si las copias de seguridad, la replicación y los contratos con proveedores pueden respaldar esas cifras.
Errores comunes al definir estos objetivos
- Definir un RTO «ambicioso» sobre el papel sin probar si es realmente alcanzable: un plan que nunca se prueba es, en la práctica, una simple suposición.
- Asumir que las copias de seguridad diarias son suficientes para todos los sistemas, sin evaluar el RPO real de cada uno.
- No involucrar a quienes conocen el negocio: el RTO y el RPO son decisiones de gestión, no únicamente decisiones técnicas de TI.
- Dejar estos objetivos solo en la cabeza de una persona, sin documentarlos ni revisarlos a medida que la empresa crece.
Un RTO y un RPO que nunca han sido probados no son un plan de recuperación: son una buena intención.
Del objetivo al plan: transformar RTO/RPO en acción
Definir el RTO y el RPO es solo el primer paso. Estos números solo tienen valor real cuando se traducen en un plan concreto: qué copias de seguridad existen, con qué frecuencia se ejecutan, dónde se guardan, quién las prueba y con qué periodicidad, y qué pasos se siguen en cuanto se detecta un incidente.
Sin ese plan por escrito y sin pruebas periódicas que confirmen que los objetivos se cumplen en la práctica, el RTO y el RPO se quedan solo en el papel... y es precisamente en el peor día cuando esa diferencia se hace evidente.
Conclusión
El RTO y el RPO no son conceptos técnicos abstractos: son decisiones de negocio traducidas en cifras concretas. Para una pyme, definir estos objetivos con claridad —sistema por sistema y teniendo presente el impacto real— es lo que transforma un plan de recuperación de un mero trámite formal en algo que efectivamente funciona cuando hace falta.
En Valluris ayudamos a las pymes a definir el RTO y el RPO de cada sistema crítico y a construir un plan de recuperación probado —no solo escrito— para el día en que realmente sea necesario.
Solicitar una evaluación