El incendio declarado el 7 de mayo en el centro de datos de NorthC en Almere, Países Bajos, ha dejado una de esas lecciones que el sector cloud suele explicar en presentaciones, pero que solo se entienden de verdad cuando ocurre una crisis. La infraestructura digital también arde, se evacúa, queda inaccesible y puede dejar sin servicio a empresas, universidades, administraciones y profesionales que hasta ese momento daban por hecha la disponibilidad de sus sistemas.

En ese contexto, el testimonio público de Jeroen Derks, especialista en PHP y Laravel, ha puesto nombre propio a una parte menos visible de la respuesta técnica. Tras el incendio, Derks explicó en LinkedIn que su servidor gestionado por Stackscale volvió a estar operativo en otra ubicación “en tiempo récord”. Mientras él estaba preocupado por la pérdida de acceso al correo, el equipo de ingeniería y soporte trabajaba en segundo plano para recuperar el servicio.

Su mensaje, con una frase tan sencilla como potente, “Turns out, Stackscale is fireproof”, resume algo que cualquier proveedor de infraestructura debería poder demostrar: la continuidad de negocio no se mide en folletos comerciales, sino en la capacidad de responder cuando falla una ubicación física.

Un incendio que recordó la parte física del cloud

El fuego se declaró en la mañana del jueves 7 de mayo de 2026 en las instalaciones de NorthC Datacenters en Rondebeltweg, dentro del polígono industrial Sallandsekant de Almere Stad. NorthC informó de que el incendio comenzó alrededor de las 08:45 y que todas las personas presentes fueron evacuadas a tiempo. Las autoridades activaron un NL-Alert para la población cercana por la presencia de humo y la situación llegó a escalarse inicialmente a GRIP 1, un nivel de coordinación de emergencias utilizado en Países Bajos.

La incidencia no fue menor. Diversos medios neerlandeses e internacionales recogieron problemas en servicios digitales vinculados a organizaciones públicas, educativas y empresariales. Utrecht University informó de impactos en su red, aplicaciones y sitios web, con efectos sobre el trabajo diario, la investigación y la docencia. Otros medios señalaron también afectaciones en servicios como transporte público, clínicas y organismos administrativos.

El episodio expuso una realidad incómoda: el cloud, el hosting, la conectividad y las plataformas digitales dependen de edificios concretos, sistemas eléctricos concretos, salas técnicas concretas y equipos que, por muy redundantes que parezcan, pueden quedar inaccesibles durante horas o días. La nube no flota en el aire. Vive en centros de datos con riesgos físicos, desde incendios hasta fallos eléctricos, inundaciones, cortes de fibra o problemas de refrigeración.

En el caso de Almere, Techzine informó de que la recuperación completa del centro podía llevar hasta 72 horas, mientras NorthC trabajaba en inspecciones, control de daños y comunicación con clientes. Para cualquier empresa afectada, esa ventana puede ser asumible si existe un plan de recuperación probado; puede ser crítica si todo depende de una única ubicación.

Recuperar un servidor no es solo encender otra máquina

El caso compartido por Jeroen Derks resulta relevante porque baja el debate a tierra. La continuidad de negocio no consiste únicamente en tener una copia de seguridad. Hace falta saber dónde está, cuándo se generó, si es consistente, cuánto tarda en restaurarse, qué dependencias tiene el servicio, qué DNS hay que cambiar, qué redes deben levantarse, qué datos pueden perderse y qué clientes hay que informar.

Recuperar un servidor en otra ubicación tras un incidente de centro de datos exige coordinación técnica y operativa. Hay que evaluar el estado del servicio afectado, localizar backups o réplicas, aprovisionar capacidad alternativa, reconstruir máquinas, validar sistemas, comprobar conectividad, revisar correo, bases de datos, certificados, firewall, almacenamiento y monitorización. En ocasiones, además, hay que trabajar sin acceso inmediato al edificio original.

Ahí es donde se diferencia un proveedor que solo aloja infraestructura de uno que opera con mentalidad de continuidad. La respuesta no depende únicamente de hardware disponible. Depende de procesos, personas, documentación, automatización y experiencia acumulada. También depende de tener presencia en varias localizaciones y capacidad para mover cargas con rapidez cuando una instalación queda comprometida.

El reconocimiento público de Derks tiene valor porque no procede de una nota corporativa. Es la reacción de un cliente que pasó por una interrupción real y vio cómo su servicio volvía a estar operativo en otra ubicación. En situaciones así, la confianza no se construye con promesas, sino con ejecución.

La resiliencia debe diseñarse antes de la crisis

