Si tu equipo de TI aún no tiene definidos el RPO y el RTO de cada sistema crítico, tu empresa no tiene un plan de continuidad: tiene una intención. El RPO (Recovery Point Objective) responde a cuánta información puedes perder sin comprometer el negocio, mientras que el RTO (Recovery Time Objective) responde a cuánto tiempo puede estar caído un sistema antes de que el daño sea irreversible. Fijar ambos números correctamente, y luego construir la infraestructura que los cumpla, es la base de cualquier estrategia de recuperación ante desastres.
Qué significa cada sigla y por qué no son lo mismo
El RPO mide el tiempo máximo de datos que puedes tolerar perder. Si tu base de datos transaccional se respalda cada cuatro horas y ocurre una falla justo antes del próximo respaldo, perderás hasta cuatro horas de operaciones. Ese intervalo es tu RPO real, le llames así o no. Si esa pérdida deja facturas sin registrar, pedidos sin procesar o transacciones sin cerrar, el RPO de cuatro horas es demasiado amplio para ese sistema.
El RTO, en cambio, mide cuánto tiempo puede pasar desde que ocurre el incidente hasta que el sistema vuelve a estar operativo. Aquí entran variables como el tiempo de detección, el tiempo de restauración desde el respaldo, las pruebas de integridad y la disponibilidad del equipo técnico. Un sistema puede tener un RPO de cero (replicación síncrona, sin pérdida de datos) pero un RTO de dos horas si la restauración es manual y depende de un único administrador.
La confusión más frecuente en organizaciones medianas es tratar ambas métricas como si fueran la misma: "necesitamos recuperarnos rápido y sin perder nada". Ese deseo es válido, pero técnicamente implica soluciones muy distintas y con costos muy distintos. RPO bajo exige mayor frecuencia de respaldo o replicación. RTO bajo exige redundancia activa, automatización y capacidad de failover. Conseguir ambos en niveles cercanos a cero requiere arquitecturas de alta disponibilidad que no todas las cargas de trabajo justifican.
Cómo fijar los valores correctos para tu organización
El punto de partida es un análisis de impacto de negocio (BIA, por sus siglas en inglés). La metodología consiste en reunirse con los responsables de cada área para identificar cuánto tiempo podría tolerar la operación sin ese sistema y qué volumen de datos perdidos generaría un daño real. A partir de esa conversación se asignan valores de RPO y RTO a cada proceso o aplicación, y se los clasifica en niveles de criticidad.
Un ejemplo concreto: el sistema de emisión de facturas electrónicas de una empresa retail puede admitir un RPO de quince minutos (se puede re-emitir con tolerancia regulatoria) y un RTO de dos horas (las operaciones manuales absorben la brecha). En cambio, el sistema de pagos en línea del mismo retail puede necesitar un RPO de menos de un minuto y un RTO de minutos, porque cada momento fuera de línea se traduce en ventas perdidas y clientes que no regresan.
Para los sistemas de bases de datos críticas, los valores de referencia del mercado ubican el RTO por debajo de quince minutos en cargas de misión crítica, como core bancario, plataformas transaccionales o sistemas de control industrial. Cuanto más se acercan esos objetivos a cero, más sofisticada debe ser la solución: replicación síncrona, clústeres de alta disponibilidad y procedimientos de failover automatizados. En OS4IT administramos más de 400 bases de datos en producción y una parte central de ese trabajo es definir y garantizar estos umbrales junto a cada cliente, no solo documentarlos en un papel.
Si necesitas revisar o modernizar la arquitectura de tus bases de datos para que los respaldos realmente se alineen con tus objetivos de recuperación, puedes conocer más sobre nuestro servicio de administración de bases de datos.
El error más caro: RPO y RTO declarados que nadie ha probado
Muchos equipos de TI tienen un documento que dice "RTO: 4 horas, RPO: 1 hora" para sus sistemas críticos. El problema aparece el día que ocurre una falla real y la restauración tarda doce horas porque el respaldo estaba incompleto, la cinta tardó en llegar o nadie recordaba el procedimiento. Según datos de ITIC 2024, más del 90% de las organizaciones medianas y grandes estiman que una hora de inactividad les cuesta más de 300.000 dólares. Con ese contexto, un RTO no probado es una promesa vacía con un precio muy alto.
La única forma de validar que tus RTO y RPO son alcanzables es ejecutar simulacros de recuperación periódicos, con escenarios reales: corrupción de datos, falla de almacenamiento, pérdida del sitio principal. En esas pruebas se descubren los cuellos de botella reales: dependencias no documentadas, credenciales vencidas, versiones de software incompatibles o simplemente falta de personal entrenado.
Un servicio administrado de respaldo y recuperación bien estructurado no solo ejecuta los respaldos: documenta los procedimientos, actualiza los runbooks y programa los simulacros. Esa disciplina operativa es la que convierte un número en papel en una garantía real.
La relación entre RPO, RTO y el costo de la solución
Uno de los errores frecuentes al presentar estas métricas a la dirección es separar los objetivos del costo de cumplirlos. Un RPO de cero con replicación síncrona requiere ancho de banda dedicado, almacenamiento espejado y latencia controlada. Un RTO de cinco minutos requiere failover automatizado, que a su vez requiere virtualización bien configurada, monitoreo constante y procedimientos de activación probados.
La conversación correcta con el gerente general o el CFO no es "queremos llegar a RPO cero", sino "estos tres sistemas necesitan RPO de quince minutos y RTO de una hora, esto es lo que cuesta cumplirlo, y esto es lo que cuesta una hora caída si no lo cumplimos". El segundo número casi siempre justifica el primero.
Para que esa comparación sea posible, tu equipo necesita una estimación del costo de inactividad por sistema. Si aún no tienes ese cálculo, puedes apoyarte en la metodología que describimos en nuestro artículo sobre cuánto cuesta una hora de sistema caído, que incluye una fórmula aplicable a cualquier organización.
Nuestro servicio de monitoreo 24x7 complementa directamente los objetivos de RTO: detectar el incidente en segundos, no en horas, es la diferencia entre cumplir o no un objetivo de recuperación de treinta minutos. Y cuando el almacenamiento subyacente forma parte del análisis, nuestro equipo de infraestructura de almacenamiento puede evaluar si la arquitectura actual soporta los tiempos comprometidos.
Preguntas frecuentes
¿Cuál debería ser el RPO y el RTO de una pyme en Chile?
No existe un valor único correcto: depende del sector, del proceso y del costo de la pérdida. Una empresa de servicios profesionales con facturación diaria puede tolerar un RPO de dos a cuatro horas y un RTO de medio día. Una empresa de comercio electrónico o de salud probablemente necesita RPO inferior a una hora y RTO de menos de dos horas para sus sistemas principales. El punto de partida es siempre el análisis de impacto: cuánto cuesta cada hora caída y cuánta información perdida es recuperable manualmente. Con esos datos sobre la mesa, los objetivos se fijan solos.
¿Es posible alcanzar RPO cero sin un presupuesto de gran empresa?
La replicación síncrona, que garantiza RPO cero porque cada escritura se confirma solo cuando todas las réplicas la han registrado, tiene un costo en latencia y en infraestructura de red. Sin embargo, no es exclusiva de grandes organizaciones. En entornos virtualizados bien diseñados y con almacenamiento compartido, es posible acercarse a RPO de minutos con soluciones de costo accesible para medianas empresas. La clave está en aplicar esos niveles solo a los sistemas que realmente lo requieren, en vez de intentar cubrir toda la infraestructura con el mismo estándar, lo que sí encarece cualquier proyecto.
¿Con qué frecuencia se deben revisar los valores de RPO y RTO definidos?
Los objetivos de recuperación deben revisarse al menos una vez al año, y también cada vez que cambia un sistema crítico, se incorpora una aplicación nueva, cambia el modelo de negocio o se produce un incidente real. Una fusión, la migración a una nueva versión de base de datos o la incorporación de un nuevo canal de ventas pueden cambiar completamente el perfil de riesgo de un proceso. Mantener los valores actualizados y probarlos con simulacros periódicos es lo que distingue un plan de continuidad activo de un documento que solo existe para una auditoría.
En OS4IT trabajamos con cada cliente para definir, documentar y garantizar sus objetivos de recuperación, desde el diseño de la arquitectura hasta la ejecución de los simulacros. Si quieres revisar si tu infraestructura actual puede cumplir los RTO y RPO que tu negocio necesita, Agenda un diagnóstico gratuito con nuestro equipo.
