Objetivo
Traducir necesidades del negocio en objetivos de recuperación medibles y distinguirlos de garantías o resultados automáticos.
Contexto
RPO es el punto objetivo de recuperación: expresa cuánta información reciente podría perderse, medido como tiempo. Un RPO de cuatro horas implica diseñar copias o replicación para no retroceder más que ese intervalo en condiciones previstas.
RTO es el tiempo objetivo de recuperación: cuánto debería tardar el servicio en volver a un nivel acordado después de una interrupción. Ambos son objetivos de diseño y deben validarse; no son garantías por escribirlos en un documento.
Puntos clave
- Cada proceso puede necesitar objetivos diferentes según impacto y horario.
- Menores RPO y RTO suelen requerir más automatización, redundancia, capacidad y costo.
- Recuperar infraestructura no garantiza que aplicaciones y datos funcionen correctamente.
- Dependencias de identidad, red, proveedores y personas deben incluirse.
- El tiempo se mide desde un evento definido hasta un estado de servicio acordado.
Recomendaciones
- Identificar procesos y responsables, no empezar por servidores aislados.
- Estimar impacto por hora o etapa y alternativas manuales disponibles.
- Acordar RPO, RTO, prioridad y nivel mínimo de operación.
- Diseñar tecnología, documentación y personal para alcanzar los objetivos.
- Probar escenarios y ajustar objetivos o inversión según resultados.
Riesgos y advertencias
- Definir cero pérdida y recuperación inmediata sin análisis produce objetivos inviables.
- Medir solo restauración técnica ignora validación funcional y comunicación.
- No actualizar objetivos después de cambios de negocio vuelve obsoleto el plan.
Cómo validar el resultado
- Una prueba registra hora de inicio, hitos, recuperación y validación del usuario responsable.
- La pérdida observada y el tiempo total se comparan con objetivos definidos.
- Los desvíos generan acciones con responsable y fecha.
Buenas prácticas
Utilizar escenarios concretos y documentar supuestos. Diferenciar recuperación parcial, servicio degradado y operación completa ayuda a fijar objetivos realistas.
Próximos pasos
Realizar un taller breve con responsables de procesos críticos para acordar impacto, prioridades y objetivos antes de revisar la arquitectura de backup y continuidad.
Diferencia entre RPO y RTO con un ejemplo
Supongamos que un sistema deja de funcionar a las 15:00. Si el RPO acordado es de cuatro horas, el diseño debería permitir recuperar un punto no anterior a las 11:00 bajo el escenario previsto. Si el RTO es de dos horas, el servicio mínimo acordado debería estar disponible antes de las 17:00. Son dos mediciones distintas: pérdida de datos y duración de la interrupción.
| Objetivo | Mide | Pregunta para el negocio |
|---|---|---|
| RPO | Pérdida de información expresada como tiempo. | ¿Cuánto trabajo reciente podemos reconstruir o perder? |
| RTO | Tiempo hasta recuperar el nivel de servicio acordado. | ¿Cuánto puede permanecer interrumpido este proceso? |
Preguntas frecuentes
¿La frecuencia del backup es igual al RPO?
No siempre. La frecuencia influye, pero también importan la finalización de las copias, la replicación, la consistencia y el punto realmente recuperable.
¿El RTO termina cuando enciende el servidor?
Solo si ese fue el estado acordado. Para un proceso de negocio suele incluir aplicación, datos, accesos, conectividad y validación funcional.
El siguiente paso es revisar qué es un backup recuperable y relacionar las pruebas con los objetivos de continuidad.