Danube Data: 8 horas caído y nadie se enteró

El postmortem más honesto que leerás este año

El 17 de agosto de 2026, a las 00:32 UTC, uno de los servidores de almacenamiento de Danube Data, un proveedor cloud rumano con object storage compatible con S3, registro de contenedores y despliegues serverless, perdió energía eléctrica. No se reinició. No hizo crash. Simplemente se quedó apagado. Un ingeniero lo descubrió a las 08:18 UTC y pulsó el botón de encendido a las 08:22. Ocho horas y quince minutos sin que nadie en el equipo se enterase de que toda una parte del servicio estaba caída, a pesar de que su página de estado público había detectado el fallo tres minutos después del evento, a las 00:35.

Es un postmortem notable por dos razones: la empresa admite que tuvo la información correcta en el momento correcto y aun así no actuó, y publica el detalle técnico sin maquillar. Para un founder hispanohablante que delega infraestructura, el caso vale más que cualquier guía teórica: muestra cómo una decisión arquitectónica que parecía correcta en papel convirtió un fallo de hardware en una caída total del servicio.

Por qué una sola máquina tumbó todo el object storage

Danube Data almacena los objetos de sus clientes con código de borrado 4+2: cada objeto se divide en seis fragmentos, cuatro de datos y dos de paridad, y cualquier combinación de cuatro sirve para reconstruir el archivo. Sobre el papel, el esquema aguanta la pérdida de dos fragmentos por objeto.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El problema estaba en dónde podían vivir esos seis fragmentos. La compañía operaba con cuatro máquinas de almacenamiento y permitía que los fragmentos se repartiesen entre discos, pero no entre servidores. Cada servidor alojaba muchos discos. Cuando uno cayó, se llevó consigo una media de 1,5 de los 6 fragmentos de cada objeto, y para una proporción significativa de objetos se llevó 2 o 3.

Perder 1 fragmento de 6: el objeto se sigue leyendo.
Perder 2: por debajo del mínimo seguro, las lecturas se detienen.
Perder 3: por debajo del umbral para reconstruir, queda ilegible hasta que vuelva el hardware.

Ese es el motivo por el que la caída fue total y no degradada. Y por qué no se pudo autorecuperar mientras la máquina estuvo apagada. Los datos no se perdieron en ningún momento: estaban simplemente inalcanzables.

La empresa reconoce que el arreglo evidente, forzar que los seis fragmentos vivan en seis servidores distintos, no se pudo aplicar el día del incidente. Un esquema 4+2 necesita seis dominios de fallo y solo tenían cuatro máquinas. No era un cambio de configuración: era una decisión de capacidad que se había ido aplazando en silencio detrás de un valor por defecto.

El componente pequeño que rompió el servicio grande

Hay un segundo problema, más pequeño y más revelador. Junto a los datos, el object storage guarda unos pocos registros internos de bookkeeping, almacenados como dos copias en lugar de con código de borrado. Esas dos copias también podían coincidir en la misma máquina. Para un puñado de registros, incluido el que las gateways leen al arrancar, las dos copias estaban en el servidor caído.

Unos pocos kilobytes de configuración, con menos cuidado por ser pequeños, son la diferencia entre lecturas lentas y un "connection refused" total. La propia empresa lo dice con claridad: cientos de terabytes de datos de clientes se comportaron exactamente como fueron diseñados; unos pocos kilobytes de metadatos desorganizados son los que tiraron el servicio. Si corres algo parecido, audita primero tus pools más pequeños, porque suelen ser el talón de Aquiles.

El casi accidente que no se produjo

Cuando una máquina de almacenamiento desaparece, el cluster empieza a reconstruir las copias faltantes en las máquinas restantes. En este caso eso significaba mover unos 115 TiB sobre tres servidores con 140 TiB libres entre los tres. Trayectoria: cerca del 97% de ocupación en aproximadamente cinco días, umbral en el que el cluster deja de aceptar escrituras y convierte un outage de lectura en uno total.

El vector de fallo era el equivocado y el rebuild no estaba suprimido. La cifra fría que deja el informe: con un cluster de cuatro nodos al 71% de utilización, no se puede absorber la pérdida permanente de uno. Para sobrevivirlo necesitas bastante más espacio libre, o bastantes más máquinas. Es la clase de margen que no se nota hasta el día que se necesita.

Lo que arreglaron el mismo día (y lo que todavía no)

