RTO i RPO sense fum: dues xifres que se signen sense haver-les calculat

«RPO d'una hora, RTO de quatre». Ho hem sentit en reunions on ningú no havia cronometrat mai quant triga a tornar un servidor d'aquella casa. Les dues xifres viatgen juntes, sonen a rigor, queden bé a l'acta i gairebé sempre estan escrites al revés: en comptes de sortir del que el negoci aguanta, surten del que l'eina de còpia fa avui. Un RPO no és una capacitat tècnica. És una promesa amb preu, i algú la cobrarà el pitjor dia de l'any.

El que ve és la conversa que tenim cada cop que algú ens ensenya un pla de continuïtat heretat: quatre o cinc preguntes amb què aquell pla cau tot sol. Gairebé sempre hi ha una de les dues xifres que ningú del comitè no podria defensar davant d'un auditor, o davant del director financer un dimarts a les onze. Val la pena saber quina és abans que ho pregunti algú de fora.

Traduïts a alguna cosa que es pugui decidir

L'RPO (Recovery Point Objective) no és «quantes dades perds». Aquesta formulació no la pot decidir ningú, perquè les dades no es mesuren en gigues quan fan mal. La formulació útil és: quanta feina estàs disposat a repetir. Si tornem a la còpia d'ahir a la nit, què s'ha fet avui, qui ho refà i en quantes hores? Amb quaranta persones treballant, un RPO de vuit hores són tres-centes vint hores-persona de feina repetida. I això comptant només el que es pot repetir: els albarans es tornen a teclejar, la trucada que va entrar a dos quarts de dotze no.

L'RTO (Recovery Time Objective) tampoc no és «el que triga el restore». És quant de temps pot estar l'empresa sense aquell servei, comptat des que comença el problema —no des que algú s'asseu a restaurar— fins que el servei torna a estar en producció i validat. Entre aquests dos extrems hi ha quatre rellotges diferents, i l'únic que apareix als plans és el del restore. És exactament el que menys mana.

El teu RPO real és el de l'última còpia verificada

Aquí hi ha el primer engany, i és dels cars. La còpia que va acabar a les 22:04 no és un punt de recuperació: és la intenció d'un punt de recuperació. Ho serà quan algú n'hagi llegit els blocs sencers i hagi comprovat que els checksums quadren. La documentació de Proxmox Backup Server ho diu sense adorns quan explica per què cal reverificar: «es recomana que reverifiquis totes les còpies almenys mensualment, encara que una verificació anterior fos correcta», perquè «els discos físics són susceptibles de fer-se malbé amb el temps, cosa que pot fer que una còpia antiga i funcional es corrompi, en un procés conegut com a bit rot o degradació de dades».

La mateixa documentació recomana una pauta que a la pràctica gairebé ningú no té muntada: una tasca de verificació freqüent per al que és nou i una altra setmanal o mensual que ho reverifiqui tot. Si el teu pla promet un RPO d'una hora i les teves còpies horàries no es verifiquen mai, la xifra que pots defensar no és una hora: és el temps que fa des de l'última còpia que saps llegir sencera. La diferència entre aquestes dues frases és un projecte de recuperació amb el consell d'administració mirant.

I hi ha un segon desplaçament, el que hi introdueix un atacant. La teva freqüència de còpia fixa l'RPO de l'incident tonto: un esborrat, una taula destrossada, un disc mort. La teva retenció fixa l'RPO de l'incident dolent, perquè la còpia que serveix no és l'última, és l'última anterior al fet que entressin. L'Active Adversary Report 2026 de Sophos, publicat el 24 de febrer, va situar la mediana de permanència de l'atacant a la xarxa en tres dies i va mesurar en 3,4 hores la mediana fins que arriben al servidor de Directori Actiu, un 70 % més ràpid que l'any anterior. Amb aquesta forma, una retenció curta i una detecció lenta es multipliquen: la còpia bona queda per darrere de la primera que mira tothom. És l'altra cara del que vam explicar amb les xifres de l'informe anual de ransomware de la mateixa casa quan vam explicar per què restaurar no és recuperar.

Els quatre rellotges de l'RTO

El primer és detectar: des que el servei comença a fallar fins que algú ho sap amb certesa. En una caiguda neta són minuts; en una corrupció lenta o en un xifratge per lots són hores, i de vegades ho descobreix un usuari abans que la monitorització. El segon és decidir, i és on hem vist anar-se'n més temps en les recuperacions que s'allarguen. El motiu gairebé mai no és tècnic: decidir vol dir que algú accepti, per escrit, que es perd la feina de les últimes hores, i aquesta signatura no la vol posar ningú a les tres de la matinada.

