WordPress-backup som fungerar – 3-2-1, databas och filer

Nästan alla som kör WordPress vet att backup är viktigt. Betydligt färre har tänkt igenom vad som egentligen behöver backas upp, hur ofta och var kopiorna faktiskt hamnar. Det är den distinktionen som avgör om du kan återställa sajten på en timme, eller om du tillbringar tre dagar med att försöka lappa ihop ett halvfärdigt tillstånd från webbhotellets kontrollpanel.

WordPress är inte en monolitisk klump av data. Det är två fundamentalt olika typer av innehåll med olika förändringstakt, olika säkerhetskopierings-behov och olika konsekvenser om de saknas. Den insikten saknas i de flesta backup-guides, och det är den vi börjar med.

Databasen och filerna beter sig inte likadant

En WordPress-installation består av filer och en databas, och de förändras i helt olika takt. Inser du det förändras hela synen på hur du bör lägga upp ditt backup-schema.

Databasen innehåller allt dynamiskt: inlägg, sidor, kommentarer, användaruppgifter, inställningar, widgetkonfigurationer och, om du kör WooCommerce, alla ordrar, kunddata och lagersaldon. Varje gång du publicerar ett nytt inlägg ändras databasen. Varje order som läggs in ändras databasen. Varje inställning du justerar skriver till databasen. För en aktiv sajt kan det hända dussintals gånger per dag.

Filerna, det vill säga wp-content/uploads, teman och plugins, beter sig annorlunda. Uppladdningsmappen växer löpande med bilder och dokument, men enskilda filer ändras aldrig efter att de laddades upp. Teman och plugins förändras bara när du uppdaterar eller installerar något nytt.

Praktisk konsekvens av det här: en blogg eller WooCommerce-butik med dagliga ordrar behöver en databas-backup minst dagligen, gärna var fjärde till var sjätte timme för transaktionsintensiva sajter. Uppladdningsmappen med 4 000 produktbilder behöver däremot inte backas upp varje natt, i synnerhet inte om du redan vet att ingenting ändrades sedan igår. Det är skillnaden inkrementell backup löser: istället för att kopiera hela uppladdningsmappen varje natt tar ett bra backup-plugin bara med de filer som faktiskt tillkommit eller ändrats sedan senaste körningen.

Märk att den inkrementella logiken också löser ett annat problem. Stora uploads-mappar (vi har sett sajter med 20 till 50 GB bilder) gör att en naiv "allt varje natt"-backup äter lagringskvot snabbt och kan krocka med de inode-gränser vi beskriver i vår artikel om dolda resursgränser. Inkrementell backup minskar den risken markant.

Vad 3-2-1 faktiskt betyder för en WordPress-sajt

3-2-1-principen är industristandard inom backup, och den är enkel nog att minnas utan att förenkla bort det väsentliga. Tre kopior av data, på två olika typer av lagring, varav en kopia finns offsite.

Applicerat på WordPress brukar det se ut ungefär så här:

Offsite-kopian är den som folk oftast struntar i, och den är den enda som faktiskt räddar dig om något allvarligt händer hos webbhotellet självt. Branschstandarden är inte en nyckfull regel utan ett svar på ett konkret riskscenario: en kopia på samma server hjälper dig inte om servern försvinner.

Webbhotellets backup är ett skyddsnät, inte en plan

Det här är den punkt där många WordPress-ägare har en falsk trygghet, och det är värt att vara rakt på sak.

Webbhotellets inbyggda backup är kopia 1 av 3 i din 3-2-1-plan. Den är värdefull och du bör använda den. Men den är inte din backup-plan.

Tre konkreta skäl till varför den inte räcker ensam:

Platsen. Webbhotellets backup lagras ofta på samma server, eller åtminstone i samma datacenter, som din sajt. Det skyddar dig mot att en fil raderas av misstag. Det skyddar dig inte mot ett serverfel, en datacenterolycka eller att webbhotellet stänger ned ditt konto utan förvarning. Det senare är ovanligt men händer, och det är ett scenario du inte kan undvika med enbart webbhotellets backup.

Granulariteten. Många hostingleverantörer erbjuder återställning av hela kontot men inte av enskilda filer eller databastabeller. Om du råkar skriva över ett inlägg eller ett plugin gör en massa ändringar i databasen kan du tvingas välja mellan att återställa ingenting eller att rulla tillbaka hela sajten till ett tidigare tillstånd, inklusive innehåll du publicerade efter det datumet.

Backup-historiken. Hur länge sparas backup-historiken? Sju dagar? Trettio? Om din sajt infekterades med skadlig kod för tre veckor sedan och du inte märkte det kan du vara tvungen att gå längre bakåt än vad webbhotellets rulle sträcker sig. Utan en extern backup med längre historik sitter du fast.

