RTO y RPO sin humo: dos números que se firman sin haberlos calculado

«RPO de una hora, RTO de cuatro». Lo hemos escuchado en reuniones donde nadie había cronometrado nunca cuánto tarda en volver un servidor de esa casa. Los dos números viajan juntos, suenan a rigor, quedan bien en el acta y casi siempre están escritos al revés: en lugar de salir de lo que el negocio aguanta, salen de lo que la herramienta de copia hace hoy. Un RPO no es una capacidad técnica. Es una promesa con precio, y alguien la va a cobrar el peor día del año.

Lo que viene es la conversación que tenemos cada vez que alguien nos enseña un plan de continuidad heredado: cuatro o cinco preguntas con las que ese plan se cae solo. Casi siempre hay un número de los dos que nadie del comité podría defender delante de un auditor, o delante del director financiero un martes a las once. Vale la pena saber cuál es antes de que lo pregunte alguien de fuera.

Traducidos a algo que se pueda decidir

El RPO (Recovery Point Objective) no es «cuántos datos pierdes». Esa formulación no la puede decidir nadie, porque los datos no se miden en gigas cuando duelen. La formulación útil es: cuánto trabajo estás dispuesto a repetir. Si volvemos a la copia de anoche, ¿qué se ha hecho hoy, quién lo rehace y en cuántas horas? Con cuarenta personas trabajando, un RPO de ocho horas son trescientas veinte horas-persona de trabajo repetido. Y eso contando solo lo que se puede repetir: los albaranes se vuelven a teclear, la llamada que entró a las once y media no.

El RTO (Recovery Time Objective) tampoco es «lo que tarda el restore». Es cuánto tiempo puede estar la empresa sin ese servicio, contado desde que empieza el problema —no desde que alguien se sienta a restaurar— hasta que el servicio está otra vez en producción y validado. Entre esos dos extremos hay cuatro relojes distintos, y el único que aparece en los planes es el del restore. Es exactamente el que menos manda.

Tu RPO real es el de la última copia verificada

Aquí está el primer engaño, y es de los caros. La copia que terminó a las 22:04 no es un punto de recuperación: es la intención de un punto de recuperación. Lo será cuando alguien haya leído sus bloques enteros y comprobado que los checksums cuadran. La documentación de Proxmox Backup Server lo dice sin adornos al explicar por qué hay que reverificar: «se recomienda que reverifiques todas las copias al menos mensualmente, incluso si una verificación anterior fue correcta», porque «los discos físicos son susceptibles de dañarse con el tiempo, lo que puede hacer que una copia antigua y funcional se corrompa, en un proceso conocido como bit rot o degradación de datos».

La misma documentación recomienda una pauta que en la práctica casi nadie tiene montada: un trabajo de verificación frecuente para lo nuevo y otro semanal o mensual que lo reverifique todo. Si tu plan promete un RPO de una hora y tus copias horarias no se verifican nunca, el número que puedes defender no es una hora: es el tiempo que hace desde la última copia que sabes leer entera. La diferencia entre esas dos frases es un proyecto de recuperación con el consejo de administración mirando.

Y hay un segundo desplazamiento, el que introduce un atacante. Tu frecuencia de copia fija el RPO del incidente tonto: un borrado, una tabla machacada, un disco muerto. Tu retención fija el RPO del incidente malo, porque la copia que sirve no es la última, es la última anterior a que entraran. El Active Adversary Report 2026 de Sophos, publicado el 24 de febrero, situó la mediana de permanencia del atacante en la red en tres días y midió en 3,4 horas la mediana hasta que llegan al servidor de Directorio Activo, un 70 % más rápido que el año anterior. Con esa forma, una retención corta y una detección lenta se multiplican: la copia buena queda por detrás de la primera que mira todo el mundo. Es la otra cara de lo que contamos con las cifras del informe anual de ransomware de la misma casa cuando explicamos por qué restaurar no es recuperar.

Los cuatro relojes del RTO

El primero es detectar: desde que el servicio empieza a fallar hasta que alguien lo sabe con certeza. En una caída limpia son minutos; en una corrupción lenta o en un cifrado por lotes son horas, y a veces lo descubre un usuario antes que la monitorización. El segundo es decidir, y es donde hemos visto irse más tiempo en las recuperaciones que se alargan. El motivo casi nunca es técnico: decidir significa que alguien acepte, por escrito, que se pierde el trabajo de las últimas horas, y esa firma no la quiere poner nadie a las tres de la mañana.

