Onderwerp: SIDN maakte geen backup voorafgaand aan mislukte database migratie

De SIDN had voorafgaan aan het uitvoeren van de database migratie vorige week zaterdag geen snapshot (backup) gemaakt van de database van het .nl-domeinregistratiesysteem. Dat blijkt uit het verslag dat de SIDN over het onderhoud aan .nl-registrars heeft gestuurd. Toen de database migratie mislukte bleek er enkel een backup beschikbaar te zijn van 5 dagen ...

Source: ispam.nl

“Informatie over hoe vaak precies geven we niet aangezien dat onze interne bedrijfsvoering betreft.”

Wat is stelletje prutsers. Echt geen woorden voor. En dan ook de zin hierboven. Waarom zou je niet kunnen vertellen hoevaak je een backup maakt.

Dat de meest recente backup van 5 dagen terug is zegt genoeg... Zeker voor een organisatie als deze moeten gegevens snel terug gezet kunnen worden. En dat ze geen backup gemaakt hebben voor de werkzaamheden zegt ook iets over de professionaliteit binnen het SIDN.... Waar gaat dat geld naar toe??

Als je dit combineert met de berichten over de uitbreidingsdrang van SIDN, kan ik niets anders concluderen dan mismanagement. Buiten het feit dat SIDN zich enkel met zijn kerntaak bezig zou moeten houden, wordt die kerntaak ook nog eens dramatisch slecht uitgevoerd.

Moeten we niet eens een brandbrief naar de politiek sturen? Dit zijn risico's voor de hele nederlandse samenleving. Als de DNS servers er op 1 of andere manier uitliggen (door bijvoorbeeld een fout van een medewerker), kan het blijkbaar wel een paar uur duren voordat de .nl websites weer bereikbaar zijn (met een flink inkomsten verlies voor veel bedrijven).

Hier zitten we in Nederland niet echt op te wachten.

Dat mismanagement is al jaren aan de gang bij de SIDN, daarbij komt dat ze gewoonweg schijt hebben aan de leden zij maken zelf wel de dienst uit en als je het er niet mee eens bent stap je toch op!

Deze autonome club doet gewoon waar ze zelf zin in hebben.....

Dit is van de mailwisseling kort na de storing. Ik was benieuwd naar de reactie van het SIDN en waarom ze voor deze werkwijze gekozen hadden.

Allereerst onze excuses voor het ongemak wat u ondervonden heeft als gevolg van de onderbreking van de productie afgelopen weekend. Wij betreuren deze situatie zeer.

Onze reguliere onderhoudsvensters plannen wij doorgaans op dinsdagen en vroeg in de ochtend met een eindtijd rond 8.00 uur. Het onderhoud van afgelopen zaterdag betrof echter een veel ingrijpender onderhoud, met een langere doorlooptijd. Om die reden is er uitgeweken naar een zaterdag. Wij kiezen daarbij voor een moment waarop de activiteit in onze systemen het minst hoog is. In tegenstelling tot wat u wellicht verwacht ligt dit moment niet in de nacht.
Tijdens het onderhoudsvenster wilden we een flinke stap zetten naar het mogelijk maken van ‘side-by-side deployment’ met als doel het aantal toekomstige onderhoudsvensters drastisch te beperken en ook de doorlooptijd te verkorten. Dit was ook een van de redenen waarom ervoor is gekozen om tijdens het onderhoudsvenster alles in het werk te stellen om Oracle DB 11g succesvol uit te rollen. Helaas zijn we hierin niet geslaagd en zal er nogmaals een onderhoud ingepland moeten worden om de upgrade uit te voeren.

Als reactie de vraag gestuurd waarom ze alleen technisch hiernaar gekeken hebben en niet functioneel met het plannen van onderhoud (dus dat ze bij het plannen rekening houden met de gebruikers ipv de systeem belasting). Het antwoord hierop was dit:

SIDN plant haar onderhoudsvensters weloverwegen en heeft over haar onderhoudwerkszaamheden nauw contact met de Vereniging van Registrars. Een onderbreking van de productie is nooit natuurlijk nooit prettig en de kans is groot dat het geplande moment niet voor alle belanghebbenden gunstig uitkomt, welk moment er ook gekozen wordt voor het onderhoud. We streven er daarom naar de impact van onderhoudsintervallen zoveel mogelijk te beperken.

Zoals in mijn eerste e-mail aangegeven had dit onderhoud een grote verbetering voor toekomstig onderhoud moeten brengen. Jammerlijk genoeg is deze uitrol mislukt waardoor op korte termijn wij minimaal nog 1 keer langere tijd onbereikbaar zullen zijn waardoor er geen mutaties in de .NL zonefile kunnen worden doorgevoerd en de Whois niet bereikbaar zal zijn.

Maar goed in dit geval was het ook overdag plat geweest...

Is het al duidelijk waarom er geen snapshot is gemaakt vooraf de database migratie?

In het artikel staat dat het een gevalletje van 'oeps vergeten' was.

Ik denk ik maak de tekst even wat groter.

“Het ontbreken van de snapshot kan hierbij worden aangemerkt als een nalatigheid in de gehele procedure welke bij een migratie verwacht mag worden.”

Ach ja, wat maakt het uit als je toch geen concurrentie hebt...

Ze maken zich hiermee totaal belachelijk, zeker in verhouding tot deze uitbreidingswaanzin: http://www.nu.nl/internet/2990400/si...eem-maken.html

Had SIDN voor dit soort gevallen niet een redundant cluster gebouwd een jaar of 2 terug?

(staat me ergens iets van bij, maar weet niet meer de ins and outs)

Zo goed ken ik de mensen bij SIDN niet maar dit zijn zulke basisfouten dat er iemand zijn baan zou moeten verliezen daar. Als ze het zelf niet kunnen waarom niet iemand inhuren voor zo'n migratie?

Ze hebben geld genoeg.

Hmmm..... zijn we niet lichtelijk aan het overdrijven allemaal? Ik heb het op ispam ook al gezegd, waar gewerkt wordt maken mensen fouten. It is part of the job. Als er échte ITers in dit topic zitten die nog nooit een screwup hebben gemaakt durf ik te zeggen dat je of liegt... of geen echte ITer bent.

Amazon, KPN, ING..... allemaal bedrijven met IT budgetten die een veelvoud van de SIDN begroting zijn en óók fouten maken. Kom op zeg.... Ik waardeer de openheid van SIDN. Ze hadden zich er makkelijk van af kunnen doen als genoemde partijen en het op een technische storing kunnen gooien. Nee, deze openheid zorgt er voor dat de SIDN zichzelf scherp stelt en zo'n fuckup niet zomaar weer zal maken omdat dat domweg niet uit te leggen is. Er zijn zooooooveel hostingbedrijven die het maar op een DDoS gooien als ze een storing hebben.

Amazon AWS plat door foutje ontwikkelaar:

http://webwereld.nl/nieuws/112910/op...ons-cloud.html

KPN backup platform weken plat:

http://tweakers.net/nieuws/81660/her...ereikbaar.html

Volledige zakelijke klantenbestand van ING die geen betaalverkeer meer kan doen:

http://tweakers.net/nieuws/87174/zak...-update-2.html

Gek he? Je zou bijna zeggen dat we in de IT werken waar een storingsvrije historie niet (nooit) bestaat!