Fråga din host rakt ut: Hur ofta körs backup? Var lagras den fysiskt? Kan jag återställa en enstaka fil eller bara hela kontot? Vad kostar en manuell återställning? Svaren varierar kraftigt mellan leverantörer och mellan planer hos samma leverantör, och de är sällan framträdande i marknadsföringsmaterialet.

Så här ser det ut när en host faktiskt erbjuder backup med tydlig kontroll i kontrollpanelen (i det här fallet Oderland med Acronis-integration):

Att ett sådant gränssnitt finns innebär inte att allt sköter sig själv. Det innebär att du har verktygen. Du behöver fortfarande bekräfta att backup faktiskt körs och testa att återställning fungerar.

Off-site i praktiken: plugins och extern lagring

Det vanligaste sättet att skapa kopia 2 (offsite) för en WordPress-sajt är att använda ett backup-plugin som automatiskt skickar backup-filerna till en extern lagringstjänst. UpdraftPlus är det mest använda och fungerar väl för de flesta. Det finns också alternativ som BackupBuddy och Duplicator, med något olika fokus.

Valet av lagringsmål spelar roll. Några alternativ att ta ställning till:

• Dropbox eller Google Drive är enkla att komma igång med och kostar ingenting om du har plats i kontot. Nackdelen är att de inte är designade som backup-arkiv, versionering och retention-regler är begränsade, och du blandar in din personliga data med sajt-backuper.
• Backblaze B2 är ett objekt-lagringssystem byggt för just backup, med rimlig prissättning per GB. Det kräver lite mer konfiguration men ger bättre kontroll över retention och lagringskostnad.
• Sunet Drive eller svenska molntjänster är värda att titta på om datasuveränitet är ett krav, till exempel om du hanterar personuppgifter och vill hålla all data inom EU-jurisdiktion. Kolla att lagringstjänsten explicit garanterar europeisk infrastruktur och tydlig databehandlingsöverenskommelse.

En praktisk tumregel: välj ett lagringsmål du inte har kopplat till webbhotellets infrastruktur. Poängen med offsite-kopian är att den ska vara oberoende av din primära hosting-leverantör.

Om din sajt är liten (under 5 GB totalt) och du publicerar sällan duger ett gratis Dropbox- eller Google Drive-konto utmärkt. Driver du en WooCommerce-butik med tusentals produktbilder och dagliga ordrar är det värt att sätta upp B2 eller liknande med separata retention-regler för databas-backuper (täta, behåll länge) och fil-backuper (glesare, behåll kortare).

Testa återställningen innan du behöver den

En backup du aldrig återställt är en förhoppning. Det är ett hårt påstående, men det är verifierat av verkligheten gång på gång.

Backup-system slutar fungera av en rad skäl som inte genererar uppenbara felmeddelanden: autentiseringstoken mot molntjänsten löpte ut, backup-pluginet uppgraderades och ändrade sitt filformat, diskkvoten hos lagringstjänsten fylldes utan att du fick ett mejl om det, databas-exporten misslyckades i bakgrunden och ingen berättade om det. Backupen existerar i logg-rutan men är inte återställningsbar.

Det minsta du bör göra kvartalsvis:

1. Ladda ned en backup-fil från din externa lagring och kontrollera att den faktiskt är fullständig, att den innehåller en SQL-dump och inte bara filer.
2. Återställ till en staging-miljö hos webbhotellet, ett separat test-domain eller en lokal installation. Moderna webbhotell erbjuder oftast staging med ett klick, vilket gör det hela till en tjugo minuter lång operation.
3. Bekräfta att sajten fungerar: startsidan laddar, inloggning fungerar, ett inlägg eller en produkt syns som förväntat.

Det är allt. Tre steg, tjugo minuter, kvartalsvis. Den som aldrig gjort det vet inte vad de inte vet.

Om du byter webbhotell är detta ännu viktigare. Att ha en verifierad, extern backup som du vet går att återställa är en förutsättning för ett tryggt byte. Det väger tungt när du planerar ett byte av webbhotell.

Backup-checklista för WordPress

Sammanfattat i konkreta kontrollpunkter:

• Webbhotellets automatiska backup är aktiverad. Du har verifierat att den faktiskt körde senast (kolla loggen, anta ingenting).
• Du vet var backup-filerna lagras fysiskt och om det är samma server eller genuint offsite.
• Du har ett backup-plugin installerat och konfigurerat mot en extern lagringstjänst.
• Databas-backupen körs oftare än fil-backupen om du har en aktiv butik eller publicerar ofta.
• Inkrementell backup är aktiverad för uppladdningsmappen om den är stor.
• Du har testat en återställning, inte bara tittat på loggen.
• Du har en kalender-påminnelse för nästa test om tre månader.

Inget av det här är komplicerat. Det kräver ungefär en timme att sätta upp och tjugo minuter att verifiera kvartalsvis. Mot det väger du kostnaden av att inte ha det när du verkligen behöver det.