El tercero es restaurar, el único que aparece en los planes y el único que se puede calcular con una regla de tres antes de que pase nada; lo hacemos en el apartado siguiente. Y el cuarto es validar y reabrir: comprobar que el sistema restaurado hace lo que tiene que hacer, reprocesar las colas que se quedaron a medias, reconciliar con lo que sí funcionó durante la caída y avisar a la gente de que ya puede volver a trabajar. Es la parte que convierte un servidor encendido en un servicio en marcha y, en un ERP con integraciones, puede durar más que el propio restore.

No tenemos una cifra pública que ponerle al reloj de la decisión, y no vamos a inventarla. Sí tenemos la observación repetida de que es el que más se estira y el único que se puede acortar sin gastar un euro: se acorta escribiendo antes quién decide, con qué criterio y hasta qué hora se espera. En nuestra experiencia, un plan que nombra a una persona y una hora límite recorta más RTO que doblar el ancho de banda.

La aritmética que casi nadie hace

Coge el volumen que tendrías que restaurar y el enlace por el que va a pasar. La cuenta es de primaria y desmonta más planes que cualquier auditoría:

La conclusión incómoda de la regla de tres es que un RTO no se decide: se mide. Y se mide una vez al año con un cronómetro de verdad, restaurando algo de verdad. No debería firmarse ningún número que no se haya cronometrado en un ensayo, porque el día que falla no hay margen para descubrir que el papel decía cuatro horas y la cabina da 180 MB/s.

El número que falta en casi todos los planes

RTO y RPO describen un mundo binario: el servicio está o no está. La realidad de una recuperación es un rato largo de estar a medias, y ese rato no tiene número asignado en ningún plan que hayamos revisado. ¿Qué significa «funcionar a medias» en tu empresa? ¿Se puede facturar a mano un día? ¿Se puede recibir mercancía sin el ERP y meterla después? ¿El taller para, o el taller sigue y lo que se detiene es la administración?

De esa conversación sale lo que de verdad guía una recuperación: el orden. Qué vuelve primero, qué vuelve después y qué puede esperar a mañana. Si el orden no está escrito, lo decide quien grite más fuerte por teléfono, que casi nunca es quien tiene el sistema más crítico. Escribir tres líneas de prioridades cuesta una reunión y ahorra las dos peores horas del incidente. Es el mismo ejercicio que propusimos tras la caída de Microsoft 365 de julio, cuando lo que había que decidir no era cómo arreglarlo, sino cómo seguir trabajando mientras tanto.

Cuándo NO hay que bajar el número

Vender continuidad es fácil: siempre se puede proponer un número más pequeño y cobrarlo. Nos parece más honesto decir cuándo no toca. Bajar el RPO de veinticuatro horas a quince minutos multiplica el coste de almacenamiento y de enlace, y en muchas empresas no cambia nada, porque el que hace daño es el RTO: da igual perder quince minutos de datos si vas a estar dos días parado. Aplicar el RPO del ERP al servidor de ficheros es otro clásico caro; y comprar réplica síncrona para un sistema que se usa de nueve a seis es pagar un seguro contra un riesgo que no tienes.

Hay además una parte del número que no es tuya. Si el servicio vive en una nube pública, tu RTO incluye el tiempo de recuperación de un proveedor al que no puedes llamar y con el que no negocias prioridad: lo repasamos con el reloj en la mano durante la caída de AWS CloudFront de julio. Y si tu respuesta a todo esto es «para eso están las copias», conviene mirar de vez en cuando lo que pasa cuando el borrado alcanza también a la copia: es el escenario que convierte un RPO de una hora en una hoja de cálculo reconstruida a mano.

Las cinco líneas que sí escribimos

La pregunta que hacemos primero

Cuando revisamos un plan de continuidad no empezamos por la tecnología. Empezamos por esta: ¿cuándo fue la última vez que restaurasteis algo de verdad, y cuánto tardó? Si la respuesta es una fecha y un número, el resto de la conversación es afinar. Si la respuesta es «las copias van bien, no dan errores», entonces no tenéis un RTO: tenéis una expectativa, y las expectativas no se restauran.

Fuentes: recomendación de reverificar mensualmente, citas literales sobre el bit rot y pauta de trabajos de verificación — documentación de mantenimiento de Proxmox Backup Server; opción --live-restore y su descripción literal — manual de qmrestore de Proxmox VE; mediana de permanencia del atacante en tres días y llegada al Directorio Activo en horas — Sophos Active Adversary Report 2026 (febrero de 2026). Las cuentas de tiempo de restauración son aritmética directa a partir del ancho de banda nominal y se presentan como cota inferior, no como estimación. Imagen de portada: «Departure board at Hackerbrücke S-Bahn station in München», Robert von Oliva, CC0, vía Wikimedia Commons.