Brand bij datacenter Almere geeft IT-problemen bij Universiteit Utrecht en KVK

De zeer grote brand bij het datacenter van NorthC in Almere levert problemen op bij diverse bedrijven en organisaties. De Universiteit Utrecht en de Kamer van Koophandel hebben IT-problemen door de brand en het kantoornetwerk van de gemeente Amsterdam zou er ook last van hebben.

De Universiteit Utrecht meldt problemen met zijn onlinesystemen en brengt die in kaart, schrijft RTV Utrecht. Volgens een woordvoerder van de UU heeft dit 'onder andere gevolgen voor studenten en medewerkers die willen inloggen op onze website of apps'. Verder is de website van het digitale nieuwsblad van de UU onbereikbaar.

De Nederlandse KVK stelt in een melding op zijn website dat de dienstverlening 'momenteel niet beschikbaar' is door een storing. "Ook zijn wij tijdelijk niet bereikbaar via telefoon en chat." Aanvankelijk gaf de organisatie daarbij aan dat dit kwam door 'een storing in het datacenter'. Dat detail is echter verwijderd.

Niet alle klanten geraakt

Verder bereiken Tweakers berichten dat het kantoornetwerk van de gemeente Amsterdam plat zou liggen als gevolg van de brand in het datacenter van NorthC. Niet alle klanten van de hostingaanbieder lijden onder de vanmorgen uitgebroken brand, weet Tweakers. Beheerders van nog draaiende servers in de Almeerse locatie van NorthC krijgen wel het advies om de temperaturen van hun systemen goed in de gaten te houden.

De oorzaak van de brand is nog onbekend. De brand brak donderdagochtend uit om 8.45 uur, meldt onder meer Omroep Flevoland. Het vuur zorgt voor flinke rookontwikkeling die zichtbaar is boven de stad. De brandweer is opgeschaald naar een GRIP1-situatie. Daarbij wordt er gecoördineerd met andere hulpdiensten, zoals de politie en ambulances. Voor zover bekend zijn er geen gewonden, meldt NorthC in een persverklaring.

Het bedrijf stelt dat het 'klanten die direct gevolgen ondervinden van dit incident' op de hoogte houdt via de reguliere kanalen en het klantenportaal. "Het customerserviceteam draait op volle sterkte om vragen van klanten te beantwoorden en onderhoudt de directe contacten." Het bedrijf 'zal verdere updates verstrekken zodra er meer geverifieerde informatie beschikbaar is over de situatie en over de impact op de datacenteroperaties'.

datacenter Almere. Bron: NorthC
Datacenter Almere. Bron: NorthC

Door Jasper Bakker

Nieuwsredacteur

07-05-2026 • 11:49

329

Submitter: akaryan

Reacties (329)

329
325
160
16
1
137

Sorteer op:

Weergave:

Vanochtend ontstonden er door de grote brand in het datacenter van NorthC in Almere verstoringen in een deel van onze dienstverlening. Daardoor waren onder andere online inschrijvingen, wijzigingen, het opvragen van uittreksels en delen van onze API’s tijdelijk niet of beperkt beschikbaar.

Fijn om te horen dat er voor zover bekend geen slachtoffers of gewonden zijn gevallen bij de brand en dat de hulpdiensten snel ter plaatse waren!

We zagen vandaag veel vragen en reacties verschijnen via verschillende online kanalen, waaronder ook hier. Begrijpelijk ook! Daarom hebben we geprobeerd zo open en transparant mogelijk antwoord te geven op wat we op dat moment konden bevestigen.

KVK beschikt over twee verschillende datacenterlocaties om dit soort situaties op te vangen. In dit geval heeft het overschakelen naar de andere locatie meer tijd gekost dan gewenst. Daarbij spelen meerdere systemen, afhankelijkheden en gecontroleerde herstelstappen een rol, waardoor zo’n omschakeling complexer is dan alleen “een switch omzetten” en systemen en applicaties gecontroleerd opnieuw moesten worden opgestart.

Rond 14:15 uur werkte alle dienstverlening, inclusief de KVK-API, gelukkig weer naar behoren.

We waarderen de betrokkenheid, het meedenken en de kritische vragen hierover. Daarom wilden we graag wat extra context geven bij de situatie van vandaag, ook hier op Tweakers :-)
Beste KVK, ik ben op termijn wel geïnteresseerd om te leren over waar jullie tegenaan liepen waardoor het overschakelen lastiger was dan verwacht. Wellicht een mooie gelegenheid voor een diepte interview hier op Tweakers over het redundantie beleid versus de praktijk.

in mijn ervaring valt het toch meestal tegen. Je denkt dat alles geregeld is qua High availability maar in de praktijk loop je soms toch tegen onverwachte zaken aan.
Zoals aangegeven beschikken we over een tweede datacenterlocatie en een uitwijkscenario, maar niet alle onderdelen van ons landschap schakelen op dit moment al volledig automatisch en zonder onderbreking over.

Daardoor moest de omschakeling gisteren deels gecontroleerd en handmatig plaatsvinden om alle dienstverlening vanuit de tweede locatie weer beschikbaar te maken.

Nagenoeg de gehele dienstverlening was in de loop van de middag alweer hervat en uiteindelijk zijn alle dienstverlening en interne systemen binnen onze interne serviceafspraken hersteld. Dit soort situaties blijven natuurlijk wel belangrijke leermomenten voor zowel techniek als processen.

Of we op termijn meewerken aan een uitgebreider interview over dit onderwerp moeten we intern even bekijken. Voor verdere vragen kun je in ieder geval altijd contact opnemen met onze woordvoerders via de contactgegevens op onze website.

Fijn weekend alvast!
Wat goed dat jullie hier zo reageren, mijn complimenten. Daar kunnen veel organisaties een voorbeeld aan nemen. (y)
Wat fijn om te horen! Daar doen we het voor. Fijne avond!
Fijn zo'n open en eerlijke reactie. Ook fijn dat jullie je dienst verlening op zo'n korte tijd weer hebben kunnen hervatten ondanks dat een deel van je infra wegvalt. Ook het feit dat jullie al op tijd communiceerde dat jullie impact hadden vindt ik stoer en belangrijk.

Top gewerkt voor zowel het Infra team en Team Communicatie!
Dank voor het begrip! Zowel onze technische teams als communicatiecollega’s hebben vandaag hard gewerkt om alles zo snel mogelijk weer stabiel te krijgen en iedereen zo goed mogelijk op de hoogte te houden. Fijn dat dat ook zo is overgekomen. Fijne avond!
Als het alleen een Excel-bestand was geweest, waren we waarschijnlijk iets sneller klaar geweest. Achter de schermen draait natuurlijk een stuk meer: denk aan online inschrijvingen, wijzigingen, koppelingen met andere overheidsdiensten, uittreksels, API’s, authenticatie, Mijn KVK en allerlei systemen die veilig met elkaar moeten samenwerken.

Juist daardoor kost gecontroleerd herstellen en opnieuw opstarten soms wat meer tijd dan mensen aan de voorkant zien.
Juist blij met hun reacties, erg leuk om dat zo eens te zien. Ze worden ondertussen helemaal de moeder geplust ook.
Bij deze geen smileys en uitroeptekens
Ik zie allemaal mensen reageren met: hoe kan je hier nu last van hebben, en waarom sturen organisaties hun mensen naar huis, etc.

Maar dat is best logisch als je weet hoe bedrijven dit vaak inrichten: partijen huren serverruimte of capaciteit van zo'n datacenter. Daar draaien die bedrijven hun workloads/servers weer op. Je moet als bedrijf zelf je DR/tweede locatie regelen. Dat kan soms bij dezelfde datacenterorganisatie, soms moet je daarvoor een ander datacenter contracteren. Veel workloads/servers draaien niet 'hot/hot', dus een datacenter wat offline gaat, betekent dat je je DR scenario moet starten. En dat kost voor veel organisaties 4-24 uur (of nog langer).

Daarnaast heb je dan ook nog ketenproblematiek. Bijv. een van onze zakelijke partners zat op dat datacenter. Die zijn nu hun uitwijkscenario aan het uitvoeren. In ons geval kan dat inderdaad tot 24 uur gaan duren, voordat ze hun hele applicatielandschap weer online is... En daarna kunnen wij onze bedrijfsvoering weer gaan opstarten... Dus al met al duurt dat best lang.

