El backup era fora de perill. I feia 47 hores que era dins de la mateixa caiguda

Dues frases del mateix comunicat oficial, publicades amb un dia de diferència. La de diumenge a la tarda: «no existeix risc de pèrdua de dades. La informació i les dades emmagatzemades es troben segures». La de dilluns: «Mentre la incidència romangui activa, temporalment no és possible accedir als backups ni fer la migració dels serveis afectats cap a un altre node». Totes dues són certes. Juntes descriuen una situació que no apareix a gairebé cap pla de recuperació: les teves dades són perfectes i no hi pots fer absolutament res.

El rellotge, amb la font al davant

Parlem de la caiguda del node Nova de DonWeb, un proveïdor argentí d'allotjament i registre de dominis. El rellotge que fem servir aquí és el seu, el de la seva pàgina pública d'estat, perquè és l'única cronologia que no està reconstruïda per tercers. La seva primera entrada sobre l'incident està datada el diumenge 30 d'agost a les 09:23 (hora de l'Argentina, GMT-3) i ja entra a l'estat «Identificat». L'última que hem llegit abans d'escriure això és del dimarts 1 de setembre a les 08:43, i continua dient el mateix: incidència activa, sense resolució.

Entre aquestes dues marques hi ha 47 hores i 20 minuts. És una resta nostra i és deliberadament conservadora: compta des que el proveïdor obre la incidència al seu status, i no des que el primer client es va quedar sense servei, que va ser abans. La premsa local situa l'arrencada «el diumenge», sense hora; no hi ha marca horària d'inici en font primària, així que no ens la inventem. El número real és pitjor que 47, i 47 ja serveix per al que ve.

L'abast, en paraules del proveïdor, és «el 100% dels servidors del node NOVA», amb els Cloud Servers inaccessibles. La premsa local parla de centenars d'empreses: sistemes de facturació, bases de dades, botigues de comerç electrònic. El cent per cent és la xifra incòmoda aquí. Una degradació s'aguanta treballant pitjor; això és l'interruptor sencer.

Identificar la causa no és una fita de recuperació

La incidència s'obre diumenge a les 09:23 ja en estat «Identificat», amb aquest text: «El nostre equip tècnic ha aconseguit identificar la causa dels inconvenients i ja es troben treballant a restablir el servei amb la màxima brevetat possible». El comunicat ho repeteix a les 09:35. A les 11:14 apareix el primer avenç concret, «el reemplaçament d'un component de connexió». Dos dies després el servei continuava caigut.

Això és el que més vegades hem vist entendre malament des de l'altre costat del telèfon, gairebé sempre en boca de direcció i no dels tècnics. «Ja saben què és» es tradueix automàticament a «llavors falta poc», i sobre aquesta traducció es prenen decisions —esperar en comptes d'activar el pla B, no avisar els clients encara, no muntar el circuit manual—. Són dues feines diferents, i la segona pot durar un ordre de magnitud més que la primera. En una infraestructura d'emmagatzematge compartit, saber quina peça va fallar et diu molt poc sobre quant triga a tornar a ser consistent el que hi ha a sobre.

Les dues frases s'han de llegir juntes

«No existeix risc de pèrdua de dades» és, tècnicament, una boníssima notícia, i cal reconèixer-ho: el proveïdor la va publicar aviat i la va sostenir. Significa que l'RPO —quanta informació perds— és zero o gairebé. És el número que més es mira quan es compra emmagatzematge i el que surt a totes les fitxes.

La segona frase diu que l'RTO —quant trigues a tornar a funcionar— no té número. I no en té per un motiu que convé mirar de cara: no el pots accelerar tu. La via de sortida que qualsevol pla raonable contempla —«si això s'allarga, restauro la còpia en un altre lloc i continuo»— passava pel mateix panell que estava caigut. La còpia existia, era íntegra, i era tan inabastable com el servidor original. Això és diferent del que explicàvem fa unes hores arran de Microsoft 365: allà el problema era que sis serveis que et pensaves independents penjaven de la mateixa peça; aquí només hi ha un servei, i el que falla és la sortida.

És la mateixa família d'error que ja hem explicat en una altra versió domèstica: el servidor de còpies ficat al mateix domini que protegeix. L'escala és una altra i l'error és el mateix. Una còpia hereta la disponibilitat del lloc des del qual es restaura, no la seva pròpia. Si l'únic camí fins a ella passa pel panell del proveïdor, la teva còpia té exactament el mateix temps de recuperació que el proveïdor, i aquest temps el decideix ell.

La xifra que falta: a quina hora deixes d'esperar

Quan vam escriure sobre RTO i RPO insistíem que l'estona llarga d'estar a mitges no té cap xifra assignada a cap pla. Aquesta caiguda hi afegeix una xifra que tampoc no en té, i que és la que de debò es troba a faltar a les quaranta-set hores: en quin moment deixes d'esperar el proveïdor?

Sense aquella hora escrita per endavant, no es decideix mai. La raó és psicològica i força humana: cada actualització de l'status sembla la penúltima, i arrencar en un altre lloc significa donar per perduda la feina de les hores anteriors. Així que s'espera una hora més. I una altra. És exactament el mateix mecanisme pel qual ningú surt d'una cua: fa tant de temps que ets allà que marxar ara sembla un malbaratament. A les quaranta-set hores, la decisió d'esperar no es va prendre mai; simplement no se'n va prendre cap.

La xifra és diferent a cada empresa i surt d'una conversa de negoci, no tècnica: quantes hores d'aturada aguanta l'operació abans que el dany deixi de ser recuperable —clients que marxen, comandes que no entren, una obligació contractual que s'incompleix—. Poden ser quatre hores o poden ser tres dies. L'important és que estigui escrita, que la signi algú amb autoritat per gastar diners, i que vagi acompanyada de l'única cosa que la fa executable: una còpia que no depengui del proveïdor caigut, i algú que sàpiga aixecar-la sense improvisar.

