Un ejemplo
Una tienda online decide que su sistema de pedidos debe volver a funcionar en 4 horas (RTO) y que como mucho puede perder 15 minutos de pedidos (RPO). Una copia de seguridad diaria no cumple ese RPO: la empresa necesita replicación continua o copias muy frecuentes. Una restauración que tarda un día entero no cumple ese RTO: necesita un entorno de reserva o un procedimiento de recuperación más rápido.
Cómo se fijan
El RTO y el RPO salen del análisis de impacto en el negocio, no de lo que la tecnología actual permite por casualidad. El negocio define lo que puede tolerar; IT diseña y presupuesta una solución que lo cumpla. Los valores más bajos cuestan más, así que los objetivos deben fijarse por sistema, reservando los más exigentes para lo verdaderamente crítico.
Comprobarlos en la práctica
Los objetivos solo significan algo si se han probado. Las pruebas periódicas de restauración y los ejercicios de recuperación ante desastres muestran el tiempo de recuperación y la pérdida de datos reales. El ransomware es la prueba más dura: las copias pueden estar cifradas también y los sistemas deben reconstruirse limpios, por lo que la recuperación suele tardar mucho más de lo previsto.
Métricas relacionadas
El RTO sirve para planificar la recuperación antes de un incidente. El MTTD y el MTTR miden cuánto tardan en la práctica la detección y la respuesta cuando ocurren incidentes. Ambos aparecen en los planes de continuidad de negocio y en los requisitos de resiliencia de DORA y NIS2.