[Reactie gewijzigd door PGR op 7 mei 2026 13:57]

Inderdaad. Een kwestie van eerst een goede risico analyze, en dan de kosten/baten kwestie.

Het bedrijf waar ik werkte had voor de meeste servers een failover in een ander datacenter in een andere stad. Van een aantal servers wogen de kosten niet op tegen de baten. Die konden we aan de hand van back-ups -die wel in beide datacentra werden opgeslagen- wel binen max 48 uur recoveten (meestal binnen 4 uur).

Dit stond dus ook duidelijk in onze SLA's
@PGR je noemt tot wel 24 uur nodig voor een uitwijk. Dat is imho veel te lang.

Bij De Rechtspraak deden testten we minstens 1x per jaar een uitwijk wat neerkwam op alles down, alles up in andere DC, testen of alle applicaties werken, alles down, alles up in origineel DC. En dat deden we in een etmaal.

Dan ben je dus 2x uitgeweken en de gehele productieomgeving opgestart en getest, binnen 1 etmaal. Ik ben even kwijt om hoeveel servers het ging maar het was de totale P-omgeving van de gehele Rechtspraak.

Het enige wat mogelijk niet geheel reeel verliep was dat we gecontroleerd downgingen en dus geen hersteloperatie nodig hadden, maar dat is met tegenwoordig OS en programmatuur toch al een verminderd probleem.
Jij kan dat te lang vinden, maar afhankelijk van allerlei scenario's en kosten/baten analyse kan dat heel normaal zijn. 'Near real time' sync kost nu eenmaal geld, enwanneer ga je overschakelen naar een ander datacenter, wanneer niet, wat mag het kosten, etc. Bijv: is de verwachting bij de eerste rook dat het binnen een uur opgelost is, schakel je niet direct over naar een ander datacenter met de data van 8 uur geleden.
Of 24 uur veel te lang is of niet kun je helemaal geen uitspraken over doen zonder verdere info te hebben over een bedrijf of bedrijven die er 24 uur of (veel) langer over doen. Daadwerkelijk uitwijken en niet een geplande test zoals jij omschrijft is een beslissing die in veel bedrijven niet zomaar even genomen wordt. Kan zomaar gebeuren dat er heel wat uurtjes voorbij gaan voor men daadwerkelijk het besluit neemt om uberhaupt te gaan uitwijken. En het komen tot dat besluit is ook onderdeel van je DR scenario dus telt gewoon mee in je doorlooptijd.
Dat is dan de risicoafweging gemaakt door De Rechtspraak. Andere bedrijven maken andere overwegingen. Echt High-Availability (hot/hot direct failover) kost veel geld en dat moet je afwegen tegen de kans en impact van een disaster (en de recovery).

Ik werk bij een bank en zelfs bij ons zijn maar een paar systemen HA ingericht. De rest zit in de DR (of is SaaS/PaaS) met RTO's van 4 uur tot 72 uur. Dus de kernsystemen kunnen binnen 4 uur al live zijn (en dat testen we jaarlijks) maar de gehele organisatie is dus potentieel pas na 72 uur weer 'up-and-running'.

En zoals @ninjazx9r98 terecht al opmerkt, dit is nog exclusief de tijd die je nodig hebt om te besluiten om uit te wijken. Vaak kost dat ook nog tot 4 uur (of soms langer). Want je gaat ook niet uitwijken als je weet dat een storing 1 uur later kan zijn opgelost...

Dus dit is voor elke organisatie anders.
We hebben zelfs klanten die zeuren over een RTO van 10 minuten (laat staan 4 tot 72 uur ???)
Voor veel huisartsen wordt het ook een hele lange dag:

Huisartseninformatiesysteem (HIS) Bricks Huisarts is getroffen tetra.nl
Klopt. Men registreert alles weer met pen en papier.
Mijn huisarts in amsterdam is ook in de problemen.

Ze kunnen de afspraken niet zien of maken, klantportaal (waar sommigen handelingen zoals recept verlengen ofzo automatische plaatsvinden) is uit en ze kunnen geen medische dossieren zien.

Ze kunnen nog alleen telefonische contact hebben maar die raakt tuurlijk overbelast.

Zij raden aan om huisartsen.nl te raadplegen voor zelf hulp en 112 in geval van nood.

[Reactie gewijzigd door moimeme op 7 mei 2026 22:45]

Kijk het laaste seizoen van ‘The Pitt’ maar eens (aanrader). Dat geeft een beetje een beeld van hoe je in dergelijke gevallen moet zorgen dat je een ‘analoog’ alternatief klaar hebt liggen (en getrainde ‘Champions’ nodig hebt) om het snel op te starten.
het is geen nieuws meer als huisartenpraktijken plat liggen door it storingen geloof ik .
Dit vind ik wel een interessante. Sinds vorig jaar is de NIS2 richtlijn actief en die stelt dat alle kritische infrastructuur (energie, OV, maar ook (g)gz) een (realistisch) back-up/DR plan moeten hebben voor hun dienstverlening in het geval van incidenten.

Van een SaaS-HIS dienstverlener mag je wel verwachten dat die dit op orde hebben, zeker gedien de aard van de dienstverlening.
Hoe kan je er eigenlijk last van hebben? Je moet ten alle tijde kunnen uitwijken naar een andere locatie. Ons bedrijf voert ieder jaar daarvoor een uitwijktest. Tuurlijk, je bent even uit de lucht maar daarna zou je gewoon verder moeten kunnen werken.
Zoals anderen al zeggen, kosten vs baten. Volgens mij zou je uit een business contingency plan (wat veel breder gaat dan IT) op zijn minst een disaster recovery locatie beschikbaar willen hebben. Het beschikbare budget is dan de driver om een locatie volledig redundant, HA of disaster recovery (mag een dag duren om op te starten) te maken.

Er zijn veel organisatie waar een dag downtime niet zal opwegen tegen de kosten van volledige redundantie, iedereen naar huis sturen en IT een dag laten werken aan opbouwen op 2de locatie op basis van backups is niet per definitie een slecht plan.
Helemaal mee eens - zoals altijd iets met stuurlui die aan wal staan.

Neemt niet weg dat het weer een moment gaat zijn waarop een aantal (getroffen) organisaties (kunnen) gaan evalueren: hoe zijn de recovery scenario's in de parktijk gelopen, zijn ze voldoende, etc. Een "what if" scenario is "o dear" geworden, en dan kijk je er anders naar.

Zoals ergens begin jaren 2000 een klant tegen me zei "O, mail mag er gerust een dag of wat uitliggen, we gebruiken het niet zo vaak" en er een half jaar later achter kwam dat 1 van z'n kritische bedrijfsprocessen een afhankelijkheid van mail had...
De brandstofleverancier die een mailtje krijgt als de noodstroom gestart is....
De noodstroom voorziening zorgt er dan toch voor dat de benodigde infra online blijft zodat die mail gewoon aankomt... toch?
behalve dat de mailserver niet aangesloten is was op de noodstroom......
En als de peut opraakt. Of zoals ik het begrepen heb onderhoud aan de stroom/noodstroomvoorziening gepleegd wordt en het wat anders liep dan verwacht ...

[Reactie gewijzigd door tweazer op 7 mei 2026 15:27]

Beter nog: de ruimte die nu in de fik staat de noodstroomvoorziening herbergt. Dat is althans wat ik uit de berichtgeving opmaak.
En waar de 150kv aansluiting en trafo's zijn las ik ergens, allemaal geen 'gewone' situatie ..
Ik bedoelde het als twee losstaande problemen.
1) De mailserver is dood, maar daar kijken we morgen wel naar want zo belangrijk is email ook niet en het is vijf uur dus ik wil naar huis.
2) De mailserver wordt ondertussen gebruikt voor monitoring en het ontvangen/versturen van alerts waardoor uitval van een kritische applicatie niet tijdig opgemerkt wordt.
Er kunnen inderdaad altijd zaken zijn die je over het hoofd ziet.

