RPO y RTO sin jerga: cuánto puede perder y esperar

RPO y RTO son dos siglas que ordenan cualquier plan de continuidad. Bien entendidas, permiten decidir cuánto invertir en respaldo y recuperación sin gastar de más en lo que no es crítico.

• RPO: cuántos datos, medidos en tiempo, la empresa puede perder.
• RTO: cuánto tiempo puede estar detenido un sistema.
• Los valores declarados solo son confiables si se miden en un simulacro.

Los dos conceptos en simple

El RPO (punto objetivo de recuperación) responde a cuánto trabajo se puede perder: si se acepta perder el trabajo de las últimas horas o del último día, ese es el RPO. El RTO (tiempo objetivo de recuperación) responde a cuánto se puede esperar para volver a operar. Ambos se definen por sistema, no para toda la empresa.

Cómo definirlos

Conviene conversar con quienes usan cada sistema. El correo, el sistema de facturación y el servidor de archivos no tienen la misma urgencia. Una forma práctica de hacerlo:

1. Listar los sistemas que sostienen la operación.
2. Preguntar qué ocurre si se detienen una hora, un día o una semana.
3. Preguntar qué información sería difícil de reconstruir.
4. Anotar un RPO y un RTO por sistema, y quién los aprueba.

Estos valores determinan la frecuencia de los respaldos y el tipo de solución de recuperación; vea también Respaldo 3-2-1.

Declarar no es lo mismo que medir

Un RTO escrito en un documento es una intención. Se vuelve un dato cuando se realiza un simulacro: se restaura el sistema, se cronometra el proceso, se verifica la integridad de la información y se compara el resultado con lo declarado. Sincronizar los relojes de los equipos con una fuente horaria confiable ayuda a que los tiempos registrados sean consistentes, y el registro se cierra con la firma de quien dirigió la prueba.

Para quienes buscan una referencia formal sobre planes de contingencia, el documento NIST SP 800-34 Rev. 1, «Contingency Planning Guide for Federal Information Systems», ofrece una estructura detallada.

Qué hacer

• Definir RPO y RTO para los tres o cuatro sistemas más importantes.
• Programar un simulacro de recuperación al menos con esos sistemas.
• Registrar el tiempo real y las diferencias con lo declarado.
• Ajustar el respaldo o la infraestructura si la brecha es relevante.
• Repetir el ejercicio después de cambios importantes.

Preguntas frecuentes

¿Puedo tener un RTO distinto para cada sistema? Sí, y es lo recomendable: así se concentra el esfuerzo en lo que realmente importa.

¿Qué pasa si el simulacro no cumple lo declarado? Es un resultado útil: permite corregir antes de un incidente real, ya sea ajustando la solución o revisando las expectativas.

¿Necesito un plan formal? Un plan breve, escrito y probado es suficiente para empezar.

En nuestro trabajo con organizaciones chilenas, realizamos simulacros con RPO y RTO medidos, y vemos que ese ejercicio aclara la distancia entre lo declarado y lo real.

IT Lab acompaña a organizaciones chilenas en esto. Contáctenos.

Fuentes

• NIST, SP 800-34 Rev. 1, «Contingency Planning Guide for Federal Information Systems»: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final