Leveringsprobleem voor onderdeel vertraagt herstel datacenter in Almere na brand

Het herstel na de brand in het datacenter van NorthC in Almere duurt langer dan het bedrijf eerst inschatte. De oorzaak is een leveringsprobleem voor een component voor een nieuwe, tijdelijke stroomvoorziening. Klanten kunnen naar verwachting woensdag hun systemen weer inschakelen.

Afgelopen vrijdagmiddag gaf NorthC nog aan dat het een hersteltermijn van 72 uur verwachtte. De reden voor de vertraging is een leveringsprobleem voor 'een kritieke component', meldt NorthC in een persverklaring. Dat onderdeel is nodig om de stroomvoorziening voor het datacenter redundant te herstellen.

Het bedrijf verwacht de component dinsdagochtend in Almere, waarna 'de technici direct met de installatie en aansluiting' starten. NorthC bouwt de nieuwe stroomvoorziening direct redundant op, zodat het 'op een later moment' zonder extra onderbrekingen kan overschakelen naar het reguliere stroomnet.

Mogelijk eerder

De tijdelijke, redundant uitgevoerde stroomvoorziening komt pas woensdagochtend 'uiterlijk woensdagochtend 13 mei om 12.00 uur' beschikbaar voor klanten van het datacenter. Mogelijk wordt dit dus eerder. "Wij begrijpen dat deze vertraging impact heeft op de operaties van klanten en betreuren dit ten zeerste. Onze teams werken dag en nacht door om het herstel zo snel mogelijk te realiseren", verklaart ceo Alexandra Schless.

Datacenter Almere. Bron: NorthC

Reacties (80)

[peperbus]

Ik stond er eigenlijk nooit bij stil, maar als je in de krant leest hoeveel instanties die getroffen zijn door de brand.... Best wel kwetsbaar, een goede back-up zou niet verkeerd zijn.

[Pietopdeheuvel]

het is maar wat de klant wil uitgeven. Heel kort door de bocht

1. Een RAID configuratie die voorkomt dat je data weg is wanneer er een schijf crasht,
2. Het regelmatig draaien van backups
3. Het regelmatig draaien van off site backups
4. Continue backup, al dan niet off-site (spiegelen van data)
5. Backup hardware die wordt gebruikt als fail safe voor wanneer de productie faalt en bv gebruikt wordt voor testen wanneer productie gewoon draait, al dan niet off site (in een ander datacenter)
6. Hardware die in hot standby draait met actuele data
7. Productie verdelen over twee of drie datacenters die dan in load balance draaien en data die ook, net als bij een RAID systeem verdeeld staat over meerdere DC en up to date wordt gehouden
   
   Hoe redundanter, hoe duurder en complexer. Hebben we het nog niet over de stroomvoorziening en batterij backup, glasvezel verbindingen tussen de DC die ook redundant kunnen zijn, van verschillende leveranciers en die op verschillende plekken het gebouw in gaan, en gescheiden liggen van elkaar (dus niet in dezelfde goot). Je moet dan ook rekening houden dat volledig synchroon zijn bij miljoenen transacties niet 100% lukt omdat je zit met afstand en er een beetje vertraging daardoor is.
   
   Allemaal mogelijk en nog meer.
   
   Maar de realiteit is maar al te vaak dat men kiest voor housing (dus alleen maar een eigen server in het DC zet, en stroom, koeling en netwerk huurt). Wanneer het dan misgaat wordt men boos op de DC leverancier. Allemaal meegemaakt, jaren in die industrie gezeten, aan beide kanten van de tafel.

[BvdW1978]

Precies deze boodschappenlijst is enorm complex en duur om te regelen. "Been there" voor een stukje betalingsverkeer. Als je dan thuis op de bank eens bespreekt wat zoiets kost, dan is de eerste reactie verbazing over hoe duur zoiets moet zijn. Tot je uit uitpelt in alle lagen die stuk voor stuk heel goed bestand moeten zijn tegen uitval.

Helaas ook binnen mijn werk moet ik nog te vaak uitleggen dat je SLA's moet stapelen. De ketting is uberhaupt maar zo sterk als de zwakste schakel, maar de faalkansen vermenigvuldig je ook met elkaar. Dat idee landt maar heel zelden.

[gooos]

Eruit liggen met je business en je daarvoor verzekeren is ook enorm duur - nog los van de reputatieschade.

Hoe meer je in je bedrijfsvoering je afhankelijk bent van data des te meer moet je investeren in zaken als High Availability (HA), Disaster Recovery (DR) en combinatie van deze 2. Hoe en in welke mate je dat doet is ook enorm afhankelijk van het type bedrijfsproces en de impact wat ermee gepaard gaat.

[WargamingPlayer]

