Blogger du med WordPress kan du ikke være trygg på at backup-fila fungerer etter f.eks. et hackerangrep. Her en oppskrift.

De siste ukene har det skjedd rare ting i denne bloggen. Systemet er blitt utsatt for en massiv påloggingskampanje, fulgt av mange uforklarlige meldinger om endringer i systemet mitt at jeg ikke lenger turte å la det fortsette slik. Derfor slettet jeg blogginstallasjonen, installerte WordPress på nytt og begynte på arbeidet med å gjenopprette innholdet fra backup. Jeg har alltid vært påpasselig med å ta regelmessige sikkerhetskopier og lagre dem på et trygt sted, så jeg regnet ikke med at backupfila som WordPress genererer ville gi meg problemer.

Men det gjorde den til gagns. Importfunksjonen kræsjet så snart fila var lastet inn, og ga bare en lite informativ feilmelding. Jeg hadde mange backupfiler (jeg tar selvsagt vare på tidligere versjoner også!), og alle ga det samme resultatet. Av det trakk jeg slutningen at det neppe handlet om at fila var ødelagt, men at problemet var serverrelatert. Jeg oppdaget snart at jeg ikke var alene. Riktignok er problemet ikke veldig utbredt, men det ser ut til å skapt problemer for én bestemt kategori med WordPress-brukere i årevis: Vi som har store backupfiler.

 

2 MB en magisk grense

Jeg begynte å blogge i 2003, og siden det ikke fantes sosiale medier den gang var jeg en ivrig blogger. I årevis kom det minst en posting om dagen, og mange av dem var rike på tekst. Resultat: Min backupfil er nå på rundt 28 MB. Det høres ikke så mye ut, og er det heller ikke med tanke på at bilder i bloggen ikke sikkerhetskopieres (du må altså ha en egen backuprutine for dem!) Men på denne siden påpekes det at selv om WordPress i teorien tilllater installasjon av backup-filer på opptil 7 MB (min installasjon hevder opptil 64 MB) vil systemet ofte kræsje om filene blir større enn 2 MB.

The problem here is not with uploading the XML file. It’s with processing it. Once uploaded, WordPress passes the XML file into a PHP processor script. The processor parses through each line of the XML document and handles the data accordingly. Namely: it inserts records into the database according to the XML doc’s content and meta definitions (author, publish date, status, tags, etc.).

It’s that markup-parse/database-insert process that causes a problem. It just takes too long. 2MB of plain text—like in an XML file—is a TON of text. The server takes forever to process all the data in the 2MB file. And most servers have a timeout limit. They don’t let the process run long enough.

Den forestlåtte løsningen er å dele fila opp i komponenter som er så små at de kan håndteres av WordPress. Hell i uhell: Om ikke WordPress har kompetanse nok til å skrive programvare som kan håndtere systemets egne sikkerhetskopier hadde de i alle fall vett nok til å gå or XML som standard. Det betyr at backupfila er en ren tekstfil som kan åpnes i en teksteditor (bruk ALDRI et tekstbehandlingsprogram til en slik fil!) og deles opp ved å klippe og lime tekstsegmenter for hånd. Oppskriften finnes i lenken over, jeg kommer også tilbake til en grundigere beskrivelse her.

Min backup-fil var på ca 350 000 linjer, ved å dele den opp i 15 mindre tekstfiler (fra 22 000 til 25 000 linjer) fikk jeg segmenter på i underkant av 2 MB. Da gikk importen uten problemer. Jeg har nå laget et eget underområde der de mindre filene er lagret for fremtiden så jeg slipper å bruke en halv dag på dette neste gang jeg har bloggproblemer. Jeg har også lastet ned alle bildene fra bloggen i en mappestruktur som avspeiler den i den opprinnelige bloggen. Når bildene lastes opp til samme mapper i den nye WordPress-installasjonen, havner bildene på rett sted i bloggen. Tungvint, men om ikke annet fungerer det.