Kapotte backup leidt tot migratieproblemen bij Web-log.nl

Een door Typepad aangeleverde backup van de bijna 400.000 weblogs van Web-log.nl blijkt niet in orde. Als gevolg daarvan moet de weblogdienst nu handmatig de corrupte delen opsporen en alle blogs naar Wordpress overzetten.

Een groot deel van de blogs op Web-log.nl is al twee weken offline. De downtime blijkt te worden veroorzaakt door een deels corrupt exportbestand met daarin alle blogs. De backup was aangeleverd door Typepad, dat tot voor kort verantwoordelijk was voor de achterliggende blogsoftware, maar zijn diensten aan derden heeft gestaakt.

Hoewel Sanoma, de uitgever van Web-log.nl, ruimschoots op tijd hiervan op de hoogte was gebracht, blijkt het bedrijf niet in staat te zijn geweest om de weblogs tijdig naar de nieuwe Wordpress-omgeving te migreren. In januari wist Sanoma al dat de blogs gemigreerd zouden worden en dat hiervoor tot juni tijd zou zijn. Toen dit niet haalbaar bleek, kreeg de uitgever uitstel van Typepad om de boel in orde te maken. Volgens Sanoma werd dit uitstel echter plotseling ingetrokken, waarna een backup over de schutting werd gegooid en verdere communicatie niet of nauwelijks mogelijk was.

Ongeveer 5 procent van de berichten in het backupbestand is volgens Sanoma corrupt. Hierdoor was een automatische migratie naar Wordpress nagenoeg onmogelijk en moet Sanoma handmatig blogs herstellen.

Het ontwikkelteam werkt nog aan het exporteren van de content naar het nieuwe platform. Een deel daarvan staat al online. Web-log.nl kan niet toezeggen dat alle blogs deze week weer beschikbaar zijn. "Nadat we het probleem hadden ontdekt, moesten we de blogs zonder eigenaren scheiden van de rest. Hiervoor moesten alle weblogs opnieuw worden ingeladen en gecontroleerd op fouten. Dat heeft veel tijd gekost", zegt productmanager Coen Wesselman.

Reacties (30)

[The Zep Man]

Waren er geen oudere back-ups? Zijn er geen checksums of herkenningspunten per blog waarop gecontroleerd kan worden? Waarom was er maar één back-up? Was de back-up geverifieerd? Als het om een back-up gaat: waar is de originele data?

Op de één of andere manier kan men handmatig herkennen of een blog corrupt is of niet. Automatiseer dat zodat een computer dit voor het grootste deel kan doen (false positives en negatives zal je altijd houden), zodat in ieder geval het grootste deel van de eigen tijd en dat van een groot deel van de klanten bespaard wordt.

Dit lijkt echt amateuristisch gedaan te zijn door zowel Typepad (die de back-up aanleverde) als Sanoma (die geen goede eisen aan de levering van de gevraagde informatie heeft opgelegd en die niet goed met de huidige situatie om kan gaan).

Uit de tekst:

In januari wist Sanoma al dat de blogs gemigreerd zouden worden en dat hiervoor tot juni tijd zou zijn. Toen dit niet haalbaar bleek, kreeg de uitgever uitstel van Typepad om de boel in orde te maken. Volgens Sanoma werd dit uitstel echter plotseling ingetrokken, waarna een backup over de schutting werd gegooid en verdere communicatie niet of nauwelijks mogelijk was.

Dit geeft inderdaad de indruk dat Sanoma zowel haar eigen zaken als de afspraken met Typepad niet goed onder controle had.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 16:22]

[koter84]

Dit geeft inderdaad de indruk dat Sanoma zowel haar eigen zaken als de afspraken met Typepad niet goed onder controle had.

inderdaad, ik vind na een half jaar mogelijkheid om te migreren, dan nog 2 maanden uitstel... dan kan je volgens mij niet meer spreken van "werd dit uitstel echter plotseling ingetrokken"
gewoon dikke FAIL van Sanoma....