El tercer és restaurar, l'únic que apareix als plans i l'únic que es pot calcular amb una regla de tres abans que passi res; ho fem a l'apartat següent. I el quart és validar i reobrir: comprovar que el sistema restaurat fa el que ha de fer, reprocessar les cues que van quedar a mitges, reconciliar amb el que sí que va funcionar durant la caiguda i avisar la gent que ja pot tornar a treballar. És la part que converteix un servidor encès en un servei en marxa i, en un ERP amb integracions, pot durar més que el restore mateix.

No tenim cap xifra pública per posar al rellotge de la decisió, i no ens la inventarem. Sí que tenim l'observació repetida que és el que més s'estira i l'únic que es pot escurçar sense gastar un euro: s'escurça escrivint abans qui decideix, amb quin criteri i fins a quina hora s'espera. Segons la nostra experiència, un pla que anomena una persona i una hora límit retalla més RTO que doblar l'amplada de banda.

L'aritmètica que gairebé ningú fa

Agafa el volum que hauries de restaurar i l'enllaç per on ha de passar. El càlcul és de primària i desmunta més plans que qualsevol auditoria:

La conclusió incòmoda de la regla de tres és que un RTO no es decideix: es mesura. I es mesura un cop l'any amb un cronòmetre de debò, restaurant alguna cosa de debò. No s'hauria de signar cap xifra que no s'hagi cronometrat en un assaig, perquè el dia que falla no hi ha marge per descobrir que el paper deia quatre hores i la cabina dona 180 MB/s.

La xifra que falta a gairebé tots els plans

RTO i RPO descriuen un món binari: el servei hi és o no hi és. La realitat d'una recuperació és una bona estona d'estar a mitges, i aquella estona no té cap xifra assignada en cap pla que hàgim revisat. Què vol dir «funcionar a mitges» a la teva empresa? Es pot facturar a mà un dia? Es pot rebre mercaderia sense l'ERP i entrar-la després? El taller s'atura, o el taller continua i el que es detura és l'administració?

D'aquella conversa en surt el que de debò guia una recuperació: l'ordre. Què torna primer, què torna després i què pot esperar a demà. Si l'ordre no està escrit, el decideix qui crida més fort per telèfon, que gairebé mai no és qui té el sistema més crític. Escriure tres línies de prioritats costa una reunió i estalvia les dues pitjors hores de l'incident. És el mateix exercici que vam proposar després de la caiguda de Microsoft 365 del juliol, quan el que calia decidir no era com arreglar-ho, sinó com continuar treballant mentrestant.

Quan NO cal abaixar la xifra

Vendre continuïtat és fàcil: sempre es pot proposar una xifra més petita i cobrar-la. Ens sembla més honest dir quan no toca. Abaixar l'RPO de vint-i-quatre hores a quinze minuts multiplica el cost d'emmagatzematge i d'enllaç, i a moltes empreses no canvia res, perquè el que fa mal és l'RTO: tant se val perdre quinze minuts de dades si estaràs dos dies aturat. Aplicar l'RPO de l'ERP al servidor de fitxers és un altre clàssic car; i comprar rèplica síncrona per a un sistema que es fa servir de nou a sis és pagar una assegurança contra un risc que no tens.

Hi ha a més una part de la xifra que no és teva. Si el servei viu en un núvol públic, el teu RTO inclou el temps de recuperació d'un proveïdor a qui no pots trucar i amb qui no negocies prioritat: ho vam repassar amb el rellotge a la mà durant la caiguda d'AWS CloudFront del juliol. I si la teva resposta a tot això és «per això hi ha les còpies», convé mirar de tant en tant què passa quan l'esborrat arriba també a la còpia: és l'escenari que converteix un RPO d'una hora en un full de càlcul reconstruït a mà.

Les cinc línies que sí que escrivim

La pregunta que fem primer

Quan revisem un pla de continuïtat no comencem per la tecnologia. Comencem per aquesta: quan va ser l'última vegada que vau restaurar alguna cosa de debò, i quant va trigar? Si la resposta és una data i una xifra, la resta de la conversa és afinar. Si la resposta és «les còpies van bé, no donen errors», llavors no teniu un RTO: teniu una expectativa, i les expectatives no es restauren.

Fonts: recomanació de reverificar mensualment, cites literals sobre el bit rot i pauta de tasques de verificació — documentació de manteniment de Proxmox Backup Server; opció --live-restore i la seva descripció literal — manual de qmrestore de Proxmox VE; mediana de permanència de l'atacant en tres dies i arribada al Directori Actiu en hores — Sophos Active Adversary Report 2026 (febrer del 2026). Els càlculs de temps de restauració són aritmètica directa a partir de l'amplada de banda nominal i es presenten com a cota inferior, no com a estimació. Imatge de portada: «Departure board at Hackerbrücke S-Bahn station in München», Robert von Oliva, CC0, via Wikimedia Commons.