El incendio de NorthC en Almere ofrece una enseñanza clara para cualquier organización que dependa de infraestructura digital: la resiliencia no se improvisa durante el incidente. Se diseña antes. Y se prueba antes.

Muchas empresas creen que tienen continuidad porque hacen backups. Es un primer paso, pero no basta. Un backup que nunca se ha restaurado es una esperanza, no una garantía. Un plan de recuperación que solo existe en un documento sin responsables, tiempos y pruebas periódicas puede fallar cuando más falta hace. Una arquitectura crítica concentrada en un único centro de datos convierte cualquier incidente físico en un riesgo de negocio.

La estrategia correcta depende del tipo de carga. No todos los servicios necesitan alta disponibilidad activa-activa entre varios centros. No todos justifican replicación síncrona, clustering geográfico o arquitecturas complejas. Pero todos deberían tener claro su RPO y RTO: cuántos datos se pueden perder y cuánto tiempo máximo puede estar parado el servicio.

Un correo profesional, una tienda online, una plataforma SaaS, un ERP, una base de datos de clientes o una web institucional no tienen el mismo nivel de criticidad. Pero en todos los casos conviene responder a preguntas muy concretas: dónde están los datos, qué ocurre si el data center principal queda inaccesible, quién ejecuta la recuperación, cuánto tarda, cómo se comunica a los usuarios y cuándo se probó por última vez.

El caso de Almere también recuerda la importancia de diversificar ubicación. En Europa, muchas empresas han adoptado cloud o colocation pensando en latencia, precio o certificaciones, pero no siempre han diseñado una arquitectura que soporte la caída física de una instalación. La disponibilidad de varios centros de datos, redes redundantes y copias separadas geográficamente no es un lujo si el servicio sostiene actividad crítica.

Lecciones para proveedores y clientes

Para los proveedores de infraestructura, incidentes como el de Almere obligan a revisar planes de emergencia, comunicación, coordinación con bomberos, acceso a instalaciones, gestión de clientes, priorización de servicios y capacidad de recuperación cruzada. La transparencia también cuenta. En una crisis, los clientes necesitan información frecuente, clara y útil, incluso cuando todavía no hay todas las respuestas.

Para los clientes, la lección es igual de exigente. No se puede delegar toda la continuidad en el proveedor sin entender la propia arquitectura. Hay que contratar el nivel de resiliencia adecuado, revisar backups, pedir pruebas de restauración, documentar dependencias y evitar que el coste sea el único criterio. La alta disponibilidad no aparece por defecto en todos los servicios. Se diseña, se contrata y se mantiene.

La experiencia de Stackscale con el servidor de Jeroen Derks muestra la parte positiva de una crisis: cuando hay equipo, procedimientos y varias ubicaciones, es posible recuperar cargas afectadas y reducir el impacto para el cliente. También muestra el valor de los equipos humanos detrás del cloud. En su publicación, Derks agradeció el trabajo de ingenieros y soporte, a quienes atribuyó una respuesta rápida en condiciones difíciles.

Ese reconocimiento es importante porque la continuidad de negocio suele verse como una capa técnica fría. En realidad, en un incidente grave, la diferencia la marcan personas capaces de tomar decisiones, coordinarse y actuar con rapidez. La automatización ayuda, pero alguien tiene que conocer la plataforma, priorizar, comunicar y verificar que el servicio vuelve a funcionar.

El incendio de Almere no será el último incidente físico que afecte a un centro de datos europeo. La dependencia de infraestructura digital seguirá creciendo, y con ella la exposición a fallos que pueden parecer improbables hasta que ocurren. La pregunta para empresas y proveedores no es si algún día habrá problemas, sino si la arquitectura y los equipos estarán preparados cuando lleguen.

Preguntas frecuentes

¿Qué ocurrió en el centro de datos de NorthC en Almere?
El 7 de mayo de 2026 se declaró un incendio en las instalaciones de NorthC Datacenters en Rondebeltweg, Almere. El edificio fue evacuado y las autoridades activaron avisos de emergencia por el humo.

¿Qué relación tiene Stackscale con este incidente?
Un cliente de Stackscale, Jeroen Derks, explicó públicamente que su servidor volvió a estar operativo en otra ubicación tras el incendio, y agradeció la respuesta del equipo técnico y de soporte.

¿Qué diferencia hay entre backup y continuidad de negocio?
El backup es una copia de datos. La continuidad de negocio incluye también restauración, infraestructura alternativa, redes, tiempos de recuperación, comunicación y pruebas periódicas.

¿Qué debería revisar una empresa tras un incidente como este?
Debe revisar sus RPO y RTO, ubicación de backups, pruebas de restauración, dependencia de un único centro de datos, plan de comunicación y nivel real de alta disponibilidad contratado.