[Bosmonster]

Ze weten dat ongeveer 5% corrupt is, maar het is niet mogelijk deze geautomatiseerd te herkennen zodat 95% wel geautomatiseerd overgezet kan worden?

Dat lijkt me een betere tijdsinvestering dan 100% ineens handmatig over te gaan zetten...

edit: wel lekker aso van Typepad overigens..

[Reactie gewijzigd door Bosmonster op 23 juli 2024 16:22]

[Rob Coops]

Het probleem is dat dit vereist dat de mensen op de stoelen waar besloten wordt om wel of niet een scriptje te schrijven dat de rotte appels er tussen uit plukt en de rest aan de auto conversie tool voert duidelijk niet goed zijn ingelicht of simpel weg niet vertrouwen op de mensen die ze in dienst hebben.

Ik heb eens een bedrijf gered toen het na een failure van een systeem er achter kwam dat de backups net zo rot waren als de database die dat al maanden aan aan het geven was maar door een misconfiguratie deze noodkreten niet bij de beheerders wist af te leveren.
Er werden een aantal oplossingen verzonnen binnen ongeveer een uur. De voorstellen waren, restore de laatste goede backup en replay alle transacties sinds dan (duur ongeveer 1 a 2 weken), rebuild de database van scratch (duur ongeveer 1 maand) of mijn voorstel vind de laatste status van de klant maak een correct record aan en insert dat in de database (4 uur).
Die zelfde dag nog was 90% van de klanten weer helemaal gelukkig en na flink wat puzzelwerk kwam de laatste 9% gedurende de volgende dag weer terug, de overgebleven 1% had andere problemen of was in middels door de helpdesk online geholpen via de nog steeds werkende maar veel tragere standaard processen.

Als om welke reden dan ook mijn manager en de operations manager/CEO toen het vertrouwen niet gehad hadden dan had het bedrijf waarschijnlijk over de kop gegaan omdat men simpel weg te veel klanten en naam zou verliezen om nog door te kunnen blijven gaan.

Het is de mensen op de werkvloer denk ik niet te verwijten dat er een domme beslissing is genomen er van uitgaande dat men weet wat men doet en hoe men de slechte 5% kan herkennen... het is de leidinggevende volledig aan te rekenen dat dit op zo'n slechte manier opgelost wordt.
Als medewerker zou dat voor mij genoeg reden zijn om op zoek te gaan naar een andere baan omdat deze werkgever duidelijk geen vertrouwen in mij heeft.

[SPee]

Of de werknemers die moeten zeggen wat de hoge heren moeten doen hebben geen/weinig vertrouwen in zichzelf.
Als die van hun medewerkers horen: "zou kunnen...", "ik weet niet..", "ik vindt het veiliger om...", "moet ik uitzoeken...", etc., etc., dan maken die vaker zulk soort beslissingen.

[cybermaus]

...restore de laatste goede backup en replay alle transacties sinds dan (duur ongeveer 1 a 2 weken), ...

Wij maken/verkopen/installeren software om dat de doen (ik zal onze naam niet vermelden anders word dit als reclame weggemod)

Het principe heet (volgens Gartner group, ook geen naam van ons) CDP : Continuous Data Protection. "Continuous" slaat erop dat je achteraf tot elk punt in tijd terug kan draaien.

En om een dag vooruit te draaien hoeft echt niet zo lang te duren, aangezien het allemaal geautomatiseerd is. Een paar uur is al voldoende, alhoewel het natuurlijk wel afhangt van hoe oud je laatste goede backup eigenlijk is.

Afgelopen weekend nog een klant (bank) ondersteund waar een operator om 16h00 's middags per ongelijk een folder half leeggooide met high-transaction informatie. En daarna in een poging het te repareren een oude backup over de rest van de nog niet aangetaste data schreef.