Ik kan me zelf een situatie bij een datacenter van ons herinneren. We hadden UPS-en voor de overbrugging tussen stroomuitval en opstarten aggregaat, maar de aggregaat had een mains fail delay van ik meen zo'n 3 seconden.
Dat ging uiteindelijk mis toen er een storing kwam waarbij de voeding begon te klapperen. Na 15 minuten waren UPS-en leeg en de aggregaat niet opgestart door de delay en ging alsnog het hele datacenter onderuit...

[Reactie gewijzigd door Fony op 7 mei 2026 22:18]

Klanten die eerst aangeven dat een bepaalde server best een paar dagen uit mag zijn maar volledig in paniek zijn als je zegt dat de server in verband met een spoed-update even moet herstarten onder kantoortijd.

[Reactie gewijzigd door mariomario op 7 mei 2026 14:50]

Meestal zijn dat dan 2 verschillende mensen bij dezelfde klant... en gewoonlijk weten ze van elkaar niet dat dat antwoord uberhaupt gegeven is :+
Die zien dat als verschillende situaties. De ene is een noodgeval, de ander is gepland onderhoud. En dat gepland onderhoud kan vrijwel nooit op werkdagen en alleen als het echt moet in de avonduren. Bij een noodgeval is "nou, dan proberen we even zonder, ik kan er toch niets aan doen".
Wanneer je bij ons infrastructuur afneemt kan je ervoor kiezen om HA of failover naar een 2e plek te hebben, en hier zitten natuurlijk kosten aan vast.
99% van de klanten kiest hier bewust niet voor en neemt een X uur downtime voor lief.
Een paar uur zeg je. De vraag of dit datacenter nog de komende weken/maanden nog in de lucht komt. Dit zou bedrijven aan het denken moeten zetten. Vaak wordt er gedacht in storingen die snel oplosbaar zijn in uren (server, applicatie, glasvezel of stroomonderbreking). Het afbranden van een locatie is van een geheel andere orde.
Dat hangt er dan weer sterk vanaf of de partij waar je ea onderbrengt een scenario heeft dat ze voor je ergens anders capaciteit inkopen en uitvoeren. Als die daar 24 uur voor nodig heeft ben je op hetzelfde punt. De vraag is gebeurt dat en zit dit in je contract. De partij die hier brandschade heeft wil tenslotte asap weer leveren.
Nu een brand, straks een bom?

Je kennie weten.... en wat dan?
Het heeft allemaal te maken met de kosten, risico's die je loopt en de kans dat zoiets gebeurd. Als je redelijk groot bent dan kan je infra 1 miljoen of meer per jaar kosten. Ga je daar een failover locatie tegenover zetten dan verdubbel je eigenlijk je kosten. Wat is de kans dat er een bom op valt of brand is? heb je daar jaarlijks 1 miljoen voor over om het te kunnen mitigeren?
Het is niet zo eenvoudig als de kosten maal 2 en klaar. Het moet ook nog geintegreerd worden met elkaar.

En dat is voor partijen die servers daar neerzetten en klaar zijn. Dan zijn er ook nog de netwerkleveranciers die veelal vanuit datacentra met directe lijnen kantoren e.d. ontsluiten. Die moeten dan op 2 verschillende datacentra aangesloten worden. Dat kost pas knaken, want die tracés moeten gescheiden liggen (graafschades komen veel vaker voor dan een brand) en de 2e is vaak weer langer.
Brand zou zijn uitgebroken bij de aggregaten. Datacenter zit zonder stroom.

Mogelijk dat mobiele aggregaten een optie zijn, dan zalt de impact nog wel mee.
Dit is natuurlijk maar 1 laag in de high availability. Je infrastructuur hoeft niet perse high available te zijn als je applicatie dit zelf al heeft. Wij gebruiken dit concept voor applicaties terwijl de centrale infrastructuur grotendeels is opgebouwd o.b.v. clusters waarbij elke node in het cluster op een andere plek staat
Als ik de berichten die mij via via bereiken moet geloven is de hoop om vanavond een schouw te doen van de locatie om te bepalen of er in de zalen sprake is van rook- of waterschade. Dus hopelijk later vandaag meer informatie.
In ons geval hebben we daar plannen voor en weten we die impact nav restore en failover testen, maar uit ervaring kan ik je vertellen dat MKB (en zeker het kleine deel) een werkdag offline gerust voor lief neemt als t ze maandelijks 30% scheelt.

En ja, onze calamiteiten plannen houden ook rekening met verlies van een compleet DC.
Branden zijn extreem zeldzaam. Maar kunnen prima voorkomen. Zowel op de vloer (en dan wordt het hopelijk vroeg gedetecteerd) maar ook in de ondersteunende infra zoals hier.

Ik denk dat jouw inschatting dat dit weken of maanden gaat duren reëel is. Zeker tot de redundantie volledig hersteld is/de diensten niet meer at risk zijn door minder redundantie.
Er is een verschil tussen een downtime van een paar uur (stroomstoring, opgegraven glasvezelkabel etc) en een datacenter wat door brand offline gaat. Er zijn van die risico's die je in je overweging meeneemt en risico's die je niet meeneemt. Het is altijd kans x schade. Kijk eens hoeveel datacenters in Nederland zijn vernield door brand.

Er is uiteraard een "what if" gedachte ten tijde van de analyse en een "what now" als dit je overkomt. Dus wie weet wordt de uitslag anders na dit incident.
Ja, het is mijn werk om daar rekening mee te houden, en daar plannen voor te maken, nu boeit het voor mijn plannen dan weer niet of een DC verloren is door brand, of een overstroming of een vliegtuig wat naast schiphol in een van de DC's daar geland is, verloren is verloren.
De X staat voor een variabel (afhankelijk van de situatie natuurlijk) tijdsduur. waarbij de X gerust ook 24 uur kan zijn in geval van verlies datacenter.

Technisch is het zo op te lossen overigens, kwartiertje dataverlies en max een uur downtime bijvoorbeeld is nog best betaalbaar te realiseren, en grotere intervallen nog goedkoper, toch kiest bijna geen MKB ondernemer voor zulke zaken.
De implementatie moet aansluiten bij het business continuity plan. Deze brand is een geval dat waarschijnlijk buiten veel aannames viel.

Op de een of andere manier geloven mensen niet dat dit scenario gebeurt. Het is zeldzaam maar komt wel voor.

AWS dat een regio verliest komt ook voor - https://lists.outages.org/archives/list/outages@outages.org/message/DTLQD7WN4H72LTPCPDY7P6LCU4J6AS5B/ - tail risico's waar mensen niet over nadenken.

[Reactie gewijzigd door ANdrode op 8 mei 2026 14:56]

Zijn wel organisaties die betaald worden door jouw en mij, dus de vraag moet zijn wil je 2x zoveel betalen met je belasting?
Een uitwijk locatie kost geld. Je kan gewoon een inschatting maken. Het kost X per dag dat je plat ligt en de kans erop is Y, maar een uitwijk locatie kost Z. Als Z heel veel groter is dan X*Y, dan gooi je alleen maar geld weg.

Natuurlijk is het dan zuur als Y wel optreed, maar dat is dan een bewust risico dat je neemt.
Beetje kort door de bocht. Dat het financieel niet uit kon en door een major IT verstoring je wettelijke taken voor een lange tijd niet kan uitvoeren is best een no-go en heeft juridisch / politieke gevolgen.
En een andere wettelijke taak voor een gemeente is bijvoorbeeld jeugdzorg. Als de kosten voor redundantie (wat gegarandeerd in de miljoenen zal lopen) de jeugdzorg de kop kost, heeft dat gegarandeerd juridische, politieke, en vooral sociale gevolgen. Alle overheidsinstellingen (en eigenlijk ook alle commerciële instellingen) zitten met deze afwegingen, en zullen dus belangen moeten afwegen.
Dat is toch precies onderdeel van die berekening? als je je wettelijke taak niet kan uitvoeren dan kan dat een boete geven, die reken je gewoon mee in je risico analyse.
Klopt. De overheid probeert dit op te lossen door het instellen van de NIS2-richtlijn, maar voor wat ik weet is er in de praktijk alleen reactief toezicht hierop. Waarschijnlijk vanwege het gebrek aaan voldoende capaciteit.
De implementatie van die EU-Richtlijn is de CbW en daar wordt nog volop aan gesleuteld. Daarna zal (waarschijnlijk) een commissie worden opgericht die op de implementatie en naleving toezit, zoals dat ook bij de AVG het geval is. Het is eigenlijk geen capaciteitsprobleem, maar instabiele regeringen de afgelopen jaren.