Valt best wel mee. Wij zijn ook plat gegaan maar draaien gewoon door. We hebben VSAN en HPV+S2D draaien. We zaten ook gewoon naar de rook te kijken terwijl onze infra door draaide in het andere DC van NorthC. Tot iemand opmerkte toen ik op kantoor kwam, weet je dat jullie tweede DC er uit ligt? Dus was geen stress hier. Op dubbel core netwerk na, heb je niks anders dan een paar extra spullen nodig. Zou je bijvoorbeeld een 3 node ESX cluster hebben, dan bouw je gewoon een 4 node, met 2 hosts in A en 2 in B. Omdat je sowieso altijd al op 75 tot 80% piek draait heb je gewoon geen last van even 2 hosts weg. Je moet tenslotte ook patchen. En hoe groter je aantal hosts, hoe minder redundante extra’s je nodig hebt, met uitzondering van netwerk switches, routers en firewalls. Daarnaast cross-site backup. Dus backups van site A worden gedaan op Site B en andersom. Ik vermoed dat die extra investering al lang terug was verdiend.

[Reactie gewijzigd door WargamingPlayer op 12 mei 2026 14:56]

[Archcry]

Een RAID configuratie die voorkomt dat je data weg is wanneer er een schijf crasht

Dit is niet waar RAID primair voor bedoeld is. RAID is geen backup-oplossing. Het doel van RAID is vooral beschikbaarheid/uptime (en afhankelijk van het type ook performance). Als een schijf uitvalt, kan het systeem in degraded state blijven doordraaien op de overgebleven schijven.

[Reactie gewijzigd door Archcry op 11 mei 2026 16:46]

[Pietopdeheuvel]

Je zegt precies hetzelfde wat ik schrijf, en ja, een raid heeft ook andere voordelen.

[jp]

Goede back-up is in deze waarschijnlijk het probleem niet, dat is (vrijwel) niet verloren gegaan. Maar als je wel je data hebt, maar geen infra hebt om die op te draaien, heb je alsnog niets.

[RobertMe]

Dat ligt natuurlijk aan wat @peperbus met backup bedoeld. Een data backup, een backup server, een backup locatie, .... Als je redundantie over twee DCs heb je dus ook, als het goed is ingeregeld, een backup als een DC niet meer functioneert.

[RSH]

Echter moet je dan wel weten welk deel van je services op die ene locatie kan draaien. Ik zie helaas vaker dat bij situaties waarbij 2 (of meer) DC’s actief zijn niet of onvoldoende duidelijk is welk deel critical is, en welk deel “nice to have” maar tijdelijk misbaar. Er van uitgaan dat capaciteitsverlies door wegvallen van één locatie volledig overgenomen kan worden door (een) andere DC(‘s) is meestal niet realistisch, volledige redundantie in capaciteit is vaak niet de realiteit.

Als dan ook onderlinge afhankelijkheden niet of onvoldoende bekend zijn, waardoor het “een uitdaging” wordt slechts dat deel waarvoor op resterende DC capaciteit is, aan te zwengelen wordt het helemaal leuk.

[Skywalker27]

Hangt er vanaf we hebben zelf meerdere DC's maar daarvan staat er altijd 1 uit z'n neus te eten bewijze van spreken.

[Baardmeester]

Kan er niet iets van load balancing op?

[locke960]

Dat kan, dan benut je je resources heel efficiënt, maar dan loop je het risico dat als een DC uitvalt, je op dat moment te weinig resources hebt.

Dat hoeft geen probleem te zijn, maar dat is situatie afhankelijk. Dat is ook geen IT vraag, maar een business vraag.

Feit is, als high availabilty een eis is dan zul je heel veel werk moeten leveren voor je überhaupt beslist dat je meerdere datacenters nodig hebt.