We hebben de data netjes tot 16h12 herspeeld, precies de laatste transactie voor de fatale actie.

[Reactie gewijzigd door cybermaus op 23 juli 2024 16:22]

[DonKui]

Inderdaad vroeg me dit ook af, kunnen ze niet gewoon een soort check doen om te kijken of de blog die overgezet moet worden corrupt is, en zo ja dit in een bestand te zetten en deze over te slaan

[habbekrats]

Ik krijg iedere keer commentaar als ik naast de backuptapes af en toe een HD image maak. Hoewel een harde schijf danwel niet zo betrouwbaar is als een tape doe ik het toch. Al een keer eerder een tapestreamer op een cruciaal moment de tape zien opvreten en de admin hevig begon te zweten. Bleek dat de man 1 tape gebruikte en dat elke week.

De HD die ik nu gebruik is een LaCie Rugged Hard Disk 1 TB, genoeg om de belangrijkste data/os te bewaren.

[a fly]

Je krijgt terecht commentaar als je een backup opslaat op de machine waar deze gemaakt is! Bij brand of blikseminslag gaat dat namelijk gewoon kapot.

In de omgeving waar ik werk (>1000 servers) wordt er elke nacht een incrementele-backup gedraaid. Op de meer cruciale servers wordt er elke nacht een full-backup gedraaid. Elk weekend wordt er op elke server een full-backup gedraaid.

Dit wordt opgeslagen op tape. Is een tape vol, dan wordt deze in een kluis op een externe locatie bewaard.

Er zou wat met een tape kunnen gebeuren tijdens het vervoer van en naar de kluis. Omdat er tenminste 5 full backups zijn, en een veelvoud aan incrementele, is de kans op het verlies van belangrijke data redelijk klein.

Risico blijft aanwezig, maar het gaat ook om het kosten plaatje: Het risico kleiner maken kost meer dan eventueel werk wat opnieuw gedaan zou moet worden mocht het misgaan.

[GMJansen]

habbekrats,
zoals ik hierboven ook al melde: een kopie van de data hoeft geen goede backup te zijn.
als je platte data als een filesysteem hebt is het minder belangrijk, echter als je een database hebt die terug moet, en je hebt alleen een corrupt orgineel, dan heb je weinig aan een schijf met zo'n zelfde corrupte file erop.

de integriteitscheck bij de export is dan je dagelijkse controlle

[sys64738]

Dat helpt niks als je back-up al corrupt is.

Een back-up is niks waard als je niet om de zoveel tijd ook een restore test uitvoert (op een prodcutie-like systeem). Je maakt het zo vaak mee dat klanten/bedrijven zeggen dat hun back up prima verzorgd is maar als je dan vraagt of ze de afgelopen 3 jaar uberhaupt al eens geprobeerd hebben of ze ook kunnen restoren, zitten ze je glazig aan te kijken.

[Sfynx]

Onze fileserver draait op ZFS en pompt elke dag een snapshot van alle belangrijke data naar een andere locatie over het internet. Doe dat met een x aantal locaties en je zit redelijk safe dunkt me

Voor als de toko affikt o.i.d...
Terugzetten is het zfs send | zfs receive proces in omgekeerde richting uitvoeren, door al die checksumming is het eigenlijk onmogelijk dat een backup corrupt raakt zonder dat ik het doorheb... maar zelfs dan kan een periodieke test geen kwaad

Nu gaat het bij ons om een paar GB voor een snapshot per dag na stream compressie, als het teveel data wordt dan zou je zo'n stream op tapes moeten zetten en wegrijden o.i.d.... dat doen we liever niet.

[Reactie gewijzigd door Sfynx op 23 juli 2024 16:22]

[_Thanatos_]

Een corrupte backup kan ook een backup zijn die simpel verkeerd gemaakt is. Dan kun je nog zoveel checksums ertegeen plakken, maar checksums op een backup die niet correct is of onvolledig is, helpen geen zier.

