El backup estaba a salvo. Y llevaba 47 horas dentro de la misma caída

Dos frases del mismo parte oficial, publicadas con un día de diferencia. La del domingo por la tarde: «no existe riesgo de pérdida de datos. La información y los datos almacenados se encuentran seguros». La del lunes: «Mientras la incidencia permanezca activa, temporalmente no es posible acceder a los backups ni realizar la migración de los servicios afectados hacia otro nodo». Las dos son ciertas. Juntas describen una situación que no aparece en casi ningún plan de recuperación: tus datos están perfectos y no puedes hacer absolutamente nada con ellos.

El reloj, con la fuente delante

Hablamos de la caída del nodo Nova de DonWeb, un proveedor argentino de hosting y registro de dominios. El reloj que usamos aquí es el suyo, el de su página pública de estado, porque es la única cronología que no está reconstruida por terceros. Su primera entrada sobre el incidente está fechada el domingo 30 de agosto a las 09:23 (hora de Argentina, GMT-3) y ya entra en el estado «Identificado». La última que hemos leído antes de escribir esto es del martes 1 de septiembre a las 08:43, y sigue diciendo lo mismo: incidencia activa, sin resolución.

Entre esas dos marcas hay 47 horas y 20 minutos. Es una resta nuestra y es deliberadamente conservadora: cuenta desde que el proveedor abre la incidencia en su status, y no desde que el primer cliente se quedó sin servicio, que fue antes. La prensa local sitúa el arranque «el domingo», sin hora; no hay marca horaria de inicio en fuente primaria, así que no la inventamos. El número real es peor que 47, y 47 ya sirve para lo que viene.

El alcance, en palabras del proveedor, es «el 100% de los servidores del nodo NOVA», con los Cloud Servers inaccesibles. La prensa local habla de cientos de empresas: sistemas de facturación, bases de datos, tiendas de comercio electrónico. El cien por cien es la cifra incómoda ahí. Una degradación se aguanta trabajando peor; esto es el interruptor entero.

Identificar la causa no es un hito de recuperación

La incidencia se abre el domingo a las 09:23 ya en estado «Identificado», con este texto: «Nuestro equipo técnico ha logrado identificar la causa de los inconvenientes y ya se encuentran trabajando en restablecer el servicio a la mayor brevedad posible». El parte lo repite a las 09:35. A las 11:14 aparece el primer avance concreto, «el reemplazo de un componente de conexión». Dos días después el servicio seguía caído.

Esto es lo que más veces hemos visto entender mal desde el otro lado del teléfono, casi siempre en boca de dirección y no de los técnicos. «Ya saben lo que es» se traduce automáticamente a «entonces falta poco», y sobre esa traducción se toman decisiones —esperar en vez de activar el plan B, no avisar a los clientes todavía, no montar el circuito manual—. Son dos trabajos distintos, y el segundo puede durar un orden de magnitud más que el primero. En una infraestructura de almacenamiento compartido, saber qué pieza falló te dice muy poco sobre cuánto tarda en volver a ser consistente lo que hay encima.

Las dos frases hay que leerlas juntas

«No existe riesgo de pérdida de datos» es, técnicamente, una buenísima noticia, y hay que reconocerlo: el proveedor la publicó pronto y la sostuvo. Significa que el RPO —cuánta información pierdes— es cero o casi. Es el número que más se mira cuando se compra almacenamiento y el que sale en todas las fichas.

La segunda frase dice que el RTO —cuánto tardas en volver a funcionar— no tiene número. Y no lo tiene por un motivo que conviene mirar de frente: no puedes acelerarlo tú. La vía de escape que cualquier plan razonable contempla —«si esto se alarga, restauro la copia en otro sitio y sigo»— pasaba por el mismo panel que estaba caído. La copia existía, estaba íntegra, y era tan inalcanzable como el servidor original. Esto es distinto de lo que contamos hace unas horas a cuenta de Microsoft 365: allí el problema era que seis servicios que creías independientes colgaban de la misma pieza; aquí solo hay un servicio, y lo que falla es la salida.

Es la misma familia de error que ya hemos contado en otra versión doméstica: el servidor de copias metido en el mismo dominio que protege. La escala es otra y el error es el mismo. Una copia hereda la disponibilidad del sitio desde el que se restaura, no la suya propia. Si el único camino hasta ella pasa por el panel del proveedor, tu copia tiene exactamente el mismo tiempo de recuperación que el proveedor, y ese tiempo lo decide él.

La cifra que falta: a qué hora dejas de esperar

Cuando escribimos sobre RTO y RPO insistimos en que el rato largo de estar a medias no tiene número asignado en ningún plan. Esta caída añade una cifra que tampoco lo tiene, y que es la que de verdad se echa en falta a las cuarenta y siete horas: ¿en qué momento dejas de esperar al proveedor?

Sin esa hora escrita de antemano, no se decide nunca. La razón es psicológica y bastante humana: cada actualización del status parece la penúltima, y arrancar en otro sitio significa dar por perdido el trabajo de las horas anteriores. Así que se espera una hora más. Y otra. Es exactamente el mismo mecanismo por el que nadie sale de una cola: llevas tanto tiempo que irte ahora parece un desperdicio. A las cuarenta y siete horas, la decisión de esperar nunca se tomó; simplemente no se tomó ninguna.

La cifra es distinta en cada empresa y sale de una conversación de negocio, no técnica: cuántas horas de parada aguanta la operación antes de que el daño deje de ser recuperable —clientes que se van, pedidos que no entran, una obligación contractual que se incumple—. Puede ser cuatro horas o pueden ser tres días. Lo importante es que esté escrita, que la firme alguien con autoridad para gastar dinero, y que vaya acompañada de lo único que la hace ejecutable: una copia que no dependa del proveedor caído, y alguien que sepa levantarla sin improvisar.

