El objetivo de punto de recuperación (RPO) es la cantidad máxima de datos —medida en tiempo— que tu organización puede perder tras una interrupción imprevista y seguir funcionando dentro de unos límites aceptables.

Piensa en el RPO como un reloj de pérdida de datos: empieza a contar hacia atrás desde el momento en que se produce una interrupción del servicio, un ciberataque o un error humano, y se detiene en tu último punto de copia de seguridad o replicación utilizable. Cada segundo que transcurre entre esos dos puntos son datos que quizá nunca recuperes.

NISTdefine el RPOcomo «el momento en el tiempo hasta el que deben recuperarse los datos tras una interrupción del servicio». Esa definición resulta engañosamente sencilla. En la práctica, establecer el RPO adecuado plantea cuestiones importantes sobre qué cargas de trabajo son las más importantes, con qué frecuencia se realizan las copias de seguridad y cuánto se invierte en la infraestructura de replicación.

Los ciberataques, las interrupciones en el servicio de la nube y los borrados accidentales se producen en momentos que escapan a tu control. Las organizaciones que definen objetivos claros de RPO —y los cumplen mediante copias de seguridad automatizadas y basadas en políticas— se posicionan para recuperarse dentro de los límites de tolerancia del negocio, en lugar de tener que actuar a toda prisa una vez que se ha producido el incidente.

Esta guía te explica cómo funciona el RPO, en qué se diferencia del objetivo de tiempo de recuperación (RTO), cuáles son algunos ejemplos reales, cómo calcular el RPO y el papel fundamental que desempeña el RPO en la ciberresiliencia.

Cómo funciona el RPO en la planificación de la continuidad del negocio

El RPO es el «reloj de pérdida de datos» que determina la frecuencia de tus copias de seguridad. Si tu RPO para una base de datos es de una hora, las copias de seguridad deben realizarse al menos cada 60 minutos. Si no mantienes esa cadencia, es posible que ya hayas superado tu umbral de tolerancia antes de que ocurra ningún problema.

En un plan de continuidad del negocio, el RPO constituye, junto con el RTO, uno de los dos pilares de la recuperación. Mientras que el RTO responde a la pregunta «¿En cuánto tiempo podemos volver a poner en marcha los sistemas?», el RPO responde a la pregunta «¿Qué grado de actualidad tendrán los datos recuperados?». Ambos forman parte de la estrategia más amplia de Recovery ante desastres, y ambos deben validarse mediante pruebas periódicas, no solo quedar documentados en una carpeta.

La RPO también puede tener una vertiente relacionada con el cumplimiento normativo:

• Las normativas como la HIPAA suelen exigir a las organizaciones sanitarias que conserven copias recuperables de la información sanitaria electrónica de los pacientes.
• La ley SOX incluye disposiciones relativas a la conservación de los registros financieros de forma que sean auditables y estén intactos.
• El RGPD establece que el tratamiento de datos personales debe poder restablecerse en un plazo razonable tras un incidente técnico.

Cuando un ataque cifra los datos de producción, la diferencia entre tu última copia de seguridad válida y la marca de tiempo del cifrado corresponde a los datos que se pierden. Esa diferencia es tu RPO en la práctica – y ayuda a determinar si la recuperación lleva unas horas o se convierte en una crisis.

Conclusión práctica: el RPO no es una cifra que se establezca una vez y se olvide. Debe reflejar las tasas actuales de cambio de datos, los requisitos de cumplimiento normativo y la realidad del panorama de amenazas – y debe aplicarse mediante políticas de copias de seguridad automatizadas.

RPO frente a RTO: ¿Cuál es la diferencia?

El RPO y el RTO son las dos caras de la misma moneda en lo que respecta a Recovery, pero miden aspectos diferentes.

El RPO analiza lo ocurrido desde el momento del fallo. Se pregunta: «¿Cuántos datos podemos permitirnos perder?». La respuesta se expresa en tiempo —minutos, horas o días— y representa el intervalo entre la última copia de seguridad válida y la interrupción del servicio.

El RTO se centra en el futuro desde el momento en que se produce el fallo. Se pregunta: «¿Con qué rapidez deben volver a estar operativos los sistemas?». La respuesta también se expresa en términos de tiempo, pero mide la tolerancia al tiempo de inactividad, en lugar de la tolerancia a la pérdida de datos.