Neemt niet weg dat we als lidstaat niet gebonden zijn de huidige richtlijn. Sterker nog, o.a. NL is redelijk nalatig in het opvolgen van EU richtlijnen. Gaat overigens om nog veel meer voorzieningen van maatschappelijk belang (kwaliteit en aanbod drinkwater is bijv. nu ondermaats). Maar daar draagt de Staat de verantwoordelijk voor met het uitblijven van wetgeving en niet de betreffende organisaties.

[Reactie gewijzigd door Neurosis op 8 mei 2026 14:00]

Ik mag dan wel hopen dat ze minstens hun backups op een volledig andere locatie staan hebben.

De backups van mijn zaak gaan constant mee naar mij thuis, zit een 20km tussen, als zowel mijn winkel als mijn huis tegelijk verdwijnen, dan zal eerlijk gezegd de backups mij worst wezen :) want dan is ofwel Poetin daar, ofwel een global killer asteroide :)

Als ze natuurlijk hun backups ergens zitten hebben in hetzelfde datacenter dat nu in brand staat , tja :)
En houdt je die back-ups ook altijd thuis en vul je ze aan/vervang je ze? Of is alles op dezelfde locatie wanneer jij in je zaak aan het werk bent?
Worden steeds gewisseld :) (is een dubbele set)

en moest ik thuis niet zo een KAK vdsl internet hebben, dan ging het natuurlijk gewoon automatisch via internet met een Rsync job of zo, maarja , fiber is nu weer beloofd zeker voor 2026 , ik ben benieuwd :)
Hoe vaak doe je een restore test van je backups? Want als je dat nooit test dan heb je eigenlijk geen backup maar een lege tape/disc ;).
Dat zou inderdaad wat meer getest moeten worden, MAAR, de data van de backups gaat effectief op beide locaties de server op en ik zie de data dan op beide locatie's staan, maar inderdaad, thuis gebruik ik die data van het werk natuurlijk bijna niet en omgekeerd ook de data van thuis gebruik ik niet echt op het werk, dus echte test niet genoeg :)

binnekort komt er wel weer een grote test aan want ben momenteel aan het experimenteren met TrueNAS en mogelijk schakel ik beide locatie's nog wel eens over naar TrueNAS als het mij bevalt (zit thuis op een OpenMediaVault en op het werk nog op een oude Synology, beide locatie's hebben ook wel dubbele schijven, dus voor hardware failure zijn ze ook nog eens ingedekt :) )

Zal zeker niet zeggen dat ik het allemaal top ingericht heb, maar gezien alle hardware behalve de Synology NAS allemaal recyclage is (oude PC, gaming pc's, schijven, ....) en dit dus voor een kleine zelfstandige zaak is met 2 man (ik en mijn broer) , ziet het er eigenlijk al naar uit dat ik het mogelijk op sommige punten al beter in orde heb dan bij sommige gebruikers van dit datacenter, en waarschijnlijk voor 0,000001% van hun budget :) :) (maar is natuurlijk ook beetje hobby dus moet mijzelf geen IT loon betalen :) )
Maar wat nu als het terugzetten van een backup 18 uur duurt en je dan de data van de vorige dag terug hebt. Dan is even wachten en hopen dat de brand meevalt, en je over een paar uur weer online bent ook heel verleidelijk.

Recovery en replicatie zijn moeilijke dingen om goed te doen.
Ik heb ooit een directeur van mij geadviseerd dit niet te doen. Het primaire proces zou doordraaien bij een uitval van de KA omgeving en kantoorpersoneel zou niet (goed) kunnen werken. Een HA-omgeving zou ca 200K per jaar extra kosten.

Na 5 jaar geen storing was er brand in het DC waardoor we 24 uur offline zijn geweest. Die 24 uur doorwerken zou ons achteraf 1 mio hebben gekost: daarvoor kun je best een dag offline zijn.

Er zit natuurlijk veel nuancering in, maar in heel veel situaties is uitval van enkele uren tot enkele dagen geen wereldramp. En soms wel en dan heb je het geld er wel voor over, maar stellen dat je ten alle tijd MOET kunnen uitwijken is echt overdreven.
Altijd leuk met Finance systemen waar ICT'ers op 1 of andere manier altijd een hoge beschikbaarheid verzinnen. Tot nu toe zegt elke financiële afdeling waar ik heb gewerkt dat een maandje handmatig salaris uitkeren best vervelend is maar geen enorme ramp. Dat is dus ongeveer 50 dagen offline na laatste moment van uitkeren voordat het echt problematisch gaat worden

[Reactie gewijzigd door Mellow Jack op 7 mei 2026 16:30]

Bovendien maakt goede HA die echt snel kan overschakelen systemen ook veel complexer. Ik heb tegelmatig gehad dat HA juist voor meer downtime gezorgd heeft dam een enkele locatie met een cold DR locatie.
Jup, ooit gehad dat een device wat juist meer uptime moest geven (automatic transfer switch voor stroom) voor devices met 1 voeding kortsluiting gaf en beide feeds in een rack eruit klapte.... idee een 10, resultaat een 1.....
Heb jij ook twee telefoons met twee verschillende netwerken, twee laptops. Twee autos etc etc. Het is een kosten baten afweging. Ik vind er vanuit gaan dat je ten alle tijden kunt verplaatsen niet echt "fair". Dat is namelijk soms gewoon niet haalbaar kosten technisch.
En 2 huizen op 2 verschillende tektonische platen. Heeft niet iedereen dat dan? 😜
Goh,

het is net waar die twee tektonische platen elkaar raken dat het feest kan zijn :) zit je eigenlijk beter met je twee huizen in het midden op dezelfde tektonische plaat :) :)
Ik wel:

Ja -> 3 verschillende netwerken -> Ziggo, Vodafone 5G, Odido 5G
Ja -> 6 laptops -> 4x Windows & 2 Macbook Pro's.
Nog leuker te maken -> 5x Windows PC's (waarvan 3x mini PC's. Kunnen ze opgepakt en meegenomen worden.) en nog een hele oude Mac Pro -> Wordt t.z.t vervangen door een Mac Mini of Studio.
Ook nog een NAS.
Alle machines en laptops zijn volgepropt met (bijna) max geheugen en 60+TB HDD's / 8TB SSD's totaal.
UPS is een aantal jaren geleden gesneuveld -> na de zomer nog vernieuwen.

Backups van belangrijke data staat op meedere PC's / HDD's / NAS / Externe HDD's / SSD en in de cloud.


Bedrijven betalen heel veel voor redundantie buiten de deur.
Denk aan rackspace inhuren, hardware aanschaffen, netwerk afnemen.

[Reactie gewijzigd door crzyhiphopazn op 7 mei 2026 13:36]

En toen knipte een monteur buiten per ongeluk het verkeerde draadje door, en zit je als je UPS leeg is (uurtje?) zonder stroom... Je buren ook, dus dan moet je alsnog een Plan C bedenken.
Uiteindelijk gaat er altijd een keer komen dat je zegt 'einde planning bereikt, vanaf nu gaan we best-effort proberen'.

Als het goed is (en ik weet al lang dat het _niet_ goed is bij teveel tokos) heb je dat netjes op papier, want de betere certificeerders willen dat zien.
Iets met graceful shutdown.
Powerbank aan je telefoon en ik heb gewoon nog internet :)
Dat valt tegen heb ik gemerkt. Stroomstoring in de wijk. Ik heb een ups maar de wijkcentrale was al snel uit. Dus toen was het over met de pret.
UPS is meer bedoelt om je systemen een graceful shutdown te geven.
Gelukkig met laptops ga je dan over naar batterij en kan je "vrolijk" verder werken.
Heb 2x meegemaakt dat er een stroomstoring was.
1e x was ik niet thuis, maar was ik in de buurt en kon ik gelukkig een graceful shutdown doen.
2e x was ik wel thuis en direct een graceful shutdown gedaan en verder gewerkt op mijn laptop.