Lo que no vamos a hacer con esto

No vamos a decir qué falló, porque el proveedor no lo ha publicado y cualquier hipótesis nuestra sería inventada. Lo único técnico que hay en el status es «el reemplazo de un componente de conexión», que no permite deducir nada serio. Tampoco vamos a usar esto para dar a entender que a nosotros no nos pasaría: cualquiera que opere hierro suficiente tiempo acaba teniendo un domingo así, y quien diga lo contrario o lleva poco tiempo o no lo cuenta. Publicar actualizaciones cada pocas horas durante dos días, con la cara, es más de lo que hacen muchos.

Lo que sí es criticable, y va para todos —nosotros incluidos—, es vender la copia y la restauración dentro del mismo perímetro que el servicio sin decir en voz alta lo que eso implica. Nadie está engañando a nadie; es la arquitectura por defecto de casi todo el cloud de proximidad, y resulta cómoda para las dos partes. Pero el cliente merece saber que en el peor escenario esa copia no es una salida, y esa frase no aparece en ninguna oferta. Aparece en un parte de incidencia, un domingo, cuando ya no sirve de nada.

Cuatro preguntas para hacerse esta semana

• ¿Desde dónde se restaura tu copia? Si la respuesta es «desde el panel de mi proveedor», tu copia y tu servidor comparten destino. Que exista una segunda copia fuera de ese perímetro no es paranoia: es la diferencia entre tener una salida y no tenerla.
• ¿Cuántas horas de parada aguantas antes de activar el plan B? Escríbelo con dígitos. «Poco» y «lo antes posible» no valen.
• ¿Has arrancado alguna vez esa copia en otro sitio? Si no lo has hecho, no sabes cuánto tarda ni si funciona. Un ensayo cronometrado al año convierte una cifra inventada en una cifra medida.
• ¿Puedes trabajar a mano dos días? Facturar, recibir mercancía, atender al cliente. Si la respuesta es que no, el plan de recuperación es también un procedimiento en papel, y ese cuesta una tarde escribirlo.

La tercera es la que más se salta y la única que da un número real. Ya lo escribimos a cuenta del borrado del registro de la propiedad rumano, donde la palabra que importaba era «inmutable»; aquí la palabra que importa es «alcanzable». Son requisitos distintos y hay que pedirlos por separado, porque una copia puede cumplir uno y fallar el otro sin que nadie se entere hasta el día que hace falta.

Cuándo esto no va contigo

Si lo que tienes alojado es una web corporativa que no vende, dos días caída es un fastidio y poco más: no montes arquitectura para eso. Tampoco hace falta duplicar nada si puedes seguir facturando en papel una semana sin despeinarte. La conversación cambia cuando por ahí pasan los pedidos, cuando el ERP es el sitio donde vive el inventario o cuando tienes un compromiso firmado de responder en un plazo. Entonces lo que compras no es más disponibilidad —eso es carísimo y casi nunca es la respuesta—, sino una salida que no dependa de quien se ha caído: una copia fuera de ese perímetro, en otro proveedor o en tu propio hierro, y un procedimiento de recuperación que alguien haya ejecutado alguna vez con un cronómetro delante.

Y una observación que se repite y que es la razón de que insistamos: esto le pasa igual a los grandes. En julio le tocó a un gigante, y ya escribimos entonces sobre qué aprender de una caída de CloudFront. Lo que decide cómo acabas es si tu plan tenía prevista una puerta hacia afuera. Cuando el hierro es tuyo o está en un centro de datos que eliges, esa puerta es más fácil de dibujar, aunque tampoco aparece sola: también hay que diseñarla.

Fuentes (verificadas el 1 de septiembre de 2026): todas las citas literales del proveedor proceden de la página pública de estado de DonWeb, y cada una está en la entrada que se indica (horas GMT-3): «Nuestro equipo técnico ha logrado identificar la causa de los inconvenientes y ya se encuentran trabajando en restablecer el servicio a la mayor brevedad posible» está ya en la entrada de apertura del 30 de agosto a las 09:23, marcada «Identificado», y se repite a las 09:35; «se efectuó el reemplazo de un componente de conexión» aparece por primera vez a las 11:14 y se repite a las 16:49; «no existe riesgo de pérdida de datos. La información y los datos almacenados se encuentran seguros» es de las 20:04 del 30 de agosto; «Mientras la incidencia permanezca activa, temporalmente no es posible acceder a los backups ni realizar la migración de los servicios afectados hacia otro nodo» es del 31 de agosto a las 14:09; y «el 100% de los servidores del nodo NOVA» está en la entrada del 31 a las 08:48. Las demás actualizaciones consultadas son las del 31 (06:27) y las del 1 de septiembre (08:21 y 08:43); a esa última hora, la más reciente publicada, la incidencia seguía activa. El alcance («el 100% de los servidores del nodo NOVA»), la ausencia de tiempo estimado de resolución y el impacto en cientos de empresas — La Capital, 1-sep.-2026 y Punto Biz. Aritmética propia: las 47 horas y 20 minutos son la resta entre la primera y la última entrada del status citadas, no una cifra publicada; el incidente empezó antes de la primera entrada y no hemos podido fijar ese momento en fuente primaria, así que el número real es mayor. Criterio propio, no hecho reportado: la lectura conjunta de las dos frases como RPO cero con RTO sin número, la advertencia sobre confundir «causa identificada» con «falta poco», la propuesta de escribir la hora en que se deja de esperar y las cuatro preguntas. La causa técnica del incidente no ha sido publicada por el proveedor y este post no la deduce.