Ambos indicadores deben definirse conjuntamente. Una organización con un RPO de 15 minutos pero un RTO de 24 horas tiene datos recientes que permanecen inactivos durante un día entero. Por el contrario, un RTO de cuatro horas combinado con un RPO de 24 horas significa que los sistemas se recuperan rápidamente, pero con datos obsoletos.

Alinear los objetivos de RPO y RTO antes de que se produzca un incidente —y validarlos mediante pruebas periódicas de Recovery— puede marcar la diferencia entre una respuesta planificada y una reacción precipitada.

Niveles de RPO y ejemplos reales

No todas las cargas de trabajo merecen el mismo RPO. Clasificar los RPO según su importancia para el negocio ayuda a mantener una protección rigurosa donde es necesario y a mantener los costes bajo control donde no lo es.

Nivel 0: RPO casi nulo (de segundos a minutos): Las bases de datos de transacciones financieras, las historias clínicas electrónicas de pacientes y las plataformas de negociación en tiempo real suelen requerir protección continua de datos (CDP) o replicación síncrona. Estas cargas de trabajo generan ingresos o tienen implicaciones normativas cada segundo, por lo que incluso unos minutos de pérdida de datos pueden ser difíciles de asumir. Las organizaciones que implementan un RPO casi nulo suelen utilizar la CDP o la replicación síncrona para ayudar a minimizar la ventana de pérdida de datos.

Nivel 1: 1–4 horas: Los sistemas de gestión de relaciones con los clientes (CRM), las plataformas de correo electrónico y los sistemas de tramitación de pedidos suelen clasificarse en este nivel. Las copias de seguridad incrementales frecuentes —cada 15 a 60 minutos— ayudan a mantener la pérdida de datos dentro de los límites de tolerancia. El coste es moderado, y el impacto empresarial de perder unas pocas horas de correo electrónico o de actualizaciones del CRM suele ser gestionable mediante la reintroducción manual de los datos.

Nivel 2: De 4 a 12 horas: Las herramientas de colaboración interna, los entornos de desarrollo y las plataformas de gestión de proyectos suelen funcionar en este intervalo. Las copias de seguridad programadas cada 4 a 6 horas pueden ofrecer un equilibrio entre la protección y los costes de almacenamiento.

Nivel 3: 12– 24 horas: Los archivos de análisis de marketing, los registros históricos y la documentación de referencia suelen admitir copias de seguridad diarias en la nube. Los datos cambian lentamente y su reconstrucción es factible, lo que hace que las copias de seguridad diarias resulten rentables.

La organización por niveles ayuda a las empresas a destinar la mayor parte de su inversión a proteger aquellas cargas de trabajo en las que cada minuto de pérdida de datos supone el mayor coste, al tiempo que evita un gasto excesivo en archivos que solo se actualizan una vez a la semana.

RPO y ciberresiliencia

Al ransomware no le importa tu calendario de copias de seguridad  –, pero tu RPO determina el margen de maniobra que tienen los atacantes. Un RPO ajustado significa que hay menos datos entre tu última copia de seguridad inmutable y el momento del cifrado, lo que ayuda a reducir el alcance de un ataque.

La ciberresiliencia no depende únicamente de la frecuencia de las copias de seguridad. Las copias de seguridad inmutables y aisladas físicamente ayudan a protegerse frente a los atacantes que comprometen los entornos de producción, de modo que estos no puedan acceder a los datos de Recovery ni alterarlos. Cuando esas copias de seguridad se almacenan fuera de la cuenta principal en la nube, se añade un nivel de aislamiento que el ransomware simplemente no puede traspasar.

Aquí es donde Clumio by Commvault encaja en tu estrategia de RPO. ConClumio, almacenas los datos de copia de seguridad en un entorno aislado y totalmente gestionado, ajeno a tu cuenta principal de AWS. La recuperación granular en un momento determinado te permite restaurar los datos a un momento preciso anterior al ataque, lo que ayuda a minimizar la pérdida de datos hasta el RPO que hayas definido. Está diseñado para ayudarte a mantener el control de tu recuperación sin depender de la misma infraestructura que el atacante ha comprometido.

Las organizaciones que mantienen unos RPO estrictos con copias de seguridad inmutables y aisladas pueden evitar el pago de rescates, ya que pueden recuperar datos limpios de forma independiente.

La fórmula es sencilla: un RPO más estricto, junto con copias de seguridad inmutables y aisladas, suele traducirse en una superficie de ataque menor y una Recovery más rápida y limpia. Esa es la base de la ciberresiliencia.