Continuiteit, backup/restore, RPO, RTO, disaster recovery en noodplannen zijn geen "IT zaken". Dat zijn business zaken waar de IT maar één onderdeel van is. (Ik heb lang geleden serieus vragen gehad over hoe snel we nieuwe hardware, PCs, printers, LAN, WAN, etc, kunnen leveren als het gebouw afbrandt, omdat ze de klant beloofd hadden binnen 2 weken weer operationeel te zijn.

De vraag hoe snel ze een ander gebouw konden regelen konden zie niet beantwoorden.

[Skywalker27]

Precies dat, wij hebben gewoon een gebouw paraat met complete uitwijk, vanwaar de hele NL IT afdeling kan opereren incl. extra call center indien nodig. Word het hele gebouw nu niet gebruikt? Nee nu houden ze er cursussen en BCP oefeningen.

[Skywalker27]

Nee net zoals met Airco's N+1 betekend dus altijd i.i.g. 1 Idle.

[Polderviking]

Datacenter locaties redundant uitvoeren in het geval van dit soort bizar onwaarschijnlijke scenario's hangt wel een heftig prijskaartje aan.

[DjoeC]

Zo bizar onwaarschijnlijk is dit niet (meer). Denk ook aan nieuws: Brand verwoest datacenter van Franse provider OVHcloud en er zullen er vast meer geweest zijn.

Naarmate er meer datacentra komen die meer stroom verbruiken zal de kans op incidenten alleen maar toenemen. Ik heb werkelijk geen idee met welke risicopercentages gerekend wordt maar als jouw infra (denk ziekenhuis of zelfs huisarts) afhankelijk wordt van het al dan niet beschikbaar zijn van 1 van vele partijen in de keten (software, hardware, power) zou ik me eens flink achter de oren krabben.

Ik zou van een dienstenprovider zoals die waar huisartsen gebruik van maken verwachten dat ze een "binnen x uur weer beschikbaar" garantie geven, waarbij x eerder 2 of 3 uur zou moeten zijn dan langer. We worden steeds afhankelijker van 100% uptime.

[Nox]

Zat leveranciers waar wij 8 uur hersteltijd hebben in de sla's. Puntje bij paaltje als er een groot incident is als dit is het: Eh ja, die gaan we niet halen, einde mededeling. Beloftes en garanties zijn slechts letters op een papiertje. De praktijk is gewoon anders.

[Polderviking]

Ik zeg ook niet dat het niet moet gebeuren, maar toch is niet elk systeem is zomaar van levensbelang, of zijn de kosten van een paar dagen downtime dusdanig dat je alles zomaar even dubbel wil uitvoeren.

Overigens kan je ook wel wat vinden van die groeiende afhankelijkheid.
Ik stoor me er bijvoorbeeld groen en geel aan dat als specifieke systemen in storing raken, de NS gewoon HELEMAAL niet meer rijd.
En dat is meer vanuit een "hoe ging dat vroeger dan" perspectief dan dat ik me afvraag hoe het kan dat zo'n systeem er uit kan liggen.

[Reactie gewijzigd door Polderviking op 11 mei 2026 15:29]

[BvdW1978]

Vroeger was de treinenloop lang niet zo intensief als nu en gingen er ook niet zoveel verschillende vervoerders over ons enorm drukke net. Ze stoppen er bij NS echt niet zomaar mee als er een keer een servertje op z'n achterste gaat.

[SJCE]

Hoezo bizar onwaarschijnlijk? AWS UAE en Bahrain zijn nog niet weer operationeel, en ik zie nog niet zoveel datacenters die goed bestand lijken tegen drone aanvallen.

[Polderviking]

Hoezo bizar onwaarschijnlijk?

Hoeveel datacentra hebben we onderhand op deze planeet, en bij hoeveel is er de afgelopen 20 jaar zo'n kreupelmakende brand uitgebroken?

[SJCE]

De vraag is in hoeverre behaalde resultaten uit het verleden wat zeggen over de toekomst

[_Pussycat_]

Ik neem aan dat met de herrie en vervuiling van AI-datacenters er ook aanslagen op datacenters zullen komen. In Frankrijk branden dingen nogal snel.

[Sorcerer8472]

De vraag is of dat prijskaartje hoger is dan de gevolgschade die ze nu lijden.

[klakkie.57th]

Jij noemt dit bizar onwaarschijnlijk, ik noem het gewoon je zaakjes op orde hebben. de meesten denken gewoon iemand zal het wel voor mij oplossen … niet dus.

Redundant datacenters hoeven niet extreem duur te zijn, alle load verdelen over 2dc’s dan heb je hooguit een vermindering van je performance als er eentje wegvalt en kun je minder belangrijke servers/diensten uitschakelen
En als je ziet welk soort ondernemingen er geraakt zijn, dan kan Ik enkel zeggen dat universiteiten hier echt wel het geld voor hebben om een paar redundante 10 gbit lijnen te voorzien tussen datacenters met ieder een eigen breakout met bgp routers met een eigen iprange.

is dit alles nog te duur dan ga je gewoon over op diensten van Microsoft /amazon / … en wordt georeplication helemaal bereikbaar voor de gemiddelde it verantwoordelijke

[Reactie gewijzigd door klakkie.57th op 11 mei 2026 16:55]

[MeNTaL_TO]

Kosten-baten verhaal, het is best prijzig om alles redudant uitgevoerd te krijgen, bovendien was dit ook best wel een uitzonderlijke situatie.

[Cybje]

Dat ligt eraan wat je als RTO wilt. Een near-instant failover is vaak duur inderdaad, maar als je bijv. een RTO van 10 minuten accepteert hoef je alleen maar data te repliceren naar een ander datacenter, terwijl compute uit kan staan tot het nodig is. Ik snap dat dat overkill is voor de website van de lokale voetbalvereniging, maar voor organisaties als Universiteit Utrecht en de KvK moet dat echt geen probleem zijn.

[glennoo]

Je verteld dit alsof data "eventjes" overgepompt is in 10 minuten. En ja, de hardware kan uit staan maar als je verder wilt draaien op vergelijkbare hardware dan heb je dus ook kosten voor de aanschaf van die hardware. Een hosting partij gaat ook niet dubbele hardware aanschaffen, dan een gedeelte uitzetten en zeggen "nee prima, daar rekenen we niks extra's voor want het draait niet".

[Cybje]

Ik heb het over replicatie van data. Je moet natuurlijk niet ineens je data willen overpompen in 10 minuten, maar je kunt wel replicatie actief houden. En ja, daar betaal je voor, maar zoveel kost dat nou ook weer niet. Het wordt vooral duurder naar mate je sneller weer online wil zijn. De meeste klanten die ik spreek en waar ik naar de RTO vraag, zeggen dat het direct moet. Om daarna dus helemaal geen redundantie tussen datacentra te kiezen, omdat het te duur is. Dan denk ik: accepteer dan gewoon een RPO van bijv. 10 minuten, dan ben je een stuk beter af.

En partijen die cloud diensten aanbieden, ook Nederlandse partijen die vanuit dit soort datacentra opereren, kunnen prima voldoende hardware neerzetten. De ene klant wil primair in Almere draaien en secundair in bijv. Schiphol-Rijk, de andere klant precies omgekeerd. Dat is prima te managen met enige overcapaciteit, zonder dat de prijzen echt idioot hoog worden.

Ik zeg ook niet dat ze niks moeten rekenen, want dat is hoe jij het nu ineens leest. Ik zeg alleen dat het niet perse zo duur hoeft te zijn als organisaties denken.

[foobar79]

En partijen die cloud diensten aanbieden, ook Nederlandse partijen die vanuit dit soort datacentra opereren, kunnen prima voldoende hardware neerzetten. De ene klant wil primair in Almere draaien en secundair in bijv. Schiphol-Rijk, de andere klant precies omgekeerd. Dat is prima te managen met enige overcapaciteit, zonder dat de prijzen echt idioot hoog worden.

Je vergist je enorm in de complexiteit hiervan.
Als de klant op zijn eigen hardware en storage wil draaien zal je bv de boel moeten her-bekabelen zodat de servers bij de storage kan. Vervolgens moet de boel nog geinstalleerd worden etc. Dan ben je zo daaagen verder zonder 100% zekerheid dat het gaat werken als het een beetje complex is. (want dit scenario regelmatig testen zal niet meevallen)
En dan heb je het over 1 klant/bedrijf, nu moeten ineens alle klanten van dit DC dat gaan doen.

Als je het over een volledig managed oplossing hebt dan moet de hoster toch echt volledige capaciteit van het verloren DC ergebs beschikbaar hebben.
Bij 2 DCs is dat 100% extra bij 3, 50% extra, dan heb je het over flinke bedragen.
Pas bij 11 DCs heb je het over 10% maar dan heb je het al over een enorme omgeving met ditto complexiteit om te zorgen dat de juiste plekken naar naar de juiste plekken synchroniseren en over gaan (en vervolgens moeten de klanten ook precies netjes verspreid zijn).

[koppie]

Dan bezie je het nog vanuit de hardware kant. Het goed backuppen, en wegschrijven van live journaalmeldingen van bijvoorbeeld een database is echt geen sinecure.

Want vrijwel elke dienst/applicatie zit in een keten, en als een andere partij al iets van jou heeft ontvangen, wat jij zelf nog niet hebt gecommit in je backup maakt het werkelijk weer opstarten van je applicatie eigenlijk heel gevaarlijk...

[klakkie.57th]

Sorry maar dit doen bedrijven al jaar en dag , dat is echt geen hogere wiskunde ofzo, misschien voor een KMO maar echt niet voor een universiteit of KvK …

En als je het echt niet zelf kan dan ga je naar Microsoft/Amazon en neem je diensten af en zet je geo-replication aan.

[foobar79]

Sorry maar dit doen bedrijven al jaar en dag , dat is echt geen hogere wiskunde ofzo,

Mijn punt was dat dit niet tegen geringe meerkosten kan. Die setup kan je namelijk niet ad-hoc bouwen als het nodig is maar de capaciteit zal echt ergens klaar moeten staan, “ready to go”. Ja alles voorbereiden is goed mogelijk maar dus niet goedkoop.

Ook als je voor een Amazon/Azure kiest zal je de capaciteit moeten reserveren (dus duur). Deze partijen hebben namelijk ook niet voldoende capaciteit om als er een grote outage is alle workloads ergens anders te starten. Als je dan nog geen CPUs etc hebt loop je een flinke kans dat ze het niet hebben als nog 1000-en andere klanten precies hetzelfde proberen.

[Nox]

Als jouw klanten aangeven instant failover te wensen, geef je dan niet aan dat dat voor die toepassing/organisatie niet de juiste optie is en iets met een kleine downtome veel goedkoper en beter past?

Wij zitten in een iets andere branche, ik geef altijd aan dat een redundante verbinding 3-4 keer zo duur is. Immers heb je punt een, de dubbele infra. Punt twee, de integratie van het geheel. Punt drie de dubbele infra is vaak op een andere locatie waardoor afstanden e.d. groter worden en de vereiste om niets naast elkaar te leggen maakt het complexer zodat die infra duurder is. Niet altijd het geval, maar vaak wel.

Het alternatief is dat de backup bestaat uit eenzelfde dienst bij een andere partij maar dan voor consumenten en een wat goedkoper abonnement, de kans dat de concurrent en wij door dezelfde brand getroffen worden is zo klein dat als dat gebeurt er wel meer aan de hand is.

Voor mezelf heb ik gewoon besloten dat als het kapot gaat ik er maar mee leef; de kans is klein en het ongemak beperkt. Ik werk zelf in de industrie, bewust zijn ervan scheelt al veel.

[Reactie gewijzigd door Nox op 11 mei 2026 16:02]

[RiDo78]

Wie zegt dat een hostingpartij dat moet doen? Sterker nog, daar heb je vaak helemaal niets aan als het op een grote calamiteit aan komt. Als er meerdere klanten getroffen zijn, gaan ze eerst kijken naar hun eigen infra, dan naar de best betalende klanten en uiteindelijk de klanten die niet de middellen hebben om dure en uitgebreide omgevingen neer te zetten. En ook de hardware-leveranciers hebben maar beperkte voorraad, dus die gaan ook hun prioriteiten stellen. Als er in Almere 5000 IBM-servers zijn afgefikt dan duurt het wel even voor IBM die allemaal kan vervangen.

Nee, mijn inziens moet je het toch zélf op een slimme manier oplossen. En de offsite-backup is natuurlijk al genoemd. Maar je hebt inderdaad hardware nodig om alles op te laten draaien. En als de verantwoordelijke managers niet een paar hersencellen te weinig hebben dan is die vaak wel voorhanden in de vorm van een non-prod omgeving.

Want in een beetje professioneel bedrijf heb je een development-lifecycle ingericht. Development gebeurt in een DEV omgeving, de primaire tests in TST, dan gaat het door naar de 'User Acceptance Test' (UAT), eventueel naar een pre-productie om uiteindelijk naar productie te gaan. Waarbij productie en pre-productie fysiek los staan van de andere omgevingen. Bij een calamiteit in productie is vaak de eerste prio om die weer online te krijgen. Heb je het geluk van een pre-prod of disaster-recovery omgeving, dan kan het overschakelen vrij rap gaan; de software staat er al en in het geval van DR de data ook. Bij DR hoef je vaak enkel de mirror te verbreken en de replicatie (indien mogelijk) om te draaien, VM's te starten en je kunt weer verder. Bij een pre-prod omgeving zul je de productie-storage of diens mirror misschien nog even beschkbaar moeten maken en je bent ook relatief snel terug. Maar heb je geen pre-prod of DR, dan is het te hopen dat je je storage(mirror) beschikbaar hebt op de locatie van je non-prod omgevingen. Dan is het daar de non-prod down brengen en de productieomgevingen opzetten. Dat kost serieus meer tijd.

Ik heb in verschillende bedrijven een uitwijk (test) meegemaakt en er komen altijd zaken boven drijven die je niet had verwacht. Even een paar voorbeeldjes / lesjes:

• DNS: De primaire DNS-server van productieservers staat doorgaans... bij diezelfde productieservers op dezelfde hardware. Fikt die site eruit, is de primaire DNS-server ook weg. Staat de secondaire DNS-server ook op diezelfde plek? Bad luck... succes met het resolven van je management-portals. Staat de secondaire server op een secondaire site, dan kan alles wel werken maar moet je rekening houden met vertragingen. Immers, de servers gaan vaak eerst de primaire DNS-server proberen voordat ze naar de secondaire overgaan. En natuurlijk zijn er altijd appliances (vaak ingericht met handwerk ipv. automation) die enkel de primaire DNS-server kennen. Les: als het netwerk van de primaire DNS-server niet gestretched kan worden zodat hij eenvoudig naar de andere kant kan, zorg dan aan de uitwijkzijde voor een non-routable netwerk waar de secondaire (of andere) DNS-server hetzelfde IP-adres krijgt als de primaire. Bij een productiecalamiteit laat maak je dat netwerk routable binnen je uitwijkomgeving. Zo komt er snel een DNS-server terug op het oorspronkelijke IP-adres.
• IP-adressen: Als een van de locaties uitvalt, vallen ook alle netwerksegmenten weg die niet gestreched zijn. Applicaties of componenten die voor hun afhankelijkheden naar IP-adressen kijken zullen na het uitwijken niet werken als ze die IP adressen niet kunnen bereiken. Ook als ze via DNS verbinden werkt het niet zomaar. Les: Zorg dus dat je die netwerksegmenten snel terug online krijgt op de uitwijk of beter nog, zorg dat ze er al zijn zonder dat er routes naartoe lopen. Kun je dat niet? Zorg dan dat je DNS-tooling hebt om bulk-mutaties te kunnen doen. Dus alles van 10.<prod>.x.y naar 10.<uitwijk>.x.y.
• Active Directory: Gaat doorgaans prima, merk je niets aan.... totdat blijkt dat de DC met de PDC-emulator FSMO-rol weg is. Dan kun je geen wachtwoorden meer aanpassen en moet je lang wachten wanneer je een fout wachtwoord hebt ingevoerd. Les: zo snel mogelijk die (en andere FSMO-rollen) controleren overzetten; eventueel met uitzondering van de RID-master.
• VPN: Leuk die remote-access / thuiswerken. Maar waar komt die VPN binnen? In de afgefikte productielocatie? Auch! Les: Ook een toegangspunt inrichten op de uitwijklocatie en de clients juist configureren.
• Hypervisor: Die heb je natuurlijk nodig om VM's alle kanten op te schoppen. Maar zou je die wel op je productielocatie willen hosten? Als non-prod/uitwijk uitvalt heb je tijd om die over te halen naar productie. Maar als productie wegvalt? Dan wil je hem meteen kunnen gebruiken. Hetzelfde geldt ook voor je deployment-omgeving. Les: Overweeg om alles wat niet direct productie is maar wat je bij een productie-calamiteit wel snel nodig hebt standaard uit te wijken. Denk ook aan je hypervisor-VM bijvoorbeeld. Als je non-prod weg valt heb je waarschijnlijk tijd zat om die naar productie te halen. Maar als productie weg valt... En gebruik je DHCP/BOOTP voor je deployments? Zorg dan dat de DHCP-agents op de routers goed staan voor zowel de productie als de uitwijk of dat je ze snel kunt aanpassen. Les 2: Zorg dat je altijd weet WAAR en op WELKE HOST (of subset van hosts) de hypervisor staat. Zodat je deze handmatig kunt (her)starten als het nodig mocht zijn. Je wilt niet op 25 hosts inloggen om er uiteindelijk achter te komen dat de hypervisor heel ergens anders staat.

Zo kan ik nog wel even doorgaan. Want naar mijn ervaring kun je het nog zo mooi beschrijven en in procedures proberen te vatten, maar uiteindelijk is het toch de wetten van Murphy's die blijven gelden. De enige manier om de schade van Murphy te beperken is door regelmatig te testen. Helaas hebben veel managers last van koud-watervrees en moeten ze eerst in het diepe gesmeten worden voordat ze daar ook maar aan durven denken. Want stel je voor dat productie er periodiek gepland en gecontroleerd op zondagmorgen om 3 uur er even een half uurtje uitgaat... Terwijl er geen betere uitwijk-leerschool is dan dat.

[itsupportfellow]

Ik ben er niet mee eens, maar ik ga je bericht ook niet lezen.

[Baardmeester]

Voor organisaties als de Universiteit Utrecht en de KvK is de RTO ook weer van een andere orde dan van een ziekenhuis of bank. Zolang er geen levensbedreigende situaties of direct miljoenen verloren gaan zal er gewoon een berekening van kosten en kans worden gemaakt en vaak wel voor een hogere RTO worden gekozen.

[sjimmie]

Dat is voor KVK moeilijker dan je zo denkt. Als er data kwijtraakt die cruciaal is voor internationale handel dan kan het al snel in de miljoenen lopen. En vergeet niet dat banken ook gebruikmaken van KVK data. Wel is veel van die data reproduceerbaar. Maar inderdaad nog wel anders dan "levensbedreigend". Gelukkig lag KVK maar amper 2 uurtjes gedeeltelijk eruit en is er sowieso 0 dataverlies. Alleen een gedeeltelijke onderbreking in de dienstverlening.

[Sluuut]

KVK had al op t.net gereageerd dat ze wel degelijk een redundant datacenter oplossing hadden, maar dat de failover niet 'instant' was en nog veel handmatig werk vereiste voordat alles weer in de lucht was.

Dit laat juist zien dat je minimaal jaarlijks een 'zware' failover test moet uitvoeren (op groot infra vlak, echt stroom laten onderbreken voor al je racks). Dat zijn vaak ondergeschoven kindjes omdat het in theorie op papier wel goed zit, maar in de praktijk toch anders uitpakt en er niet zo snel tijd & effort voor gereserveerd word.

[mocean]

Als KVK weet dat ze best 1 dagje offline kunnen zijn, dan is het toch prima? Het is geen ziekenhuis...

[Sluuut]

Zeker! Ik leg dat verband ook nergens, ik doelde breder dan KVK. Maar natuurlijk ligt het aan de organisatie of dit het waard is of niet.

[sjimmie]

Deze keer minder dan 2 uur en slechts deels. Maar inderdaad kan en mag KVK langer offline zijn.

Vergeet niet dat elke vorm van hogere beschikbaarheid exponentioneel meer geld kost. En laat nou iedereen graag willen bezuinigen op de (semi)overheid.

[Nox]

En dan komt management: 'wat zijn de risico's van deze test?'
engineer: 'de kans is dat alles er meerdere dagen uit ligt en wat dataverlies als we letterlijk de spanning van het rack halen'

Management: doe dan maar niet.

En zo gaat het wel vaker gok ik

[Sluuut]

Hangt natuurlijk wel van het bedrijf af, bijvoorbeeld Netflix of de ING zullen echt wel dit soort half jaarlijkse tests hebben (mag ik hopen).

[Nox]

Dat zijn dan ook bedrijven die een complete schaduwproductie kunnen opzetten met loadtesters om dit te oefenen gok ik zo

[gooos]

Yup - dark room / black building tests sneuvelen nog wel eens onder druk van een onderdeel in het bedrijf wat er echt niet aan wilt maar waar de impact als het eens echt fout gaat dan ook het grootste is... en dan zijn het juist die collega's die het hardst roepen waarom er nooit getest is.

Ze zijn overigens heel snel heel stil als je ze vraagt of de mail met hun bezwaar tegen de test(s) uit je mailbox moet opgraven

[Nox]

Bij ons zijn de onderhoudsmomenten altijd een mooi moment om te kijken of de backup alles overneemt. Gaat het fout: was gepland. Gaat het goed: meevallertje.

[R_Zwart]

Als het goed is is er een risicoanalyse gedaan. En als de uitkomst is dat mitigatiekosten hoger zijn dan de risk exposure, dan heeft het geen om iets aan het risico te doen.

[mgizmo]

Wat ook niet verkeerd zou zijn, is bedenken dat er vast wel over na is gedacht en dat zoals andere al hebben geschreven waarschijnlijk een risicoanalyse ter grondslag aangelegen heeft. Ook daarin wordt meegenomen hoe snel weer up en running is volgens de theorie/sla's leveranciers e.d.

[anboni]

Met back-up in deze context bedoel je natuurlijk redundantie. Dat wordt best snel best duur (als je het goed wilt doen, heb je van alles 2 nodig, servers, storage, netwerkcomponenten, etc wat ook weer extra complexiteit toevoegt) en voor heel veel instanties is iedere vorm van redundantie een kostenpost: het levert tenslotte echt niets op, het is er alleen voor als iets misgaat - net een verzekering.

[FastFred]

Het gaat hier bijna zonder uitzondering om klanten die rackruimte huren en denken 'het staat in een DC dus het kan niet mis gaan' en vervolgens niet nadenken over een uitwijk voor scenario's als dit.

[CPV]

Natuurlijk leveren ze backup mogelijkheden:

Wilt u gebruik maken van uw eigen servers zonder de zorgen van het beheren van een eigen datacenter? Colocatie (colo) in een van onze regionale datacenters biedt de perfecte oplossing. Met onze moderne faciliteiten bent u verzekerd van uw bedrijfscontinuïteit.

Het aan de klant om de financiële afweging te maken of ze het willen inzetten.

[bbc]

Ik stond er eigenlijk nooit bij stil, maar als je in de krant leest hoeveel instanties die getroffen zijn door de brand.... Best wel kwetsbaar, een goede back-up zou niet verkeerd zijn.

Ik ben eens een main data center "verloren" door een beginnende brand. Het Argon gas begon zich te verspreiden, maar dit veroorzaakte enorme trillingen (de uitbater van het datacenter die dempers verkoopt had deze niet op zijn eigen datacenter geplaatst). Bijgevolg waren zowat alle disken in het datacenter stuk.

De fail-over naar het backup datacenter bleek toch niet zo rimpelloos te verloren als disaster recovery tests hadden laten uitschijnen.

Als je een heel datacenter moet vervangen blijkt ook wel dat je next-business-day garantie op vervanging van onderdelen ook niet veel waard meer is. De leveranciers hebben geen oneindige voorraad dure meuk.

Dus ja, zelfs met goede backups kan het zijn dat je heel lang niet aan bepaalde systemen kan.

[Pietopdeheuvel]

Bij een klant van mij ooit een uitvaltest moeten doen, in productie, onze "netwerkspecialist" kwam er toen achter dat ie een gecertificeerde prutser was, was een dag uitval van productie. Vond de klant wat van. Mijn werkgever ook. Hebben kort daarna afscheid van elkaar genomen. De prutser werkt er nog steeds.

[DigitalExorcist]

Je kan toch een offsite backup naar een ander datacenter inrichten? Kost alleen heel veel geld.

[adje123]

Kan gebeuren en het is vervelend voor iedereen! Vind het het eigenlijk al best snel gaan allemaal qua oplossen. Ben blij dat er geen doden of gewonden zijn gevallen .

[kodak]

Dit soort datacenters kies je omdat enkele uren uitval veroorzaakt door een datacenter niet acceptabel zijn. Daarom verkopen dit soort datacenters hun diensten ook als redundant. Meerdere dagen dan geen dienstverlening hebben is dan niet zomaar redelijk. Zeker als de redundantie voor de praktijk niet redundant blijkt te zijn.

Natuurlijk kunnen we ons dan afvragen of brand een bijzondere omstandigheid is om maar bijna een week geen redundantie te hoeven verwachten. Brand is een van de basisproblemen om rekening mee te houden bij gebouwen en helemaal bij stroomvoorziening.

[jongetje]

Als je echt redundant wilt zorg je voor een hot/cold-standy in een 2e datacenter (ergens anders in Nederland/Europa). Maar heb vaak genoeg gezien dat een failover test vaak genoeg niet lukte bij grote corporaties, zelfs niet in binnen een week.

Dan hoop je dat er iig een mogelijkheid toe is en je alles überhaupt weer up and running kunt krijgen. Ik ken inmiddels ook genoeg bedrijven en instellingen die hun cloud omgeving backuppen bij een 3e (europese!) partij. Puur voor als er iets in de cloud omgeving gebeurd je zelf ook nog een kopie van je (eigen) data hebt. Ja, dat kost allemaal geld, maar het kost nog meer als je er weken/maandenlang of zelfs nooit meer bij kunt. Als je daarnaast goed blijft opschonen houd je de kosten ook nog enigszins binnen de perken.

[kodak]

Voor echt geen downtime willen ben ik het met je eens. Maar dit gaat niet om echt geen downtime willen. Het gaat om een verschil tussen enkele uren per jaar en ruim een week bij een zelfde datacenter. Dat is dan een enorm verschil. Ik betwijfel of dit aan de geadverteerde tier3 norm voldoet. Het doel is redundantie te kunnen leveren terwijl het datacenter kennelijk ontworpen is dat als er een te verwachten risico bij het hoofdsysteem is dat ook grote gevolgen heeft voor de 'vervanging' en er zelfs helemaal geen redundantie is en ook nog ruim een week.

[ASx2608]

Wat wel grappig is dat sommige websites waar je Anime kijkt, maar dan niet via de officiele manier ook getroffen zijn, met het verhaal dat hun datacenters ook in brand zijn gegaan, hoogstwaarschijnlijk is het de datacenter in Almere

[asing]

Het onderdeel ligt bij de douane en wordt morgen vrijgegeven....

That's the holdup.

[ikt]

Best fragiel eigenlijk, de digitale infrastructuur. Storinkje hier bij DigiD, brandje daar en een hoop werk wordt opeens moeilijk voor de instellingen die erop moeten vertrouwen.

En dat is met "natuurlijke" oorzaken. Volgens mij kan een kwaadwillende prima een hoog gedigitaliseerde samenleving zoals Nederland vrijwel lamleggen als die dat wil. Drone-aanval hier en daar, andere dienst(en) plat (laten) leggen door (diplomatieke/politieke) kanalen (als deze diensen niet in eigen beheer draaien), en dan heb je in een middagje tot vrij veel ellende gemaakt.

[timoootjex]

Universiteit van Utrecht heeft er ook gevolgen van.

[Power2All]

Werkte de sprinklers en andere beveiligingen uberhaupt ?
Lijkt erop dat er wel meer mankeerde aan die data-center.

[mr_evil08]

Amateuristisch bende, redundantie me reet.

[repmeer]

Ik zou zeggen ga solliciteren bij het datacenter als je het zo goed weet.

[mr_evil08]

Wij hebben gekozen om de zaak te verhuizen naar een datacenter wat wel zijn zaken op orde heeft want dit is contractbreuk.

Inmiddels draaien we weer(we hadden al reeds spullen in een ander datacenter).

Daar hebben ze ook een blussysteem in de facilitaire ruimten.

[Reactie gewijzigd door mr_evil08 op 11 mei 2026 22:10]

[Pietopdeheuvel]

En wat staat er in jullie SLA mbt redundantie, recovery en fail over?

[Rens1967]

De component is correct Nederlands, zoek maar eens op

[zonglew00]

De groene woordenboek even bijplakken voordat je iets gaat reageren en nooit meer terug gaat kijken. Er is een aparte plek voor dit soort zaken, lieve admin knopje.

[jeroen3]

Het is inderdaad "de component" of "het onderdeel". Helaas klinken leenwoorden soms raar.

[cracking cloud]

Component is mannelijk, dus de component is juist (ook al klinkt het vreemd)

[DigitalDr]

"me collega's"
lol. Hoe oud ben je zelf, 17?

[Robbaman]

Of ze doen het expres omdat het gewoon correct is 🤷🏻‍♂️

[Robbaman]

Volgens mij stelde hij:

De component?

man man man

Daar ging het toch over? Aangezien het artikel gewoon "Het bedrijf" bevat, ging ik er vanuit dat dit een foutje van de reageerder was.

[Reactie gewijzigd door Robbaman op 11 mei 2026 13:49]