Danube Data publicó dos cambios concretos enviados a producción horas después de la recuperación.

1. On-call ahora recibe una llamada de teléfono. Antes del incidente, una alerta de plataforma llegaba por email a una sola persona. A las 00:35 de un domingo, un email no es una alarma. Ahora, cuando aparece un incidente en la página de estado, el sistema dispara una llamada de voz al teléfono de guardia, con un SMS adjunto. Tres detalles de diseño importan: el sistema de llamadas vive fuera del sistema de notificaciones normal (que aplica digestos, rate limits y periodos de silencio, todo correcto para clientes, todo incorrecto para un pager); el mensaje hablado va dentro de la propia llamada y no se recupera de una página servida por la infraestructura caída; y el sistema ignora los incidentes escritos a posteriori, incluyendo los que aparecen al rellenar este postmortem, para que publicar un informe no haga sonar un teléfono a las 3am.

2. Un watchdog capaz de encender una máquina muerta. Los servidores exponen una API de gestión que reporta el estado de energía real y puede pulsar el botón de encendido. Las ocho horas de outage fueron, al final, un botón que nadie estaba despierto para pulsar. Un watchdog sondea cada servidor cada minuto y puede pulsar el botón sin intervención humana. Casi todo el trabajo fue asegurar que no actúe cuando no debe: corre fuera de la infraestructura que vigila, necesita que coincidan cuatro señales independientes (red, salud del cluster, estado de energía y salud de workloads), trata dos o más máquinas fallando a la vez como un fallo de monitorización o red, no como hardware simultáneo, y se niega a actuar si no puede confirmar el estado de energía con el hardware. La lógica de decisión es una función pura con tests cubriendo cada uno de esos rieles. La propia empresa cuenta que al día siguiente el watchdog ya hizo una falsa alarma por un paquete de red perdido: lo arreglaron y prefieren haberlo detectado así.

La lista de lo que no está arreglado es igual de útil: el layout de almacenamiento sigue permitiendo que los seis fragmentos caigan juntos, la capacidad sigue demasiado justa para absorber la pérdida de un nodo, el on-call sigue siendo un único número de teléfono, y la causa raíz del corte de energía sigue sin cerrarse porque la empresa eligió esperar a una segunda ocurrencia antes de pagar seis horas de downtime en un nodo para hacer la inspección hardware.

Qué significa esto para tu startup

El episodio no es solo una curiosidad de un proveedor europeo. En el primer semestre de 2026, según el ranking de CRN, Microsoft, AWS, Google, Verizon y Cloudflare protagonizaron los mayores outages del año, incluyendo un evento térmico en la región US-East-1 de AWS que mantuvo Coinbase caído unas siete horas, siete horas de indisponibilidad de Google Gemini el 10 de junio, y dos caídas de Microsoft Copilot en el mismo mes. Splunk, a través de CRN, estima que cada minuto de downtime cuesta USD 15.000 y que las empresas del Global 2000 pierden de media USD 300 millones al año por paradas no planificadas. Un único incidente grave está asociado a una caída media del 3,4% en el precio de la acción.

Para un founder que monta producto sobre infra de terceros, este postmortem deja tres acciones concretas.

Trata cada cambio de variable de entorno como un despliegue de imagen. Como explica Danube Data, el motor serverless resuelve el tag de la imagen a digest en cada nueva revisión, así que tocar solo una env var también contacta el registry. Si dependes de un registry de un proveedor único, ten un plan documentado para reintentar manualmente los despliegues que fallen durante ventanas de indisponibilidad.
Construye redundancia con forma, no con número. "Seis copias" y "seis copias que pueden vivir en la misma máquina" son garantías distintas. Si tu proveedor no separa las copias por dominios de fallo independientes (servidor, rack, zona, región), tu redundancia es decorativa. Pídelo por escrito.
Verifica recuperación donde están tus clientes. En medio del incidente, el equipo de Danube Data creyó brevemente que el registry había vuelto porque respondía autenticación, una capa que no toca almacenamiento. Si te anuncian recuperación, valida con una petición que lea datos reales antes de reintentar pipelines de cliente.

Y una lección cultural que cualquier equipo técnico debería copiar: detección y notificación son sistemas distintos, y solo habían construido uno. Tener un status page correcto, público y rápido durante ocho horas mientras todo el mundo duerme no es监控, es un registro. Un pager que no despierta a alguien no es una alarma.