¿Qué son el RTO y el RPO?
Son las dos cifras que convierten un respaldo en un plan. Suenan a jerga, pero la idea es simple y muy práctica. El RTO, objetivo de tiempo de recuperación, responde a la pregunta «¿en cuánto tiempo tenemos que volver a operar?»: es el máximo que un sistema puede estar caído antes de que el daño al negocio sea inaceptable. Es una medida de tiempo. El RPO, objetivo de punto de recuperación, responde a otra pregunta distinta: «¿cuántos datos podemos permitirnos perder?». Es una medida de datos, expresada en tiempo: indica hasta qué momento atrás llega tu última copia útil. Si tu RPO es de una hora, en un incidente puedes recuperar hasta un punto de hace 60 minutos, y todo lo generado después se pierde. La forma más fácil de no confundirlos es recordar que el RTO mide tiempo y el RPO mide datos.
| Aspecto | RTO | RPO |
|---|---|---|
| Pregunta que responde | ¿En cuánto tiempo volvemos a operar? | ¿Cuántos datos podemos perder? |
| Qué mide | Tiempo de inactividad | Datos, expresados en tiempo |
| Qué determina | Método e infraestructura de recuperación | Frecuencia del respaldo |
| Ejemplo | «Operativos en 4 horas» | «Como máximo perder 1 hora de datos» |
¿Cómo se traducen en tu plan de respaldo?
Aquí los conceptos dejan de ser teoría y se vuelven decisiones concretas de configuración. El RPO determina la frecuencia con la que respaldas, y la relación es directa: un respaldo nocturno deja un RPO de hasta 24 horas —en el peor caso pierdes un día entero de trabajo—; una replicación cada 15 minutos da un RPO de 15 minutos; y un RPO de cero solo se logra con protección continua de datos, replicando cada cambio en tiempo real. El RTO determina el método y la infraestructura de recuperación: si necesitas estar operativo en minutos, requieres replicación o un servidor en caliente listo para tomar el relevo; si toleras horas, basta con restaurar desde una copia; si toleras días, puedes incluso reconstruir desde cero. Por eso definir estos dos números antes de comprar nada evita el error clásico de tener una herramienta de respaldo que no encaja con lo que el negocio realmente necesita. La regla 3-2-1-1-0 te da la estructura; el RTO y el RPO le dan el ritmo.
¿Cómo fijo el RTO y el RPO de cada sistema?
El error de partida es tratarlo como una decisión técnica. No lo es: es una decisión de negocio. La forma ordenada de hacerlo es a través de un análisis de impacto: revisas cada sistema y te haces las dos preguntas clave —cuánto puede estar caído (RTO) y cuántos datos puede perder (RPO)— en función del daño que causaría su interrupción. Y casi nunca la respuesta es la misma para todo: el sistema de facturación o el ERP exigen objetivos estrictos, mientras que un archivo histórico tolera valores holgados. Por eso lo habitual es organizar los sistemas por niveles —crítico, alto, medio, bajo— en una matriz, y asignar a cada nivel su RTO y su RPO. Para fijar bien esos números ayuda cuantificar el costo de cada hora de inactividad de los sistemas críticos: cuando ves en cifras lo que cuesta un día parado, decidir cuánto invertir en recuperarlo deja de ser abstracto. Esta priorización es justo el primer paso de un buen plan de recuperación ante desastres.
El equilibrio: cuanto más exigente, más caro
A todos les encantaría un RTO y un RPO de cero —volver al instante sin perder un solo dato—, pero conviene ser honesto sobre lo que eso implica. Acercarse a cero exige infraestructura redundante en tiempo real, con replicación continua y equipos en espera, algo extremadamente costoso y complejo de mantener. Por eso aspirar a cero en todos los sistemas es inasumible para la mayoría de las empresas, y tampoco hace falta. El enfoque sensato es definir objetivos tan bajos como sean prácticos y justificables según el presupuesto, y reservar lo más exigente para los pocos sistemas donde cada minuto de caída se traduce en pérdidas reales. La decisión, en el fondo, es un balance: de un lado, el costo de la inactividad y de la pérdida de datos; del otro, el costo de la tecnología que los evita. Fijar bien el RTO y el RPO es, sobre todo, poner ese balance por escrito para que el negocio y el área de tecnología hablen el mismo idioma. Como referencia no normativa, los sistemas más críticos suelen apuntar a un RTO de entre 15 y 60 minutos con un RPO por debajo de los 15 minutos, mientras que muchos sistemas de producción se mueven cómodos en un RTO y un RPO de una a cuatro horas.
El error más común: objetivos que no se pueden cumplir
Hay un fallo que vemos una y otra vez, y es el más peligroso porque no se nota hasta el día del incidente: fijar objetivos sobre el papel y nunca comprobar si se pueden cumplir. Una empresa declara un RTO de cuatro horas, confiada, y cuando llega el desastre descubre que restaurar de verdad le toma dos días. El detalle que muchos olvidan es que el RTO real no es solo el tiempo de copiar los datos: incluye detectar el problema, decidir qué hacer, restaurar y, sobre todo, verificar que el sistema quedó funcional. Lo mismo con el RPO: de nada sirve creer que tienes copias cada hora si la última válida es de hace tres días. Por eso un objetivo solo es real cuando se ha probado con una recuperación de verdad y se han medido los tiempos. Es la misma lección que repetimos en un respaldo no probado no es un respaldo: la confianza sin prueba es ilusión.
Dos números que valen por un plan
El RTO y el RPO parecen tecnicismos, pero son, en realidad, el contrato entre lo que el negocio espera y lo que la tecnología puede entregar. Definirlos te obliga a hacerte las preguntas correctas —qué es crítico, cuánto cuesta una caída, cuánto puedes perder— y a diseñar el respaldo en consecuencia, en vez de al revés. En Data Recovery Panama ayudamos a las empresas a fijar estos objetivos con realismo, a alinear su respaldo con ellos y a probar que de verdad se cumplen, porque la mejor recuperación es la que ya estaba planificada antes del incidente. Porque el laboratorio que recupera también protege.
Preguntas frecuentes
El RTO (objetivo de tiempo de recuperación) mide tiempo: cuánto puede estar caído un sistema antes de que el daño sea inaceptable, y responde «¿en cuánto tiempo volvemos a operar?». El RPO (objetivo de punto de recuperación) mide datos en tiempo: cuántos datos puedes permitirte perder, es decir, hasta qué momento atrás llega tu última copia útil. Piensa en RTO como tiempo y RPO como datos.
El RPO determina cada cuánto debes respaldar. Un respaldo nocturno implica un RPO de hasta 24 horas: en el peor caso pierdes un día de trabajo. Una replicación cada 15 minutos da un RPO de 15 minutos. Un RPO de cero exige protección continua de datos o replicación en tiempo real. En resumen: cuanto más frecuente el respaldo, más bajo el RPO y menos datos en riesgo.
Es una decisión de negocio, no técnica. Clasifica tus sistemas por criticidad y, para cada uno, pregunta cuánto puede estar caído (RTO) y cuántos datos puede perder (RPO). Los sistemas críticos —facturación, ERP— llevan objetivos exigentes; los archivos históricos, valores holgados. Lo habitual es organizarlo por niveles en una matriz, sopesando el costo de la caída.
En la práctica, sí: lograr cero tiempo de inactividad y cero pérdida de datos en todo exige infraestructura redundante en tiempo real, extremadamente cara y compleja. Lo razonable es definir objetivos tan bajos como sea práctico y justificable según el presupuesto, y reservar lo más exigente para los pocos sistemas que de verdad lo necesitan.
Porque un objetivo declarado no vale nada si no puedes cumplirlo. Es común fijar un RTO de cuatro horas y descubrir, en el incidente real, que la restauración tarda dos días. El RTO real incluye detectar, decidir, restaurar y verificar, no solo copiar. Por eso hay que probar la recuperación con un ejercicio real y medir los tiempos, no asumirlos.