Een simpele oefening is om de voorgestelde situatie na te bootsen. Dus zet een compleet nieuwe server neer (de tent is immers afgefikt) en doe wat je denkt dat je moet doen. Is dan de juiste software met plugins nog steeds geinstalleerd? Zijn de DNS-verwijzingen dan nog steeds in orde? Heeft die nieuwe server niet hardware waar de backup niet mee overweg kan? Dat soort dingen ook.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 16:22]

[GMJansen]

beetje kort door de bocht Sfynx

we hebben het hier niet over een fileserver met platte data he!
een goede backup van een database is toch echt een export.
Dat je dit niet altijd kunt doen in productieomgevingen is een feit, echter blind vertrouwen op snapshots is wel link.

[Iblies]

Dat weet jij, dat weet ik,

maar daar waar cloud-computing gemeengoed moet worden moet dit wel goed worden geregeld. Probleem daarbij is dat je in het management vaak mensen hebt die het willen verkopen en op de prijs letten,
daaronder komen pas de technici, die "uitbesteed" kunnen worden.

Dergelijke fouten zijn niet echt bevorderlijk voor het vertrouwen.

[Gé Brander]

En bij cloud computing heb je geen backup nodig want? Of begrijp ik je verkeerd?

Nog steeds kunnen er fouten (menselijke of technische) ontstaan waardoor het nodig is om een backup terug te zetten op een ander systeem of andere cloud dienst.

[Reactie gewijzigd door Gé Brander op 23 juli 2024 16:22]

[Verwijderd]

Klopt helemaal, dat je om de zoveel tijd je backups moet controleren.
Ik snap niet dat ze bij deze migratie sowieso geen extra backups hebben gemaakt. Zo'n migratie is niet zonder risico's en dan wil je toch niet kunnen terugvallen op slechts ééb kopie?
Ook na de migratie zullen ze de backups in het begin extra goed moeten testen gezien de nieuwe situatie.

[chomp]

Een backup van een corrupte backup is nog steeds corrupt...

[Eagle Creek]

Je bedoelt:
Daarom.. het terugplaatsen van back-ups periodiek testen .

Natuurlijk is dat even een naar klusje. Maar het biedt meerdere voordelen: ten eerste is men bekender met de materie, waardoor vragen die eventueel naar boven komen tijdens een test al zijn beantwoord, of in ieder geval besproken.

Ten tweede haal je er gewoon knelpunten mee uit: zijn er configuratieproblemen op het nieuwe systeem, is de back-up wel in een bruikbaar formaat / grootte, etc. En wellicht zelfs al: wordt de back-up correct aangemaakt, of is deze vaker corrupt.

Je kunt zo'n test niet bij elke back-up uitvoeren en je loopt altijd het risico dat er iets misgaat. Maar that's life. Periodiek het terugplaatsen van een back-up testen is zeker een aanrader!

Al twee weken offline met het vooruitzicht op meer downtime doet je reputatie overigens ook weinig goeds..

[Reactie gewijzigd door Eagle Creek op 23 juli 2024 16:22]

[Tomas_]

Het is natuurlijk gewoon zo dat veel bedrijven dit niet voor elkaar hebben, echter komt dat toevallig niet naar boven omdat ze de backup nog niet nodig gehad hebben.

Eigenlijk moet het bedrijf restore toetsen doen van de hele omgeving en op de site aangeven of die gelukt zijn.

Dat schept weer een beetje meer vertrouwen.

[Perceptive]

Niet zo netjes van TypePad om zo om te gaan met 400k klanten, maar het verbaast me niet. Van onbereikbaarheid en corrupte exports was 5 jaar geleden ook al sprake bij een blog-migratie bij een andere uitgever.

Al was er alleen platte HTML als backup gegeven, dan was Sanoma al redelijk geholpen.

[teacup]