Gelukkig heb ik ook een elektrische auto dus kon ik alles opladen vanuit mijn EV.
Goed geregeld, totdat je huis afbrandt, dan heb je helemaal niks meer, behalve de cloud backup.

Ik moet dan meteen denken aan dat bedrijf bij de Twin towers in New York, die de data had op één van de torens en de backup.... Juist, in de andere toren.
Er zijn grenzen tot hoe ver je moet gaan. Wij verkopen spotgoedkope dienstverlening, als zoiets ons treft is er gewoon even geen dienstverlening en is het wachten. Pay peanuts, get monkeys. Wil je een achterlijk hoge uptime, sla's etc. kost dat gewoon veel meer.
Liever een cloud backup dan geen backup.
BTW ik heb altijd 1 van mijn laptops bij mij dus ik heb een backup van mijn belangrijke data.

maar ik snap zeker je punt.
Geo location MOET je als bedrijf ook meenemen in je DRS plan.
Ik heb inderdaad thuis een Starlink mini liggen en een 5G router
Mijn partner als reserve. Prima chatbox en beter dan AI.
Ik denk dat ze de uitwijktest een tijdje niet hebben uitgevoerd.
Die test is in Dronten met hun mailservers in iedergeval gelukt.
Dat is helaas niet voor iedereen haalbaar qua kosten en beheer.
Of je uberhaupt een compleet uitwijkscenario hebt hangt van meerdere dingen af, om maar eens te beginnen met geld. Het blijft een risico afweging in hoeverre je op dit soort dingen voorbereid wil zijn. Dan is nog de vraag in hoeveel tijd je weer up & running wil zijn. Het kan een prima keuze zijn om - al dan niet voor een deel van je diensten - ervoor te kiezen om geen uitwijk te hebben en het restrisico te accepteren.
Als bij jou het huis afbrand, heb je dan een tweede backup locatie?
Ik heb een caravan waar we in kunnen, dus ja :)
Ik heb nog wel een oud tentje op zolder liggen :P
Werkt die nog als je huis is afgefikt? :P
8)7 Helaas staat de trap naar zolder in de brand.
Naast de opblaasboot, neem ik aan? :9
Die is er alleen voor de overstroming.
Omdat dat waarschijnlijk heel veel extra kost en daardoor voor genoeg bedrijven mogelijk niet betaalbaar is.
Nee, je moet dergelijke risico’s gedocumenteerd hebben in je risico-register en dan gaan bekijken wat de volgende mitigatiestap is (en een residu risiconiveau). Daaraan zit ongetwijfeld een kostenplaatje. Het is dan aan de bedrijfsleiding om te beslissen: we gaan mitigeren of we accepteren het risico.

Geaccepteerde risico’s laat je nadien periodiek herbevestigen door de bedrijfsleiding. Stomtoevallig werd bij ons zo’n geaccepteerd risico ongedaan gemaakt en werd er besloten dat het risico gemitigeerd moet gaan worden.

Blind alle risico’s gaan mitigeren is onbetaalbaar en onzinnig.
Wij hebben ons serverpark nog geheel op ons hoofdkantoor draaien in een eigen serverruimte. Waarom? Datacenter is duur en hoe groot is nou de kans dat dit pand affikt of instort of langduring stroom uitvalt of overstroomd? Dat is de denkwijze van onze directie. Zelf een uitwijk locatie bouwen op 1 van onze vestigingen schat ik rustig op 500k, die hardware staat daar dan idle te draaien voor het geval je het ooit nodig hebt en na 6 jaar is het EOL en kun je het vervangen.

That being said, wij zijn van plan de boel naar een datacenter te verkassen want betere redundantie. En dat was waarschijnlijk dit datacenter geworden :+
Redelijk "simpele" analyse. "Hoe erg is het als je er een dag uit ligt, okay weegt de prijs op tegen dat risico?"
Eens paar jaar zijn roekoe nummers, wij doen dat 2 maal per maand.

Afhankelijk wel type systeem (db, API, streaming services etc..) niet alleen dat maar ook recovery is verplicht om te testen (de test dacht ik eens per jaar, de backups zijn streaming met 2 minutes maximal RPO) .

Maar goed, dan wat je het van te voeren, ik ben wel zeer benieuwd wat er gebeurt als er ‘spontaan een data center eruit ligt).
Wie zegt dat dat moet? Kan heel goed een geaccepteerd risico zijn om het niet te doen.
Alles is te voorkomen, mits je de buidel trekt.
Maar je moet ook wel weten wat er aan de hand is.
Wij hebben een 50-tal servers in het datacenter van NorthC staan, maar door deze brand zijn die niet meer te benaderen. Ik heb een mooi dashboard waarop alle servers "groen" zijn, maar toch ligt alles plat omdat de servers niet te benaderen zijn.

[Reactie gewijzigd door gdisselkoen op 7 mei 2026 15:00]

Als je niet zelf inregelt dat je bij een andere locatie van Northc je servers hebt staan is dit datacenter gewoon "down".
Dat "je ten allen tijden moet kunnen uitwijken" is gewoon veel te plat geslagen.

Wat zijn de kosten voor welke DR-duur? Hoe kritiek zijn de processen? Seamless kunnen overfalen is duur. Binnen 4 uur weer up zijn is goedkoper. Binnen 24 of 48 uur is nog goedkoper.

Dat is een kosten-baten analyse (met ook risicoafweging) en het antwoord op die analyse is niet "altijd maximale HA."

[Reactie gewijzigd door ZinloosGeweldig op 7 mei 2026 14:42]