El que no farem amb això

No direm què va fallar, perquè el proveïdor no ho ha publicat i qualsevol hipòtesi nostra seria inventada. L'única cosa tècnica que hi ha al status és «el reemplaçament d'un component de connexió», que no permet deduir res seriós. Tampoc no farem servir això per donar a entendre que a nosaltres no ens passaria: qualsevol que operi ferro prou temps acaba tenint un diumenge així, i qui digui el contrari o fa poc temps que hi és o no ho explica. Publicar actualitzacions cada poques hores durant dos dies, donant la cara, és més del que fan molts.

El que sí que és criticable, i va per a tothom —nosaltres inclosos—, és vendre la còpia i la restauració dins del mateix perímetre que el servei sense dir en veu alta el que això implica. Ningú no enganya ningú; és l'arquitectura per defecte de gairebé tot el cloud de proximitat, i resulta còmoda per a totes dues parts. Però el client mereix saber que en el pitjor escenari aquella còpia no és una sortida, i aquesta frase no apareix a cap oferta. Apareix en un comunicat d'incidència, un diumenge, quan ja no serveix de res.

Quatre preguntes per fer-se aquesta setmana

• Des d'on es restaura la teva còpia? Si la resposta és «des del panell del meu proveïdor», la teva còpia i el teu servidor comparteixen destí. Que existeixi una segona còpia fora d'aquell perímetre no és paranoia: és la diferència entre tenir una sortida i no tenir-la.
• Quantes hores d'aturada aguantes abans d'activar el pla B? Escriu-ho amb xifres. «Poc» i «al més aviat possible» no valen.
• Has arrencat alguna vegada aquesta còpia en un altre lloc? Si no ho has fet, no saps quant triga ni si funciona. Un assaig cronometrat a l'any converteix una xifra inventada en una xifra mesurada.
• Pots treballar a mà dos dies? Facturar, rebre mercaderia, atendre el client. Si la resposta és que no, el pla de recuperació és també un procediment en paper, i aquell costa una tarda escriure'l.

La tercera és la que més es salta i l'única que dóna un número real. Ja ho vam escriure arran de l'esborrat del registre de la propietat romanès, on la paraula que importava era «immutable»; aquí la paraula que importa és «assolible». Són requisits diferents i cal demanar-los per separat, perquè una còpia pot complir-ne un i fallar l'altre sense que ningú se n'assabenti fins al dia que fa falta.

Quan això no va amb tu

Si el que tens allotjat és un web corporatiu que no ven, dos dies caigut és una molèstia i poca cosa més: no muntis arquitectura per a això. Tampoc no cal duplicar res si pots continuar facturant en paper una setmana sense despentinar-te. La conversa canvia quan per allà passen les comandes, quan l'ERP és el lloc on viu l'inventari o quan tens un compromís signat de respondre en un termini. Aleshores el que compres no és més disponibilitat —això és caríssim i gairebé mai és la resposta—, sinó una sortida que no depengui de qui ha caigut: una còpia fora d'aquell perímetre, en un altre proveïdor o en el teu propi ferro, i un procediment de recuperació que algú hagi executat alguna vegada amb un cronòmetre al davant.

I una observació que es repeteix i que és la raó que hi insistim: això els passa igual als grans. Al juliol li va tocar a un gegant, i ja vam escriure llavors sobre què aprendre d'una caiguda de CloudFront. El que decideix com acabes és si el teu pla tenia prevista una porta cap enfora. Quan el ferro és teu o és en un centre de dades que tries, aquesta porta és més fàcil de dibuixar, encara que tampoc no apareix sola: també cal dissenyar-la.

Fonts (verificades l'1 de setembre de 2026): totes les cites literals del proveïdor provenen de la pàgina pública d'estat de DonWeb, i cadascuna és a l'entrada que s'indica (hores GMT-3): «El nostre equip tècnic ha aconseguit identificar la causa dels inconvenients i ja es troben treballant a restablir el servei amb la màxima brevetat possible» ja és a l'entrada d'obertura del 30 d'agost a les 09:23, marcada «Identificat», i es repeteix a les 09:35; «es va efectuar el reemplaçament d'un component de connexió» apareix per primera vegada a les 11:14 i es repeteix a les 16:49; «no existeix risc de pèrdua de dades. La informació i les dades emmagatzemades es troben segures» és de les 20:04 del 30 d'agost; «Mentre la incidència romangui activa, temporalment no és possible accedir als backups ni fer la migració dels serveis afectats cap a un altre node» és del 31 d'agost a les 14:09; i «el 100% dels servidors del node NOVA» és a l'entrada del 31 a les 08:48. Les altres actualitzacions consultades són les del 31 (06:27) i les de l'1 de setembre (08:21 i 08:43); en aquella darrera hora, la més recent publicada, la incidència continuava activa. L'abast («el 100% dels servidors del node NOVA»), l'absència de temps estimat de resolució i l'impacte en centenars d'empreses — La Capital, 1-set.-2026 i Punto Biz. Aritmètica pròpia: les 47 hores i 20 minuts són la resta entre la primera i l'última entrada de l'status citades, no una xifra publicada; l'incident va començar abans de la primera entrada i no hem pogut fixar aquell moment en font primària, així que el número real és més gran. Criteri propi, no fet reportat: la lectura conjunta de les dues frases com a RPO zero amb RTO sense xifra, l'advertència sobre confondre «causa identificada» amb «falta poc», la proposta d'escriure l'hora en què es deixa d'esperar i les quatre preguntes. La causa tècnica de l'incident no ha estat publicada pel proveïdor i aquest post no la dedueix.