Typepad zou "ruimschoots op tijd" Sanoma op de hoogte hebben gebracht. Nu is ruimschoots op tijd een relatief begrip. Ikzelf vind een half-3/4 jaar niet zo erg veel tijd om in te moeten plannen dat je hele database op zijn kop moet en dat de records moeten worden omgezet naar een (waarschijnlijk op dat moment nog te kiezen) alternatief weblog format. Wordpress als naam is groot, maar ik kan even niet beoordelen hoe voor de hand liggend deze keuze is.

Typepad zou Sanoma ook uitstel hebben verleend om de implementatie rond te krijgen. Het is speculeren in wat voor stadium Sanoma aan de bel heeft getrokken dat ze het niet gingen redden, maart, mei? Typepad zou het uitstel vroegtijdig afgebroken hebben. Wanneer? Een dag voor het einde van de periode, of een dag na het begin? Hoe dan ook, het komt wispelturig op mij over.

Uit de bovenstaande stellingen gaat volgens mij een rommelige werkelijkheid schuil. Een wispelturige uitvoerder pakte de ruimte die een wat sullige opdrachtgever zonder twijfel heeft gegeven. Beiden verdienen hiervoor geen schoonheidsprijs.

Het eerste wat Samona had moeten doen na de melding van Typepad in januari was met ze om de tafel gaan zitten om een aantal gesloten afspraken (indien nodig met boeteclausules) te maken waarin de blogsoftware overgang geregeld werd. Zo zou Samona zich ingedekt hebben geweten tegen risico's. De indruk die ik uit dit alles krijg is dat Samona geen beeld had van wat nodig was bij een dergelijk overgangsproces. Zo kon ze in afspraken met Typepad hierop niet goed anticiperen en werd ze bovendien geconfronteerd met de tijdsoverschrijding. Nu komt Samona uit de bladenbranche, is dus een uitgever, en heeft dus geen IT roots. Dit maakt het aannemelijk dat er te kort aan kennis binnen de organisatie aanwezig is om dit soort processen goed te leiden/begeleiden.

[Reactie gewijzigd door teacup op 23 juli 2024 16:22]

[bigbadbull]

dacht dat iedere sysadmin wel weet dat je op gezette tijdstippen je backups eens moet testen.
Wij hebben er een apart systeem voor dat enkel de backups op een systeem terug zet en zo problemen detecteert.

Ja er zijn natuurlijk altijd van die enge mannetjes die dat teveel geld vinden, en daar is de oplossing : dan maar geen backups als je het niet nodig vind om goede te hebben is het de moeite niet om er überhaupt te maken.
De meeste begrijpen het daarna wel.

[Aaargh!]

De backup was aangeleverd door Typepad, dat tot voor kort verantwoordelijk was voor de achterliggende blogsoftware, maar zijn diensten aan derden heeft gestaakt.

Dus als ik 't goed begrijp, had web-log.nl basically z'n hele core-business geoutsourced ? Dikke vette FAIL.

[timmetiedalton]

Jammar dat Sanoma in januari niet al direct is begonnen met de start van de migratie. Als ze de goede eisen hadden gesteld aan de back-up en dit eerst op kleine schaal hadden getest waren een hoop problemen uitgebleven.

Geen enkel bedrijf kan het maken dat een klant al 2 weken de service niet kan gebruiken. Of dat nu gratis of betaald is.

[Erkens]

400.000 weblogs zijn er natuurlijk best veel, maar waar de grootste nieuwswaarde inzit dat is eigenlijk de les die je hieruit moet leren: "zijn mijn backups wel in orde"

[koter84]

ik zie als belangrijkste les dat ze het niet zo hadden moeten uitstellen....

een half jaar om 40.000 weblogs over te zetten is goed te doen lijkt me. maar dan moet je niet pas beginnen als het eigenlijk al offline had moeten zijn....
en als je uitstel krijgt... betekend dat niet dat je het nog een jaar kan laten doorsukkelen...

[Reactie gewijzigd door koter84 op 23 juli 2024 16:22]