Saltar al contenido
AIO Tecnología

Respaldo y continuidad

RTO y RPO explicados para gerentes

16 de septiembre de 2026 · 5 minutos de lectura

Hay dos números que deberían estar escritos en algún documento de su empresa y que, en la mayoría de los casos, no lo están. No son técnicos, aunque tengan nombre técnico: son decisiones de negocio que alguien de tecnología acaba tomando por defecto cuando nadie más las toma.

RPO: cuánta información puede perder

El RPO, o punto objetivo de recuperación, responde a una pregunta simple: si el sistema falla ahora mismo, ¿hasta qué momento del pasado podemos volver sin que eso arruine la operación?

Si el respaldo se ejecuta cada noche a las once, el RPO real es de hasta veinticuatro horas. Una falla a las cinco de la tarde significa perder el trabajo de todo el día: las facturas emitidas, los pedidos ingresados, las historias registradas. Para una empresa eso puede ser una molestia manejable o un problema serio, y la diferencia depende del negocio, no de la tecnología.

Dicho en criollo: el RPO es cuánto trabajo está dispuesto a rehacer.

RTO: cuánto tiempo puede estar detenido

El RTO, o tiempo objetivo de recuperación, responde a la otra mitad: desde que el sistema cae, ¿cuánto puede pasar hasta que vuelva a estar operativo?

Aquí la trampa habitual es confundir el deseo con el diseño. Todo el mundo quiere que el RTO sea de minutos. Conseguirlo exige equipos duplicados, replicación y procedimientos probados, y eso cuesta. Un RTO de un día laborable, en cambio, se puede sostener con un esquema mucho más simple.

Dicho en criollo: el RTO es cuánto tiempo puede tener a su gente sin poder trabajar.

Por qué se definen primero

Estos dos números son la entrada del diseño, no su resultado. Definirlos primero evita las dos formas de equivocarse:

  • Invertir de menos en un sistema que la operación no puede permitirse perder, y descubrirlo durante la falla.
  • Invertir de más en un sistema que podría estar detenido dos días sin que nadie lo note, solo porque la solución venía en el mismo paquete.

Además, no se definen una vez para toda la empresa. Se definen por servicio, y casi siempre dan resultados distintos: el sistema de facturación y el servidor de archivos de marketing rara vez merecen la misma inversión.

Un ejercicio de treinta minutos

Reúna a las áreas de negocio, no solo a TI, y por cada sistema importante haga dos preguntas:

  1. Si perdemos el trabajo de las últimas X horas, ¿qué pasa? Baje la X hasta que la respuesta deje de ser aceptable. Ahí está su RPO.
  2. Si este sistema está caído durante Y horas, ¿qué pasa? Baje la Y del mismo modo. Ahí está su RTO.

Las áreas de negocio suelen dar respuestas mucho más precisas que TI, porque son las que sufren la interrupción.

El número que nadie mide

Hay un tercer dato, y es el más revelador: el RTO real, medido en una prueba de restauración con cronómetro. La distancia entre el RTO que la empresa desea y el que realmente consigue hoy es, en una sola cifra, el tamaño del problema.

Esa brecha es la que ordena las prioridades de inversión. No la sensación de que habría que hacer algo, ni la oferta que llegó por correo.

Qué hacer con esto

Escriba los dos números por servicio, mídalos contra la realidad y use la diferencia para decidir. Es una conversación de una hora que suele cambiar por completo el presupuesto de tecnología del año siguiente.

Si quiere el dato medido en lugar de estimado, un diagnóstico de respaldo y recuperación incluye una prueba real de restauración con su tiempo cronometrado. Y si le interesa el porqué de todo esto, lea tener respaldo no significa poder recuperar su empresa.

Antes de invertir en tecnología, conviene saber dónde está el problema.

Revisamos su infraestructura, identificamos prioridades y definimos los siguientes pasos por escrito.

WhatsApp