Voor wat wij weten, alles wat er draaide aan de linkerzijde/zalen (vanaf de voorzijde gezien, de brand foto's zijn merendeel aan de achterzijde genomen en dus de rechterzijde daar) is stroomloos/down.
Aan de achterkant van het gebouw, vanaf de hoofdingang gezien links, staat een satelliet/bijgebouw/trafohuis in brand. Op Maps is dat de pukkel noordwest van het DC.
Dat is niet meer te redden volgens de brandweer, ze concentreren zich op het behouden van de rest en op het voorkomen van het ontbranden van de dieseltanks voor de noodagregaten.
Alarm is gegeven om 08:32, onze servers waren tot 9:07 te bereiken en daarna is de stroom op die vloer uitgezet/uitgevallen. Nu is het afwachten of de hardware nog intact is na de brand.
Volgens open street maps is het de 150kv, dus de stroomaansluiting. Ik verwacht niet dat het dan binnen korte tijd allemaal weer gaat doen ook al zou er beperkte schade zijn aan de vloer waar de apparatuur staat.
Even voor mijn interesse: waar kun je dit zien?
OpenStreetMap.org dan de locatie opzoeken. Als je dat vergelijkt met de brand foto's van verschillende media dan is het de 150kV NorthC Blackbox
Dat is nog duidelijker, de aansluiting komt dus van 1 kant en zit precies op de locatie zoals OpenStreetMap aangeeft. Ik denk dat het nog wel even kan duren voordat dit weer up is.
Hopen dat ze vervanging van de HV-trafo ergens contractueel afgedekt hebben. Als je die nu koud besteld wordt de levertijd gerekend in jaren.
Ookal heb je een contract, misschien is die trafo er gewoon niet. En krijg dat ding maar eens op zijn plaats en werkend.

Kans is zo maar aanwezig dat men hier op de generatoren gaat draaien voor een hele tijd.

Weet wel dat er een paar mensen heel hard moeten gaan werken dit allemaal draaiende te krijgen.
Kans is zo maar aanwezig dat men hier op de generatoren gaat draaien voor een hele tijd.
Gezien alle rook wat uit die ruimte komt zullen deze niet meer gaan draaien
Ik schreef 'de', maar het dat woord weg moeten laten. Zoals @RonJ ook al schreef: Bredenoord gaat misschien even goede zaken doen.

De exacte schade en omvang is nog niet bekend, maar men zal er alles aan doen dit binnen enkele dagen weer draaiende te krijgen.
Dat sowieso niet, maar je zou wel prioriteit op de productielijn kunnen reserveren. Ik weet dat netbeheerders dat ook hebben voor kritieke componenten. Dan is ie er nog niet morgen of volgende week, maar ook niet pas over twee jaar. Heb je dat niet, dan gaat de firma Bredenoord goede zaken doen dit jaar. Maar ook voordat je de boel weer genoeg hersteld en schoon hebt om die te kunnen inpluggen ben je wel een paar weken tot maanden verder.
hmm de trafo an zich kun je bestellen en is er met enkele dagen, helemaal in een dergelijke situatie. Wat jaren duurt is de "aansluitinging"

De tijd die zit tussen het accepteren van de aansluiting en de uitvoering is enkele weken in normale gevallen.
We hebben het hier over een 150kV aansluiting en dito trafo's (50-150KVA range), niet over een touwtje bij jou thuis. Die trafo is er niet en de orderboeken zitten voor jaren vol. Google maar op "levertijd 150kV transformator". Zelfs Chinese partijen spreken van maanden tot jaren levertijd.

[Reactie gewijzigd door RonJ op 7 mei 2026 14:45]

Ik weet waar we over praten. 150 kV compact station kun je redelijk snel krijgen. Als jij googled zie je meerdere aanbieders die hem in een week of 4-6 kan leveren.

Daarnaast worden in dergelijke situatie echt wel wat harder aan touwtjes getrokken zodat een dergelijk bedrijf snel weer is voorzien van spanning.

Daarnaast is voor de netbeheerder geen nieuwe aansluiting, maar een (flinke) storing aan een bestaande. Wat jaren duurt is het reserveren van vermogen uit het net.
Ik had MVA moeten schrijven. Met een compact station dingetje voor een rijtje huizen in een woonwijkje kom je bij een beetje DC zoals deze niet zo heel ver. Laatste DC waar ik bij betrokken was ging het om 2x 80MVA.

Verder heb je gelijk, de netaansluiting is er al, hooguit moet er een kabel gerepareerd worden.
Mijn ervaring met contractuele verplichting met boeteclausule was het per ommegaande betalen van die boeteclausule.

Oeps...
Deze staat tussen het datacenter en de generator gebouw in. Andere kant heeft dit ook.

Dus als de generator ruimte en je 150kV in brand staat. Dan is het wel een beetje afgelopen daar!
Oei, 150kv, daar kun je al gauw vlambogen mee maken tot zo'n 2 meter .... De olie in de trafo's zall ook niet helemaal gezond zijn ...
Ik denk dat die olie in de trafo's nu koolstofdioxide is geworden of aan het worden is...
Een DC heeft meerdere feeds, stroom is uitgezet door de brandweer.
Geen idee of deze dat ook heeft, het pand staat er al bijna 20 jaar. Geen idee of het toen ook normaal was om te doen.
Zelfde signaal hier, afwachten of de HW en infra lijnen nog intact zijn. Wordt maar weer pijnlijk duidelijk dat Geo Redundancy belangrijk is.
Ik blijf het altijd bijzonder vinden hoe zo iets zo erg kan escaleren in datacenters. Datacenters hebben over het algemeen zeer high tech blussystemen, en hebben alles zo'n beetje wel redundant uitgevoerd. Hoe het dan toch kan gebeuren dat een heel gebouw op zwart gaat vind ik toch knap.
Gezien de foto's en beelden op Omroep Flevoland is de brand in de locatie waar de noodstroom voorzieningen zitten (misschien ook wel de koelsystemen). Om de veiligheid van de brandweermensen te waarborgen zal de brandweer sowieso de netstroom (en gas indien dat er ook is) laten afsluiten en ook noodstroom voorzieningen uitschakelen in dergelijke situaties (vaak ook als de brand niet rechtstreeks bij stroom en gas infra is). En ja, dan gaat dus een heel DC op zwart.
Het blijft ironisch dat juist het backupsysteem er voor zorgt dat het hele DC uitvalt.
Dit is de backup van de backup zelfs. Ik heb er wel eens een rondleiding gehad, dit DC krijgt stroom vanuit 2 richtingen, Amsterdam en Zwolle (dacht ik) dus als 1 van beide wegvalt blijf je draaien. Als beide wegvallen hebben ze nog aggregraten. Maar stroom uit 3 richtingen is mooi, maar als dan je schakelmateriaal/bekabeling affikt heb je daar niks aan.
Wij hebben een keer gehad dat het systeem dat de twee feeds moest scheiden/schakelen dacht dat de ene feed was uitgevallen. Vervolgens werd de andere feed geactiveerd, door een schakelfout bovenop de aktieve 1e feed.

Beide feeds op elkaar kortgesloten. Een grote boem en een donkere wijk was het gevolg. Dan denk je alles onder controle te hebben zit er toch een lullig kastje dat zelf een verkeerde beslissing neemt.
Misschien denk ik heel simpel, ik heb immers weinig kaas gegeten van het opzetten van datacenters. Maar is het niet mogelijk/slim om die noodstroomvoorziening op een x meter afstand van het hoofdgebouw te plaatsen? Zodat deze enigszins hermetisch afgesloten kan worden bij problemen?
Ironisch zeker, onverwacht zeker niet. Ik zie vele male meer storingen door UPSen dan door stroomstoringen...
Beetje vergelijkbaar met data verlies door een defecte RAID controller..
Gezien de foto's en beelden op Omroep Flevoland is de brand in de locatie waar de noodstroom voorzieningen zitten (misschien ook wel de koelsystemen).
Bij klanten roep ik dit scenarios wel eens als ze koste wat het kost geen single point of failure willen: brand of kortsluiting achter de no break of de koelinstallatie. Leidt gegarandeerd tot grote ellende en is echt enorm lastig strucrureel te voorkomen, tenzij je bereid ben je hele koeling en energievoorziening volledig gescheiden uit te voeren met gescheiden intakkingen etc. Loopt belachelijk snel in de papieren, en als je dieper in de installatie een issue hebt, moet de boel alsnog spanningsloos.
Om de veiligheid van de brandweermensen te waarborgen zal de brandweer sowieso de netstroom (en gas indien dat er ook is) laten afsluiten en ook noodstroom voorzieningen uitschakelen in dergelijke situaties (vaak ook als de brand niet rechtstreeks bij stroom en gas infra is). En ja, dan gaat dus een heel DC op zwart.
Als je inert gas het zelf niet aankan is dat inderdaad het scenario vaak. De vermogens waar het om gaat zijn vaak ook enorm. Daar wil je echt geen bluswater ongecontroleerd bij hebben.
Voorbeeld werd gegeven dat het eigenlijk alleen mis kon gaan als er een vliegtuig of bom op valt….
"Everything works in PowerPoint." :)
Tenzij je een brandje in een SPOF ruimte hebt.
Protocol brandweer, gebouw gaat spanningsloos ondanks brand in een ander compartiment, probleem dat de brand zo lang duurt komt doordat er mogelijk accu,s in brand staan die blus je niet eenvoudig.

Best wel funny als ze zeggen dat er geen gevaarlijke stoffen vrijkomen, ja me reet, rook is altijd giftig zeker als er ook accu,s in brand staan.

[Reactie gewijzigd door mr_evil08 op 7 mei 2026 14:26]

Die blussystemen zijn vooral om een initiele brandhaard snel te doven. Argonsystemen zijn hier een voorbeeld van. Je pompt de datavloer vol met argon, brand dooft en voila. Nadeel: laait hij weer op heb je geen argon meer.

En de vraag is of een traforuimte dan meegenomen wordt. In principe blus je dat niet snel met een blusgas. Die fik laait gewoon weer op daarna. Stroom moet je sowieso uitschakelen uit veiligheid, dus dat het op zwart gaat is vrij logisch.
Argon is wel heel heel heeeeeel oud. Volgens mij zijn argon blussers al 20 jaar verboden.
Het kan zijn dat ze een ander gas gebruiken natuurlijk :+ Ik ben geen expert, het enige wat ik weet is dat als het brandalarm af gaat je alles laat liggen en zorgt dat je de datavloer af bent.
Het probleem met Argon is dat het zuurstof verdrijft en dat je dan stikt. Wel heel efficient om brand te bestrijden, maar een beetje vervelende nevenschade.

