RTO y RPO: qué son, cuál es la diferencia y cómo definir cada uno
RTO es cuánto tiempo hasta volver; RPO es cuánto dato aceptas perder. Mira el significado, la diferencia y cómo definir los dos números en tu infraestructura.
Optidata
RTO (Recovery Time Objective) es el tiempo máximo aceptable para restaurar un sistema después de una falla. RPO (Recovery Point Objective) es la cantidad máxima de datos que aceptas perder, medida en tiempo. En resumen: RTO es cuánto tiempo hasta volver, RPO es cuánto dato puedes perder.
Todo plan de continuidad se resume, al final, en dos números. Cuando un sistema cae, la primera pregunta de la dirección es “¿cuánto tiempo hasta volver?”. La segunda, apenas baja el polvo, es “¿perdimos datos?”. Saber qué es RTO y RPO, y haber definido los dos antes del incidente, es lo que separa una respuesta tranquila de una reunión de crisis. Este texto explica cada uno, muestra la diferencia en una frase y enseña a definir los números correctos para tu operación.
Qué es RTO
RTO, sigla de Recovery Time Objective, es el tiempo máximo que tu empresa acepta tener un sistema fuera del aire antes de restaurarlo. Es la respuesta a la pregunta “a partir del momento de la falla, ¿cuánto tiempo tenemos para volver?”.
El RTO es una decisión de negocio antes de ser una decisión técnica. Define el presupuesto y la arquitectura que vas a necesitar. Un RTO de pocos minutos exige redundancia activa y failover automático, lo que cuesta más. Un RTO de un día entero permite una estrategia más simple y barata. El número correcto no es el menor posible, es el que equilibra el costo de prevenir contra el costo de quedar parado.
Qué es RPO
RPO, sigla de Recovery Point Objective, es la cantidad máxima de datos que tu empresa acepta perder en caso de falla, medida en tiempo. Responde a la pregunta “¿hasta qué punto en el pasado podemos volver sin perjuicio grave?”.
En la práctica, el RPO define la frecuencia de tus backups y replicaciones. Si aceptas perder como máximo cinco minutos de datos, necesitas replicar cada cinco minutos o menos. Si aceptas perder un día, un backup diario resuelve. El RPO traduce el valor de tu dato en una cadencia de protección: cuanto más crítico el dato, menor el RPO, y más frecuente la copia.
La diferencia en una frase
La confusión entre los dos desaparece con una frase: RTO es sobre tiempo de sistema parado, RPO es sobre cantidad de dato perdido.
Un ejemplo lo deja claro. Imagina que una base de datos falla a las 10:12. El último backup fue a las 10:00. El sistema vuelve a las 11:00. En ese caso, el RPO real fue de 12 minutos, porque los datos generados entre las 10:00 y las 10:12 se perdieron. Y el RTO real fue de 48 minutos, el tiempo entre la falla y el retorno. Uno mide el hueco en el pasado, el otro mide la duración de la interrupción. Necesitas los dos, porque optimizar solo uno deja el otro descubierto.
Cómo definir cada número en tu negocio
No existe un RTO y RPO único para toda la empresa. Cada sistema tiene una criticidad, e intentar dar el mismo número a todos es desperdicio de un lado y riesgo del otro. El camino es clasificar los sistemas por impacto y atribuir los objetivos a cada clase.
La tabla de abajo muestra una forma común de organizar esto. Los valores son ilustrativos y sirven para que razones sobre tus propias franjas, no como benchmark fijo.
| Criticidad | Ejemplos | RTO típico | RPO típico |
|---|---|---|---|
| Crítico | ERP, checkout de e-commerce, core transaccional | Minutos a 1 hora | Segundos a minutos |
| Importante | CRM, BI, sistemas internos de apoyo | 2 a 8 horas | Hasta 1 hora |
| Secundario | Archivos, entornos de dev y test, reportes | 24 horas o más | 24 horas |
La lógica es directa. Cuanto más la interrupción de ese sistema duele en la facturación, en la operación o en la reputación, más corto el RTO y el RPO necesitan ser, y más la empresa necesita invertir en redundancia para sostenerlos. Los sistemas de apoyo toleran tiempos mayores, y gastar en failover instantáneo para ellos es tirar el dinero.
El costo de cada hora de RTO
Definir RTO sin conocer el costo de cada hora parada es decidir a oscuras. El número que justifica la inversión en recuperación es el costo de downtime, es decir, cuánto pierde tu empresa por hora de sistema indisponible.
La cuenta básica suma los ingresos perdidos, el costo del equipo parado y el impacto de reputación y multas, dividido por el tiempo de operación. Un ejemplo simple muestra la lógica: si tu operación factura, en promedio, veinte mil por hora y una falla derriba el sistema por tres horas, la interrupción costó sesenta mil solo en ingresos, sin contar el equipo parado y la reputación. Con ese valor en la mano, la decisión de RTO deja de ser opinión. Si cada hora parada cuesta un valor alto, un RTO corto se paga; si el costo por hora es bajo, un RTO más holgado es la elección racional. Ese es el cálculo que transforma la continuidad de “buena práctica” en una decisión de presupuesto defendible.
Errores comunes al prometer RTO y RPO
Cuatro errores aparecen con frecuencia cuando las empresas definen esos números.
El primero es prometer un RTO que nunca fue probado. Un RTO de cuatro horas en el contrato no significa nada si la empresa nunca ejecutó una restauración de verdad para medir si logra cumplirlo. RTO en el papel es hipótesis; RTO probado es compromiso.
El segundo es confundir los dos objetivos y acabar protegiendo solo el tiempo, olvidando el dato, o al revés. Los dos necesitan atención por separado.
El tercero es aplicar el mismo número para todo. Dar un RTO de minutos a un sistema de reportes secundario gasta dinero en vano; dar un RTO de un día al core transaccional es asumir un riesgo que la dirección no aprobaría si lo entendiera.
El cuarto es tratar el RTO y el RPO como números fijos para siempre. A medida que la operación crece y la criticidad de los sistemas cambia, los objetivos necesitan ser revisados. Un número definido hace tres años puede estar peligrosamente desactualizado hoy.
Preguntas frecuentes
¿Qué es RTO? Es el tiempo máximo aceptable para restaurar un sistema después de una falla, es decir, cuánto tiempo hasta volver a operar.
¿Qué es RPO? Es la cantidad máxima de datos que aceptas perder en caso de falla, medida en tiempo. Define la frecuencia de backup y replicación.
¿Cuál es la diferencia entre RTO y RPO? RTO mide el tiempo de sistema parado; RPO mide la cantidad de dato perdido. Uno trata de la duración de la interrupción, el otro de cuánto vuelves en el pasado.
¿Qué es un buen RTO? No hay valor universal. Un buen RTO es el que equilibra el costo de mantener redundancia contra el costo de cada hora parada para ese sistema específico. Para el core crítico, suele ser de minutos a una hora; para sistemas de apoyo, horas.
¿Un RTO de 4 horas es realista? Puede serlo, siempre que la arquitectura lo soporte y la empresa haya probado la restauración dentro de ese plazo. Sin prueba real, cualquier RTO es apenas una promesa no verificada.
Optidata diseña RTO y RPO contigo e incluye DR en dos regiones. Habla con un especialista.