¿Qué es RPO?

El RPO, o Recovery Point Objective, expresa cuántos datos puede permitirse perder una organización, medidos como un intervalo de tiempo. Si una aplicación tiene un RPO de quince minutos, el plan de protección debe permitir recuperarla sin retroceder más de ese intervalo respecto al incidente considerado. No significa que recuperar el servicio tarde quince minutos: esa es otra conversación, aunque ambas suelen empezar cuando alguien descubre que la copia de anoche ya no basta.

El dato útil es el último punto realmente recuperable, no la hora que aparece en el calendario del trabajo de backup. Una tarea puede arrancar puntualmente y terminar con errores, dejar fuera una base de datos o generar un conjunto que no se pueda restaurar de forma coherente. El objetivo necesita evidencia, porque tener archivos guardados y poder recuperar una aplicación son resultados distintos.

-InfraCrew dice: El calendario del backup promete muchas cosas. La restauración es quien comprueba si las cumple.-

Dos horas que conviene escribir en el parte

Imaginemos una incidencia a las 10:00 en una aplicación de pedidos. Tras revisar copias y registros, el equipo consigue recuperar un estado válido correspondiente a las 09:40; los cambios posteriores no están disponibles. La distancia entre ambos momentos es de veinte minutos, de modo que ese resultado no cumple un RPO fijado en quince. Las horas son un ejemplo de cálculo, no una recomendación para todas las empresas.

Supongamos además que el servicio vuelve a funcionar a las 10:45. Esos cuarenta y cinco minutos describen la interrupción de este escenario y se comparan con el RTO, el objetivo de tiempo de recuperación. Conseguir arrancar muy rápido con información demasiado antigua puede cumplir uno de los objetivos y fallar el otro; recuperar datos recientes después de muchas horas puede producir el caso contrario.

El intervalo tampoco cuenta por sí solo cuántas operaciones faltan. Veinte minutos durante el cierre de pedidos pueden representar un impacto distinto a veinte minutos de madrugada. Para decidir si la pérdida es aceptable hay que hablar con quien conoce el proceso: qué cambios se generan, cuáles se pueden reconstruir y cuánto trabajo o daño supone hacerlo.

La frecuencia de copia es solo una parte

Programar una copia cada quince minutos puede formar parte del diseño, pero no garantiza automáticamente un RPO de quince minutos. Hay que comprobar qué instante representa la copia, cuándo queda utilizable y si existe retraso al trasladarla al destino de recuperación. Una tarea atrasada o encadenada a otra fallida puede ampliar la ventana real sin que nadie haya cambiado el horario.

En una base de datos, un diseño puede combinar una copia base con registros de transacciones para una recuperación a un punto en el tiempo posterior a esa copia. Eso exige conservar una secuencia válida, disponer de las piezas necesarias y ensayar el procedimiento del motor concreto. No basta con aumentar la frecuencia de una tarea y dar por hecho que cualquier segundo intermedio se podrá elegir después.

La replicación también necesita una pregunta incómoda: ¿qué ocurre si lo que viaja al destino es un borrado o una corrupción? Una réplica reciente ayuda ante determinados fallos de infraestructura, pero puede reproducir un cambio no deseado. Si hace falta retroceder a un estado anterior, el diseño debe ofrecer puntos históricos adecuados; una segunda ubicación, por sí sola, no demuestra esa capacidad.

-InfraCrew dice: Dos copias del mismo desastre siguen siendo un desastre, aunque una viva en otra ciudad.-

También importa la coherencia entre componentes. Recuperar pedidos de las 09:55 y documentos asociados de las 09:20 puede exigir conciliación antes de reabrir el servicio. En un ejercicio de recuperación conviene comprobar una operación completa, con sus dependencias, en lugar de validar cada máquina por separado y asumir que el conjunto encaja.

Definirlo con negocio y demostrarlo restaurando

Un RPO se fija por carga y escenario, no por orgullo técnico. Un catálogo que se puede reconstruir quizá admita una pérdida mayor que una aplicación que registra compromisos con clientes. La decisión debe quedar escrita junto a su responsable, su alcance y las condiciones consideradas: no es lo mismo perder un servidor que necesitar recuperar tras detectar una alteración antigua.

Después se contrasta el objetivo con coste y capacidad operativa. Más frecuencia, retención y destinos pueden exigir más recursos y vigilancia, además de procedimientos que alguien sepa ejecutar. Una cifra ambiciosa sin presupuesto, personal ni pruebas sirve de poco; si el diseño no llega, hay que corregirlo o revisar el objetivo con quien asume el impacto.

Para probarlo, prepara una restauración aislada con datos de prueba identificables y registra el punto recuperado. Anota el momento del incidente simulado, la última operación válida encontrada y las comprobaciones funcionales realizadas. Conserva además los tiempos del ejercicio para evaluar el RTO por separado, sin confundir rapidez de arranque con actualidad de los datos.

La vigilancia diaria debería responder a cuánto tiempo ha pasado desde el último punto válido y avisar antes de superar el margen acordado. Cuando se incumpla, el parte necesita una causa comprobable y una acción: trabajos fallidos, registros ausentes o un destino que acumula retraso, por ejemplo. El valor del RPO está en convertir una tolerancia del negocio en una capacidad que el equipo puede demostrar.

-InfraCrew dice: Quince minutos escritos en un documento caben en cualquier presupuesto. Demostrarlos restaurando ya requiere trabajo.-

Diccionario de la Crew

• RPO: pérdida de datos máxima tolerable expresada como tiempo.
• RTO: tiempo máximo objetivo para restablecer el servicio tras una interrupción.
• Punto recuperable: estado de los datos al que el procedimiento disponible permite volver de forma válida.
• Recuperación a un punto en el tiempo: restauración hasta un instante concreto dentro de la cobertura de copias y registros disponibles.
• Replicación: traslado de cambios a otro sistema; su utilidad depende del fallo que se quiera cubrir.