La interrupción de un sistema crítico puede afectar la facturación, la atención a clientes, la producción y el acceso a la información necesaria para operar. Por eso, una estrategia de continuidad y recuperación no debe limitarse a contar con copias de seguridad: también debe definir cuánto tiempo puede permanecer indisponible cada servicio y hasta qué punto anterior al incidente deben poder recuperarse los datos.
Estos objetivos se expresan mediante dos conceptos fundamentales: el RTO (Recovery Time Objective) y el RPO (Recovery Point Objective). Aunque están relacionados, responden a necesidades diferentes. El RTO establece el tiempo objetivo para restablecer un sistema o proceso, mientras que el RPO determina la pérdida máxima de datos tolerable, expresada como un intervalo de tiempo.
Qué son RTO y RPO dentro de una estrategia de continuidad del negocio
El RTO y el RPO son objetivos utilizados para diseñar y evaluar una estrategia de recuperación ante desastres. Permiten traducir el impacto de una interrupción en criterios concretos para definir prioridades, procedimientos e infraestructura.
Ante la caída de un sistema, estos objetivos ayudan a responder tres preguntas centrales:
¿Cuánto tiempo puede permanecer indisponible cada sistema antes de generar un impacto inaceptable?
¿Hasta qué punto anterior al incidente deben poder recuperarse los datos?
¿Qué recursos técnicos y operativos se necesitan para cumplir esos objetivos?
Qué significa RTO (Recovery Time Objective)
El RTO, u Objetivo de Tiempo de Recuperación, establece el plazo dentro del cual un sistema, servicio o proceso debe volver a estar operativo después de una interrupción.
Por ejemplo:
Si un sistema de facturación tiene un RTO de 2 horas, la estrategia de recuperación debe estar diseñada para restablecerlo dentro de ese plazo.
Si una herramienta de comunicación interna tiene un RTO de 24 horas, la organización debe contar con procedimientos alternativos que permitan mantener las comunicaciones esenciales durante ese período.
En general, cuanto mayor es la criticidad de un sistema o proceso, menor debe ser su RTO. Este valor no se define de forma aislada: depende del impacto operativo, financiero, contractual y reputacional que produciría su indisponibilidad.
Qué significa RPO (Recovery Point Objective)
Por otro lado, el RPO, u Objetivo de Punto de Recuperación, define hasta qué punto anterior a una interrupción deben poder recuperarse los datos. Se expresa como un intervalo de tiempo y representa la pérdida máxima de información que la organización considera tolerable.
Este objetivo condiciona la frecuencia y el tipo de mecanismos de protección de datos necesarios:
Si una base de datos tiene un RPO de 15 minutos y el sistema se interrumpe a las 15:00, la organización debe poder recuperar la información hasta un punto no anterior a las 14:45.
Si el RPO es de 24 horas, el punto de recuperación disponible no debería superar las 24 horas previas al incidente.
Para cumplir estos objetivos, la infraestructura debe generar puntos de recuperación con la frecuencia necesaria y verificar que puedan restaurarse. Según el nivel de criticidad, la frecuencia de cambio de los datos y la capacidad de restauración requerida, pueden utilizarse backups programados, snapshots, replicación u otros mecanismos.
Diferencia entre RTO y RPO: conceptos que suelen confundirse
Aunque suelen definirse en conjunto, el RTO y el RPO responden a dimensiones diferentes de la recuperación:
RTO: responde a la pregunta "¿Con qué rapidez debe restablecerse la operación?".
RPO: responde a la pregunta "¿Qué antigüedad máxima puede tener la información recuperada?".
Objetivo | Enfoque principal | ¿Qué define en la práctica? |
|---|---|---|
RTO | Tiempo de inactividad aceptable. | Tiempo objetivo para restablecer un servicio o proceso. |
RPO | Pérdida de datos tolerable. | Condiciona la frecuencia y la tecnología utilizada para crear puntos de recuperación. |
Cómo establecer prioridades de recuperación según el RTO
Definir el RTO de cada sistema permite establecer prioridades de recuperación y asignar los recursos necesarios según su impacto en la operación. No todos los servicios requieren el mismo tiempo de restablecimiento: cuanto mayor sea el impacto de una interrupción, menor deberá ser el RTO.
Una clasificación posible es:
Sistemas críticos: RTO bajo, de minutos a una hora. Su indisponibilidad afecta directamente la facturación, la producción, la atención a clientes o el cumplimiento de obligaciones. Por ejemplo, una plataforma de ventas, un sistema de cobros o una aplicación que interviene directamente en la producción.
Sistemas importantes: RTO de pocas horas. Su interrupción genera demoras o limita procesos relevantes, pero la organización puede sostener temporalmente la operación mediante procedimientos alternativos. Por ejemplo, un sistema de gestión de inventario, logística o administración.
Sistemas secundarios: RTO de un día o más. Pueden permanecer fuera de servicio durante más tiempo sin producir un impacto significativo inmediato. Por ejemplo, un portal interno de capacitación o una herramienta que no afecta de inmediato la operación principal.
Estos rangos son orientativos. Los valores concretos deben definirse a partir del impacto operativo, financiero, contractual y reputacional de cada sistema o proceso.
La pérdida máxima de datos tolerable según el RPO
Cuanto menor sea el RPO, mayor deberá ser la frecuencia con la que se generen puntos de recuperación y, en algunos casos, será necesario utilizar tecnologías adicionales al backup tradicional.
Por ejemplo, determinados sistemas transaccionales pueden requerir un RPO cercano a cero, por lo que utilizan mecanismos de replicación continua o síncrona para reducir al mínimo la pérdida de información. En cambio, un sistema con un RPO de cuatro horas debe generar puntos de recuperación con intervalos que no superen ese período durante toda la ventana operativa.
Definir el RPO implica equilibrar el impacto que tendría la pérdida de datos con el costo, la complejidad y los recursos necesarios para cumplir el objetivo.
Cómo se complementan el RTO y el RPO
El RTO y el RPO deben definirse en conjunto porque responden a aspectos distintos de la recuperación.
Un RTO bajo permite restablecer un sistema con rapidez, pero no garantiza que los datos recuperados sean recientes. Del mismo modo, un RPO bajo reduce la pérdida potencial de información, pero no asegura que el servicio pueda volver a estar operativo dentro del tiempo requerido.
Por ejemplo, una organización podría recuperar un sistema en cinco minutos y, aun así, restaurar datos de una semana atrás. También podría disponer de puntos de recuperación muy recientes, pero necesitar varias horas o días para restablecer la operación. Por eso, ambos objetivos deben ser coherentes con la criticidad del sistema y con el impacto que tendrían tanto la indisponibilidad como la pérdida de datos.
Cómo se cumple el RTO en un plan de recuperación
Para cumplir el RTO definido, la organización debe contar de antemano con una arquitectura adecuada, procedimientos documentados y recursos técnicos disponibles para ejecutar la recuperación.
Entre las medidas más habituales se encuentran:
Infraestructura redundante: servidores, almacenamiento, redes o servicios alternativos preparados para asumir la operación ante una falla.
Recuperación en una ubicación alternativa o en la nube: capacidad de restaurar o iniciar cargas de trabajo fuera del entorno afectado.
Procedimientos de recuperación documentados: definición de responsables, dependencias, secuencia de acciones y criterios para validar que el servicio volvió a operar correctamente.
Pruebas periódicas: ejercicios y restauraciones controladas para comprobar que el tiempo efectivo de recuperación se mantiene dentro del RTO establecido.
Cómo se cumple el RPO en la protección y recuperación de datos
Para cumplir el RPO definido, la organización debe generar puntos de recuperación con la frecuencia necesaria y verificar que puedan restaurarse correctamente.
Entre los mecanismos más utilizados se encuentran:
Backups programados: copias independientes generadas con intervalos acordes al RPO y conservadas mediante políticas de retención.
Snapshots: capturas del estado de un sistema o volumen en un momento determinado, útiles para recuperaciones rápidas. No reemplazan a los backups independientes cuando se necesita protección frente a fallas del almacenamiento, corrupción o ransomware.
Replicación continua o periódica: copia de los cambios hacia otra infraestructura para mantener una versión actualizada de los datos y reducir la pérdida potencial de información.
Estrategias híbridas: combinación de backups locales y externos, almacenamiento en la nube, snapshots y replicación, según la criticidad del sistema y los objetivos de recuperación definidos.
La replicación puede contribuir a reducir el RPO, pero no reemplaza al backup. Un borrado accidental, una corrupción de datos o un ataque de ransomware también pueden propagarse al entorno replicado. Por eso, debe complementarse con copias independientes y pruebas periódicas de restauración.
Ejemplo práctico de RTO y RPO
Una empresa de comercio electrónico sufre un corte de energía en su centro de datos. El sitio vuelve a estar operativo tres horas después y el último punto de recuperación disponible corresponde a doce horas antes del incidente.
En este caso:
El tiempo efectivo de recuperación fue de tres horas. Para determinar si se cumplió el RTO, debe compararse ese resultado con el objetivo definido previamente.
El punto de recuperación disponible tenía una antigüedad de doce horas. Si no existían otros mecanismos de registro o recuperación, podrían perderse los cambios realizados durante ese período, como transacciones, altas de usuarios o modificaciones de pedidos.
El ejemplo muestra que recuperar rápidamente un sistema no garantiza disponer de datos recientes. El cumplimiento debe evaluarse comparando el resultado obtenido con el RTO y el RPO establecidos para ese servicio.
Cómo definir los valores adecuados de RTO y RPO para una empresa
Definir estos objetivos no es una decisión exclusiva del área de sistemas; es una decisión de negocio. Requiere evaluar el impacto que una interrupción o una pérdida de datos tendría sobre cada proceso de negocio:
Impacto operativo: qué procesos se detendrían y durante cuánto tiempo podrían sostenerse mediante procedimientos alternativos.
Impacto financiero: cuánto costaría cada hora de indisponibilidad o la pérdida de información reciente.
Impacto contractual y regulatorio: qué obligaciones podrían incumplirse si un sistema no se recupera dentro del plazo requerido.
Impacto reputacional: cómo afectaría la interrupción a clientes, usuarios o proveedores.
Dependencias técnicas: qué aplicaciones, servicios, proveedores o componentes deben recuperarse previamente.
Costo y complejidad: qué infraestructura, licencias, conectividad y recursos humanos se necesitan para alcanzar los objetivos definidos.
Cuanto menores sean el RTO y el RPO, mayores suelen ser los requisitos de redundancia, automatización, protección de datos y capacidad de recuperación. Por eso, los valores deben establecerse según la criticidad de cada sistema y no aplicarse de manera uniforme a toda la organización.
Relación entre RTO, RPO y los planes de recuperación ante desastres
El plan de recuperación ante desastres define la estrategia, los recursos y los procedimientos necesarios para restablecer los sistemas y recuperar los datos después de una interrupción. El RTO y el RPO establecen los objetivos que ese plan debe poder cumplir.
Conviene distinguir este plan de recuperación ante desastres (Disaster Recovery Plan, DRP) del plan de continuidad del negocio (Business Continuity Plan, BCP). El DRP se centra en restablecer sistemas e infraestructura tecnológica dentro de los objetivos de RTO y RPO definidos, mientras que el BCP abarca la continuidad operativa integral de la organización, incluyendo procesos, personas e instalaciones. Ambos planes están relacionados, pero responden a alcances distintos y suelen desarrollarse de forma coordinada.
Además de describir la infraestructura y las tecnologías utilizadas, el plan debe identificar responsables, dependencias entre sistemas, secuencias de recuperación y criterios para validar que los servicios volvieron a operar correctamente.
También debe probarse de forma periódica mediante ejercicios y restauraciones controladas. Estas pruebas permiten verificar si los tiempos de recuperación y los puntos de recuperación disponibles se ajustan al RTO y al RPO definidos.
La definición de estos objetivos y la estructura del plan suelen apoyarse en marcos de referencia reconocidos internacionalmente, como la norma ISO 22301:2019 de gestión de la continuidad del negocio, la guía NIST SP 800-34 Rev. 1 para la planificación de contingencia de sistemas de información, y las prácticas profesionales de DRI International.
Herramientas y tecnologías para cumplir los objetivos de RTO y RPO
El cumplimiento del RTO y el RPO depende de una combinación de infraestructura, mecanismos de protección de datos, automatización y procedimientos probados.
Entre las tecnologías más utilizadas se encuentran:
Sistemas de backup automatizados y cifrados: permiten generar y conservar puntos de recuperación de acuerdo con el RPO definido.
Replicación de máquinas virtuales y datos: mantiene copias actualizadas en otra infraestructura para reducir la pérdida potencial de información y acelerar la recuperación.
Monitoreo de infraestructura: permite detectar fallas, degradaciones o condiciones que podrían afectar la disponibilidad de los sistemas.
Automatización de la recuperación: reduce tareas manuales, estandariza la secuencia de restauración y contribuye a disminuir los tiempos de recuperación.
Infraestructura redundante o alternativa: permite restablecer servicios en otro servidor, centro de datos o entorno en la nube cuando la infraestructura principal no está disponible.
Ninguna de estas tecnologías garantiza por sí sola el cumplimiento de los objetivos. Su efectividad debe verificarse mediante pruebas periódicas de backup, restauración y recuperación.
Beneficios de contar con objetivos RTO y RPO bien definidos
Definir el RTO y el RPO aporta previsibilidad a la estrategia de recuperación y permite alinear las decisiones técnicas con el impacto real sobre la operación.
Entre sus principales beneficios se encuentran:
Priorización de la recuperación: el equipo técnico sabe qué sistemas deben restablecerse primero y dentro de qué plazo.
Protección de los datos según su criticidad: la frecuencia y el tipo de backup, replicación o retención se definen en función de la pérdida máxima tolerable.
Dimensionamiento más preciso de la inversión: la infraestructura y los recursos se ajustan a las necesidades de cada sistema, evitando tanto la falta de capacidad como el sobredimensionamiento.
Mejor capacidad de validación: la organización puede comprobar mediante pruebas si los tiempos y puntos de recuperación disponibles cumplen los objetivos definidos.
Cómo definir una estrategia de recuperación efectiva
Una estrategia de recuperación debe partir de la criticidad de los sistemas, las dependencias entre aplicaciones y el impacto que tendría su indisponibilidad o la pérdida de datos. A partir de ese análisis, se definen los objetivos de RTO y RPO, la arquitectura necesaria, los procedimientos de recuperación y las pruebas que permitan validar su cumplimiento.
En ZNET relevamos la infraestructura, los mecanismos actuales de backup y recuperación, y las dependencias operativas de cada entorno. Con esa información, diseñamos estrategias de continuidad y recuperación orientadas a reducir el tiempo de indisponibilidad y la pérdida de datos dentro de objetivos previamente definidos.
También implementamos y validamos soluciones de backup, replicación, infraestructura redundante y recuperación en entornos alternativos, de acuerdo con la criticidad de cada sistema y las necesidades de la organización.
Preguntas frecuentes
¿Cuál es la diferencia más simple entre RTO y RPO?
El RTO define en cuánto tiempo debe restablecerse un sistema o proceso. El RPO define qué antigüedad máxima puede tener la información recuperada después de una interrupción.
¿Es posible configurar un RTO y RPO de cero?
En determinados sistemas es posible aproximarse a un RTO o un RPO cercano a cero mediante arquitecturas de alta disponibilidad, replicación síncrona y automatización. Sin embargo, garantizar un valor cero absoluto frente a cualquier tipo de incidente no es realista, ya que también deben contemplarse fallas lógicas, corrupción de datos, errores operativos y dependencias externas.
¿Qué pasa si mi empresa no tiene definidos estos objetivos?
Sin objetivos definidos resulta difícil establecer qué sistemas deben recuperarse primero, qué frecuencia de protección de datos se necesita y si la infraestructura actual puede responder dentro de los tiempos aceptables para la operación.
¿Cada cuánto se deben revisar el RTO y el RPO?
Deben revisarse periódicamente y siempre que cambien los procesos críticos, las aplicaciones, la infraestructura, las dependencias con proveedores o los requisitos regulatorios y contractuales. Como referencia, una revisión anual puede ser adecuada si no se produjeron cambios relevantes.