Wat ze tegenwoordig doen is extra stikstof de ruimte in blazen, zodat relatief gezien de hoeveelheid zuurstof daalt. Onder een bepaald percentage zuurstof in de lucht heb je geen vlammen meer, maar mensen kunnen dan nog wel ademen.

Ze stoppen er ook wat extra CO2 bij, en blijkbaar word je longen dan gestimuleerd om extra zuurstof uit de lucht op te nemen.
Ik begrijp ff iets niet. Hoe kan het zijn dat in dat datacenter zo een grote brand is. Bij mijn weten als ex ITer vaak genoeg in dat soort ruimtes geweest en verplichte instructies meekreeg ivm het Halon blussysteem. Dat gas dooft meteen het vuur en dood je als je daar blijft. Heeft een datacenter dat niet dan?
Accu,s laten zich niet eenvoudig blussen, brand is in de technische compartiment.

[Reactie gewijzigd door mr_evil08 op 7 mei 2026 14:19]

Op dit datacenter staan geen accus racks als UPS system maar een Dynamische UPS/generatoren (DRUPS)

Diesel-aangedreven UPS- systemen ( DRUPS ) combineren de functionaliteit van een UPS vliegwiel en een dieselgenerator. Zolang de netspanning binnen de specificaties valt, fungeert een elektromotor/generator met vliegwiel als motor om kinetische energie op te slaan.

zie ook : https://datacenterworks.nl/artikelen/dynamische-ups-op-basis-van-vliegwieltechnologie

Wens NorthC en hun daar aanwezige klanten veel sterkte de komende dagen
Het is de keuze aan de ontwerper op het moment van inrichten wat/hoe er wordt opgesteld. Dat kan heel mooi een drups zijn zodat het draaiende moment van het vliegwiel er voor zorgt dat de stroom en spanning op niveau blijven en dat de dieselmotor start en de electromotor in generator bedrijf gaat.

Ook kan het heel goed zijn dat er een accu pakket staat dat een kwartier de spanning en stroom op houdt en dat de dieselmotor na een paar minuten de tijd krijgt om op toeren te komen en de generator de stroomvoorziening kan overnemen van de accu's.

Er zijn zelfs rekencentra ingericht die geen centrale ups voorziening hebben maar op elke server een eigen accupakket, vergelijkbaar met een laptop.
In de spec's van NorthC Almere staat dat men daar een DRUPS gebruikt (en dat is bij meerdere NorthC zo (zal hun ontwerp zijn)

Die laaste optie die je noemt is voornamelijk ingegeven door google/facebooks met hun open slee ontwerp van hun CPU als server om kosten tebesparen of kast, voeding ect.
Goed om te weten, maar de rook blijft giftig, de meeste datacenters hebben altijd wel wat accu,s erbij staan.

[Reactie gewijzigd door mr_evil08 op 7 mei 2026 16:45]

Benieuwd wat er dan in brand staat, er hingen overal sprinklers.
De ruimtes waar de servers staan waarschijnlijk wel.

Maar voor zover ik het nu begrijp (van andere reacties hier) is de brand ontstaan in de ruimte(s) waar aan de stroomvoorziening wordt gewerkt. Zeker in ruimtes met UPS' en is er flinke ventilatie en dus ook flinke airflow. Dat maakt een brand sowieso moeilijk te blussen en ik denk dat blusgas hier ook niet gebruikt kan worden.


Maar ben geen expert op dit gebied.
Sinds 2004 mag er geen HALON meer gebruikt word in nederland, is natuurlijk al reeds vervang door een ander inerte gassen (zuurstof verdrijvend) of watermist installatie's.

Dit zal zeker wel toegepast zijn op de computer vloeren , maar in de technische ruimte's zal wel wat anders zijn toegepast.

Als je de foto's bekijkt zie je dat ze aan het werk ware op die zijde van het pad (waar technische ondersteunende dingen draaide (UPS, generatoren, wellicht ook de koeling)
Ik huur een rack in dit DC. Om 09:09 uur ging de hele boel plat en raakte ik de connectie kwijt. NorthC heeft aangegeven dat de brand is ontstaan tijdens werkzaamheden. Hoop oprecht voor mezelf, en alle andere systeem- & netwerkbeheerders die getroffen zijn door deze ramp dat de schade aan apparatuur op de vloer beperkt is gebleven.
Qua brand zal het misschien mee kunnen vallen maar rook en roet incombinatie met computer apparaat betekend eigenlijk altijd dat alles vervangen moeten worden.

Helaas 2 weken geleden brand hier gehad op het aanliggende pand bij ons kantoor en eigenlijk moeten alles vervangen worden omdat in rook zuur zit wat alles aantast. Ook al werkt alles nu nog kan het maar zo over een jaar klaar zijn.
Als ik het goed gezien heb op de beelden, dan bestaat het datacenter uit 2 panden. In het ene pand staan alle apparaten die nodig zijn om een datecenter in bedrijf te houden, denk aan generatoren, koelingen en stroom voorziening. In het andere pand zijn de server ruimtes. Het lijkt mij dus stug dat er rook schade is in de server ruimtes. Maar goed ik kan het mis hebben, dit is wat ik aflijd van wat ik op de beelden heb gezien. Ik weet dat de datacenter van NorthC in Oude meer wel zo is opgebouwd.
Als je via Google Maps kijkt zijn het aparte gebouwen maar ze zitten gewoon aan elkaar. De eventuele rook kan dus gewoon via de gangen naar de andere ruimtes. Dan is het heel erg de vraag in hoeverre dat lucht dicht allemaal is.

Wat ik in mijn eerste bericht ook aangaf, bij ons 2 weken geleden brand en die rook was binnen no-time aan de andere kant terwijl het 2 panden zijn die verder los van elkaar zijn maar wel verbonden via gangen. Dus zelfs een normale dichte deur is niet genoeg.
In beide panden zijn server ruimtes. Van de voorkant gezien is het linkerdeel als eerste in gebruik genomen met serverruimtes, later is het rechter deel ook in gebruik genomen met server ruimtes.
Wat je bedoelt met de opbouw in Oude Meer snap ik niet helemaal, dat bestaat ook niet uit twee panden.
Van buiten af gezien zou je inderdaad denken dat het datacenter in Oude meer 1 pand is. Maar er is een fysieke schijding tussen het pand met de data zalen en het pand met de generatoren en ander systemen die nodig zijn voor de data zalen. Dit is gedaan om trillingen van die systemen niet door te laten vloeien naar de data zalen.

@Brummetje In het datacenter heb je nog de mogelijkheid om de downflow units harder te laten blazen. Op die manier onstaat er overdruk in de datazalen waardoor de rook buiten die zalen gehouden kan worden. Of in ieder geval minder rook binnen komt. Ik weet niet of ze dat hebben kunnen doen, of daadwerkelijk gedaan hebben.
Je weet dat je servers gewoon kunt laten wassen (technical reconditioning). Daarnee word alle roet en vet weg gespoeld.
Uiteraard maar dat is ook niet gratis ;)
Ik hoop eerder op goede offsite backups 😉
Heb je de pricewatch gezien? In deze tijden een heel rack moeten vervangen, ai.
Dacht altijd dat data centers soort van zuurstof wegnemende brandpreventie systeem hebben en vaak als een bunker gebouwd.
Brand is ontstaan tijdens werkzaamheden. Werkzaamheden betekent aanwezigheid van mensen. Mensen hebben zuurstof nodig. Ergo: tijdens werkzaamheden worden dergelijke systemen al snel uitgeschakeld. Die mensen er levend uitkrijgen wordt belangrijker geacht dan de servers die een probleem hebben.
Dit klopt niet. Zelfs bij oudere blussystemen ga je niet dood door gebrek aan zuurstof. Wel een goede kans dat je bewusteloos raakt. Moderne systemen bevatten meer zuurstof en blijf je bij bewustzijn.

Wel zou ik me zorgen maken over je oren. Niet fijn als die dingen de ruimte volduwen met een paar honderd bar.

