Una base de datos vuelve a arrancar después de un incidente. El equipo afirma que la recuperación fue rápida, pero la aplicación todavía no puede acceder y faltan las últimas operaciones. Dos preguntas siguen abiertas: cuándo vuelve a funcionar el servicio y hasta qué punto se han recuperado los datos.
RTO y RPO permiten expresar esas necesidades por separado. Son objetivos que deben tener un alcance definido y contrastarse con pruebas; no son propiedades automáticas de una copia de seguridad.
Dos objetivos para dos consecuencias distintas
El RTO, objetivo de tiempo de recuperación, expresa cuánto tiempo de interrupción admite el servicio antes de volver a cumplir el alcance acordado. El RPO, objetivo de punto de recuperación, expresa la pérdida de datos temporal que se admite respecto al incidente.
La guía de objetivos de recuperación de AWS relaciona ambos con el impacto del negocio y las dependencias de cada carga. No propone un valor universal que deba aplicarse a toda plataforma.
Define quién utiliza el servicio y qué operación debe poder realizar después de recuperarlo. Para un informe, puede bastar una consulta validada; para una aplicación transaccional, podría ser necesario volver a registrar operaciones.
Un incidente con tiempos diferentes
Utilicemos un ejemplo construido. Todas las horas pertenecen al mismo día y zona horaria. El objetivo acordado para el ejercicio es un RTO de 60 minutos y un RPO de 5 minutos. No son recomendaciones para una empresa concreta.
| Hito | Hora |
|---|---|
| Último punto de datos finalmente recuperado y validado | 09:52 |
| Interrupción del servicio | 10:00 |
| Detección del incidente | 10:06 |
| Inicio de la restauración técnica | 10:12 |
| Base de datos disponible | 10:35 |
| Consumidor validado y servicio restablecido | 10:48 |
La recuperación completa tarda 48 minutos desde la interrupción hasta el servicio restablecido. Cumple el RTO de 60 minutos del ejemplo. Medir solo los 23 minutos de restauración técnica dejaría fuera detección, preparación y validación.
El punto recuperado queda 8 minutos antes de la interrupción. No cumple el RPO de 5 minutos. Que el sistema vuelva dentro del tiempo admitido no compensa esa diferencia.
Esos 8 minutos describen una ventana temporal, no el número ni el valor de las operaciones ausentes. Para conocer el impacto hay que identificar qué ocurrió durante ella. Si existen fuentes que permitan reconstruir más datos, su recuperación debe incorporarse al resultado final y al tiempo necesario para validarlo.
La frecuencia del backup no demuestra el RPO
Programar una copia cada cierto intervalo no garantiza que todas las copias terminen, sean accesibles o permitan recuperar el punto previsto. También pueden intervenir registros de cambios, retrasos de replicación y dependencias externas.
La comparación entre backup y réplica ayuda a identificar qué conserva cada mecanismo. Después hay que comprobar el punto realmente recuperable en el escenario elegido.
Un respaldo de la base y otro de los documentos pueden tener cortes diferentes. Si el informe necesita ambos, el alcance recuperado debe explicar esa relación; no basta con elegir el timestamp más reciente de cualquiera de las dos piezas.
Define el reloj del servicio, no solo el de una herramienta
Registra interrupción, detección, decisión, ejecución y validación como hitos separados. Una mejora en la herramienta de restauración puede tener poco efecto si la mayor demora ocurre antes de que alguien inicie el procedimiento.
Si el servicio vuelve de forma parcial, indica qué operaciones están disponibles y cuáles siguen pendientes. No declares recuperado todo el producto por haber habilitado una pantalla de consulta.
La vuelta a un modo degradado puede ser útil cuando su alcance está acordado. El criterio debe permitir al equipo y al usuario reconocer ese estado.
Revisa las dependencias y los periodos críticos
Una aplicación depende de identidad, red, datos y otros servicios. Si uno de ellos tarda más de lo que admite el objetivo global, necesitas una alternativa o revisar el diseño.
Prioriza según el impacto del proceso. Un cierre operativo y una exploración histórica pueden tolerar interrupciones diferentes aunque compartan plataforma. Documenta las condiciones especiales, como ventanas de cierre, sin asumir que todas las cargas tienen la misma criticidad.
Elegir objetivos muy estrictos sin una necesidad identificada puede añadir coste y complejidad. Elegirlos solo porque la arquitectura actual los cumple puede dejar sin cubrir una necesidad importante.
Convierte los objetivos en una prueba de aceptación
Prepara una prueba de restauración con el incidente, los accesos disponibles y los consumidores que deben volver. Guarda los tiempos y la evidencia del punto recuperado.
Si un objetivo no se cumple, identifica la causa y una acción verificable: mejorar detección, conservar otra pieza, cambiar la secuencia o corregir una dependencia. Repite la parte afectada para comprobar el resultado.
Para definir estos objetivos en una plataforma Big Data, comparte con Nexeus Big Data qué operaciones deben continuar y qué información no puede quedar fuera. Esa conversación convierte las siglas en criterios de recuperación que el equipo puede demostrar.