Cuando un servidor cae, una base de datos se corrompe o un ataque cifra tus sistemas, las dos primeras preguntas que importan son siempre las mismas: ¿cuánto tardamos en volver a operar? y ¿cuántos datos hemos perdido por el camino? Esas dos preguntas tienen nombre técnico: RTO y RPO. Entenderlas no es un lujo de ingenieros; es la base sobre la que se decide cuánto invertir en copias de seguridad y continuidad, y es lo que separa un susto de una crisis. En esta guía te explicamos qué significan, cómo calcularlas para tu negocio y cómo se traducen en una estrategia concreta.
Qué es el RTO (tiempo de recuperación)
El RTO (Recovery Time Objective) es el tiempo máximo que tu empresa puede tolerar con un sistema caído antes de que el impacto sea inaceptable. Es la respuesta a «¿cuánto podemos estar parados?». Si tu ERP se cae a las 9:00 y tu RTO es de cuatro horas, significa que el objetivo es tenerlo operativo de nuevo antes de las 13:00.
Un RTO bajo (minutos) exige infraestructura redundante y mecanismos de conmutación automática, y cuesta más. Un RTO alto (un día entero) permite estrategias más sencillas y económicas. La clave es que el RTO no lo decide la tecnología: lo decide el coste de estar parado.
Qué es el RPO (cuántos datos puedes perder)
El RPO (Recovery Point Objective) es la cantidad máxima de datos que puedes permitirte perder, medida en tiempo. Es la respuesta a «¿hasta qué momento podemos retroceder sin que duela?». Si haces una copia cada 24 horas y el fallo ocurre justo antes de la siguiente, podrías perder casi un día entero de trabajo: ese es tu RPO real.
Un ejemplo claro: una gestoría que registra facturas durante toda la jornada no puede permitirse perder un día de altas. Necesita un RPO de minutos, lo que implica copias frecuentes o replicación continua. En cambio, un sitio corporativo que se actualiza una vez por semana puede vivir con un RPO de varios días sin mayor problema.
Por qué RTO y RPO van siempre juntos
Son dos ejes distintos del mismo problema y conviene no confundirlos. El RTO mide tiempo de inactividad; el RPO mide pérdida de datos. Puedes tener un RTO excelente (recuperas el sistema en minutos) y un RPO malo (recuperas, pero con los datos de ayer). O al revés. Una estrategia de recuperación seria define ambos para cada sistema crítico por separado, porque no todo tu negocio tiene las mismas necesidades.
- RTO: cuánto tiempo aguantas parado. Marca el diseño de la infraestructura.
- RPO: cuántos datos asumes perder. Marca la frecuencia de las copias.
Cómo calcularlos para tu empresa
No hay un número universal: depende de lo que cuesta cada hora de parada y cada hora de datos perdidos en tu negocio concreto. El método es sencillo y se hace con el equipo de negocio, no solo con el técnico:
- Inventaría tus sistemas y clasifícalos por criticidad: ¿cuáles paran el negocio si caen?
- Para cada uno, estima el coste de una hora de inactividad (ventas perdidas, parálisis del equipo, penalizaciones, daño reputacional).
- Define el RTO: el tiempo máximo que ese coste es asumible.
- Define el RPO: cuánto trabajo perdido podrías rehacer o asumir sin un impacto grave.
- Contrasta esos objetivos con lo que tu infraestructura permite hoy. La diferencia es tu plan de mejora.
El error más común es fijar RTO y RPO de cero «por seguridad». La recuperación instantánea sin pérdida de datos existe, pero es cara y rara vez la necesita todo el negocio. Lo honesto es ajustar la exigencia (y el gasto) a cada sistema según lo que de verdad cuesta su caída.
De los objetivos a la estrategia de backups y continuidad
Una vez tienes los números, dictan las decisiones técnicas. Un RPO de minutos exige copias muy frecuentes o replicación; un RPO de un día se cubre con una copia diaria bien verificada. Un RTO de minutos pide sistemas redundantes con conmutación automática; un RTO de horas se puede cubrir restaurando desde copia sobre infraestructura preparada.
Hay un punto que se olvida demasiado: una copia que no se ha probado restaurando no es una copia, es una suposición. Cualquier plan serio de backup y continuidad de negocio incluye pruebas de restauración periódicas, retención adecuada (incluida una copia fuera de línea o aislada frente a ransomware) y un procedimiento documentado de quién hace qué cuando suena la alarma. Sin esa parte, los mejores RTO y RPO sobre el papel no sirven de nada.
Preguntas frecuentes
¿Es lo mismo backup que plan de recuperación ante desastres?
No. El backup es una pieza del plan: las copias de tus datos. El plan de recuperación ante desastres es el conjunto completo (objetivos de RTO y RPO, infraestructura, procedimientos y responsables) que garantiza que esas copias sirven para volver a operar en el tiempo que necesitas.
¿Cada cuánto debo hacer copias de seguridad?
Tantas veces como exija tu RPO. Si no te puedes permitir perder más de una hora de datos, necesitas copias al menos cada hora (o replicación continua). Si toleras perder un día, una copia diaria es suficiente. La frecuencia es una consecuencia del RPO, no una decisión aislada.
¿Un RTO y RPO muy bajos no son siempre lo mejor?
No necesariamente. Cuanto más bajos, más cuesta la infraestructura que los sostiene. Lo correcto es dimensionarlos según el impacto real de la caída de cada sistema, no aplicar el máximo a todo «por si acaso». Eso evita pagar de más sin reducir riesgos que importen.
¿Cómo sé si mi plan actual aguantaría un incidente real?
Probándolo. Una prueba de restauración controlada te dice si recuperas a tiempo (RTO real) y con qué cantidad de datos (RPO real). Si nunca has restaurado desde tus copias, no sabes lo que tienes; solo lo que esperas tener.
Define tus objetivos antes de que el incidente lo haga por ti
RTO y RPO convierten una preocupación difusa («espero no perder nada») en objetivos medibles que guían inversión y diseño. En Elimática ayudamos a empresas a definir esos objetivos por sistema y a montar la estrategia de backup y continuidad que de verdad los cumple, con pruebas de restauración incluidas. Si quieres saber si tu plan actual aguantaría un incidente real, cuéntanos tu caso y lo revisamos contigo.