Bij werkzaamhden zet je het blussysteem niet uit, maar wel de melders. Je zit er niet op te wachten dat dat systeem afgaat terwijl je aan het lassen bent. Maar als het goed is, is dat ook gesegmenteerd uit te schakelen.
Die wordt niet uitgeschakeld, hooguit uitgestelt blussen als het alarm gaat, als de accu,s branden dan is dat mooi te laat en zal het blijven branden.

[Reactie gewijzigd door mr_evil08 op 7 mei 2026 14:46]

Misschien stond het raam open? Als het inderdaad zo is dat de noodstroomgeneratoren in de fik zijn gevlogen dan kan het zijn dat de brand via andere route naar binnen is gekomen en de blusgasinstallaties niet effectief meer zijn.
Een datacenter heeft geen ramen in cruciale ruimtes, wel kan het zijn dat de nooddeuren nog open staan maar ook dat is de betwijfelen gezien daar een "veer" op zit.
Ik denk toch echt dat er daar wat windows draait hoor ...
Moah meeste zal wel Linux zijn wat daar draait, wellicht Windows als guest OS.
Dat hebben ze ook, echter als er accu's branden zijn ze niet eenvoudig te blussen en daar lijkt het op gezien hoe lang de brand al duurt.
Op last van de brandweer is het pand spanningsloos gemaakt, protocols etc.

Een datacenter is opgebouwd in compartimenten, de hardware/servers lijken tot dusver niet getroffen, ze staan gewoon uit omdat het pand spanningsloos moest worden, of ze toch roetschade oplopen weten we pas later, in theorie zou dat niet mogelijk moeten zijn.

[Reactie gewijzigd door mr_evil08 op 7 mei 2026 14:43]

Dat hebben ze ook maar alleen in de serverruimtes, niet in alle ruimtes eromheen.
In ruimtes waar servers staan wel. Maar de brand schijnt ontstaan te zijn bij werkzaamheden aan de noodstroominstallatie en in die ruimtes heb je juist geforceerde ventilatie nodig om UPS'en, transformatoren, generatoren te koelen.
Bij ons (grote ZBO) is iedereen (behalve IT beheerders) naar huis gestuurd. Ons primaire datacenter is uitgeschakeld door de brandweer (stroom eraf). Ons secundaire datacenter is maar zeer beperkt operationeel. Ik voorzie een aantal overuren in de nabije toekomst.
Lekker geo-redundant!
Zonder meer informatie is dat lastig te concluderen. Als er - voor dit soort situaties - een secundair datacenter bedacht is met beperkte (hoognodige) capaciteit kan het he,lemaal volgens de gekozen gedachte functioneren.

Een volledig redundant DC met voldoende capaciteit om "naadloos" alles te kunnen blijven doen is niet goedkoop, niet elke organisatie heeft daar de middelen voor of de behoefte aan.
@Techno Overlord zegt "een grote ZBO". Daar hebben we er nogal wat van, maar ik verwacht toch wel dat ze allemaal hun IT landschap netjes op orde hebben.
Een "grote ZBO" hoeft ook geen mega budget te hebben hoor.

Nogmaals: verwar niet "beperkt operationeel" met "werkt niet zoals bedoelt is". Risico afdekken kost geld; datacentra staan niet wekelijks in brand, het risico daarop is beperkt. Dus kan het een ingecalculeerd risico zijn waarbij een volledig of beperkte dienstverlening voor lief genomen wordt. Daarom zeg ik ook dat alleen op basis van een uitspraak het lastig is om conclusies te trekken.

Overigens om wat reacties voor te zijn: ja, ik ben me er van bewust dat er in veel organisaties veel te licht gedacht wordt over het niet beschikbaar zijn van bepaalde ICT middelen ("dan doen we het toch een dagje zonder") terwijl op het moment dat het gebeurd er moord en brand geschreeuwd wordt.
Nou ja. Je 'zou mogen verwachten', dat als je je spullenboel over meerdere rekencentra verspreidt, dat die wel zo ver uit elkaar liggen dat je geo-lokale problemen probeert te vermijden toch? Iets dichter bij elkaar kan ook handig zijn natuurlijk, voor synchrone datareplicatie en zo, maar als je dat soort zaken niet specifiek nodig hebt,, dan is het denk ik handig om het verder uit elkaar te houden.

Of je nou ruimte huurt in rekencentrum 1 of 2 zou niet het budget-verschil moeten uitmaken :)
Waar haal jij vandaan dat ik iets zeg over de afstand tussen 2 datacentra?

En de ruimte huren zal misschien nog wel meevallen (hoewel dat ook best kostbaar is), maar het gaat er ook nog om dat je apparatuur hebt, die onderhoudt, etc.

Ik weet niet wat jouw achtergrond is, maar vanuit die van mij (aantal decennia ICT beheer) is het heel makkelijk oordelen bij zo'n incident als vandaag, maar je moet eerst alle keuzes en maatregelen kennen die een bedrijf rondom ICT gemaakt heeft om een mening te kunnen vormen - zeker als mensen gaan veroordelen dat ze zaken niet voor elkaar zouden hebben.
De persoon waar je op reageert begon over ‘Geo-redundant’ (dat vertaal ik naar je redundantie op fysieke afstand regelen)

Ik oordeel niet, maar ik zou van grotere organisaties verwachten dat ze ook rekening houden met geografische afstand, wanneer ze keuzes maken voor rekencentra.

Voor hetzelfde geld is het gewoon domme pech. Dat kan natuurlijk ook 😊
Na de uitwijk niet meer, want terug zal niet snel meer kunnen
Zonder meer informatie is dat lastig te concluderen. Als er - voor dit soort situaties - een secundair datacenter bedacht is met beperkte (hoognodige) capaciteit kan het he,lemaal volgens de gekozen gedachte functioneren.
Ik heb die discussie ook wel eens als CISO van de opdrachtgever gehad met de CISO van een datacenter in zeer bedrijfskritische toepassingen. Als je in je eentje uitwijkt werkt het allemaal perfect, als je met honderden tegelijk komt, dan is het een groot drama.

Als iedereen dezelfde uitwijkoplossing heeft en alles ook uit moet/wil uitwijken, dan is het makkelijk. Maar als je delen moet omzetten, of moet wachten op een opdracht tot uitwijk (geen automatische failover) dan wordt het lastig. Een probleem is dat je mogelijk netwerkroutering moet aanpassen (BGP-achtige situaties) en zeker als heel veel klanten individueel om moeten betrokken afdelingen hun normale werkplek kwijt zijn (want ontruiming pand) en heel veel uitzoekwerk hebben. Je komt dan in een rij te staan die gewoon tijd gaat kosten.
Niet alle klanten willen redunantie, althans, niet als ze er voor moeten betalen.
Toen ik nog bij MinEZK werkte was het redudante datacenter constant een punt van discussie, want het snoepte wel veel kosten op.

Tot een keer het primaire datacenter een paar dagen onderuit ging, alle kosten waren ineens wel verantwoord.
Herkenbaar! Denk dat we meer en meer zullen zien dat partijen voor redundantie gaan samenwerken. Dat is lastig voor partijen met een winstoogmerk, maar bijv. waar jij hebt gewerkt kan best samenwerken met allerlei andere organisaties. Maar goed het kost wel tijd en kennis om zoiets van de grond te krijgen.
Redundatie is uiteindelijk altijd een kwestie van geld. Doorgaans kost een dubbele omgeving meer dan het dubbele aan geld. Er is namelijk ook nog extra spul (software, hardware, beheer) om de twee kanten aan elkaar te knopen. Regelmatig is dat het geld niet waard. Totdat de boel down gaat en niet meer hersteld kan worden. Dan is dat het met terugwerkende kracht ineens wel waard.

Vooral organisaties die door belastinggeld worden betaald hebben daar last van. Het kost altijd teveel en als het kapotgaat dan wordt gemopperd dat het beter had moeten worden gebouwd.

Iets met achteraf en een koe z'n k*nt.
Ik ben ook werkzaam bij een ZBO (ook een vrij grote) en ook ik mocht inpakken en van het zonnetje gaan genieten. Het was zelfs de vraag of we morgen wel weer up zouden zijn.
Wat is een ZBO? Een "Zeer Bijzondere Onderneming"?

Om te kunnen reageren moet je ingelogd zijn