Backup-plan för din webbplats - Sätt upp, testa och återskapa

De flesta webbplatsägare vet att backup är viktigt. Färre har en backupplan som de vet fungerar när det verkligen gäller. Det är skillnaden som spelar roll klockan 02:00 när sajten är nere. Den här guiden tar dig igenom hela kedjan: från att aktivera och verifiera backup, till att testa att den går att återställa, till att ha ett förberett svar på det värsta scenariot.

Tre principer avgör om din backup faktiskt skyddar dig när det gäller:

1. Automatisk backup aktiverad och verifierad. Aktivera hos webbhotellet och bekräfta att den faktiskt körs. Kolla loggen, gissa inte.
2. En extern kopia utanför servern. Webbhotellets inbyggda backup skyddar dig inte mot webbhotellets egna fel. Du behöver en kopia på en annan plats.
3. Testa återställningen på riktigt. En backup du aldrig testat är ett antagande, inte ett skyddsnät. Ha dessutom en katastrofplan klar innan du behöver den.

Varje punkt fördjupas i ett eget avsnitt nedan. Tillämpar du bara detta och ingenting mer har du ändå fått det väsentliga.

3-2-1-regeln för din webbplats - strategin som proffsen använder

Innan du börjar konfigurera något är det värt att ha ett mentalt ramverk klart för vad en fullständig backupstrategi faktiskt innebär. 3-2-1-regeln är det ramverket, och det är enkelt nog att minnas men tillräckligt robust för att hålla i skarpa lägen.

Regeln säger att du ska ha tre kopior av din data, lagrade på två olika typer av media, varav en kopia finns offsite, det vill säga utanför servern och gärna utanför din kontrollpanel. Applicerat på en webbplats ser det ut ungefär så här:

Det kritiska steget är kopia nummer två. Om webbhotellets datacenter drabbas av brand, ett allvarligt strömavbrott eller i värsta fall en konkurs är kopia 1 borta med det. Bara offsite-backupen räddar dig i det scenariot. Märk att många webbhotell lagrar sin inbyggda backup på samma server som sajten körs på. Det är inte offsite, oavsett vad det kallas.

En viktig teknisk not för WordPress-sajter: du har två separata delar att backa upp. Filerna, det vill säga teman, plugins och mediafiler i uploads-mappen, och databasen, som innehåller alla dina inlägg, sidor, inställningar och användardata. En backup utan databasen är en halvfärdig backup. Säkerställ att båda ingår.

Bilden ovan visar webbhotellet Oderlands backupssystem med Acronis. Tydliga dateringar bakåt i tiden gör det möjligt att välja att återställa hela eller delar av kontot enkelt om en kris uppstår. Bilden nedan visar återställningsmöjligheterna, vilket inkluderar domäner, filer, databaser och e-post.

Sätt upp din automatiska backup - steg för steg

Nu till det konkreta. Fyra steg för att få ett fungerande backupsystem på plats, oavsett om du kör WordPress eller en annan typ av webbplats.

Steg 1: Aktivera och verifiera webbhotellets inbyggda backup. Logga in i kontrollpanelen, oavsett om det är cPanel, Plesk eller något annat, och hitta backupinställningarna. Bekräfta att automatisk daglig backup är aktiverad. Men stanna inte där. Det viktigaste steget är att titta på den senaste backuploggen och verifiera att det faktiskt tagits en backup nyligen. Många webbplatsägare aktiverar backup en gång och antar sedan att den körs. Det antagandet har lett till jobbiga överraskningar.

Om ditt nuvarande webbhotell inte erbjuder daglig automatisk backup kan det vara dags att jämföra webbhotell som gör det. Det är ett grundläggande krav, inte en premiumfunktion. Inleed erbjuder daglig backup med generös historik, Templ hanterar backup automatiskt som en del av sin managed WordPress-plattform, och Oderland backar upp via Acronis med tydlig historik bakåt i tiden. Gemensamt för dem är att du kan inspektera och återställa direkt från kontrollpanelen.

Steg 2: Konfigurera extern backup för WordPress. För en WordPress-sajt innebär det att installera ett backupplugin och peka det mot en extern molntjänst. Välj verktyget som passar dig bäst och rikta det mot Google Drive, Dropbox eller en liknande tjänst. De flesta etablerade backupplugins stöder flera alternativ. Frågan om hur tätt du bör ta backup beror på hur ofta du uppdaterar sajten. Det svarar vi på i vår FAQ om backupfrekvens.

Kör du inte WordPress utan en annan typ av webbplats? Kontrollpanelen hos de flesta webbhotell erbjuder vanligen en exportfunktion, antingen manuell eller schemalagd. Använd den och skicka kopiorna till extern lagring.

Steg 3: Ta en manuell backup innan varje stor förändring. Automatisk backup skyddar dig mot det vardagliga, ett inlägg som raderas av misstag eller en inställning som försvinner. Men inför pluginuppdateringar, temabyten eller stora layoutförändringar behöver du en punkt-i-tid-kopia som du vet är tagen precis innan förändringen. Gör det till en rutin.

Steg 4: Dokumentera vad du har. Skriv ner, i ett enkelt dokument eller ett anteckningsblock, var backupfilerna finns, vilket schema de följer och hur du loggar in för att återställa. Det är inte för dig i dag. Det är för dig i panik kl 02:00, eller för en kollega som måste hantera ett problem utan dig.

Är du e-handlare med transaktionsdata och kunduppgifter? Då gäller strängare krav än för en enkel blogg. Vår guide om tekniska krav för din webbutik ger dig den kompletta kravspecen för e-handelshosting.

Hur du vet om din backup faktiskt fungerar

Det räcker inte att backuppluginets eller kontrollpanelens statusindikator visar grönt. Avsaknad av felmeddelanden är inte detsamma som att backupen är komplett och återställningsbar. Det är en vanlig missuppfattning och en farlig en.

Tre konkreta saker att kontrollera regelbundet:

• Titta på backuploggen i kontrollpanelen eller plugindashboarden. Avslutades den senaste backupen utan fel? Är tidsstämpeln rimlig?
• Kontrollera filstorleken. En backup som väger 1 MB för en sajt som borde vara 200 MB är ett varningstecken. Antingen är något uteslutet, eller så är det en gammal backup från innan sajten byggdes ut.
• Bekräfta att databasen ingår. Det är den vanligaste bristen. Filerna kan vara korrekt backupade medan databasen, med alla inlägg, inställningar och användardata, saknas helt.

Kvartalstest - så vet du att din backup fungerar på riktigt

En backup du aldrig testat är ett antagande. Det enda sättet att veta att backupen verkligen fungerar är att faktiskt återställa den och kontrollera resultatet. Det låter som ett steg de flesta hoppar över, och det stämmer. Det är precis därför det är så viktigt.

Testprotokollet i fem steg:

1. Välj en backup att testa. Välj helst en backup från förra veckan, inte den absolut senaste. Syftet är att verifiera att backuper från det normala schemat fungerar, inte bara en manuell backup du just tagit.
2. Sätt upp en testmiljö. Antingen webbhotellets inbyggda stagingfunktion, om det finns en sådan, ett separat testdomännamn eller en lokal installation med verktyg som XAMPP. Du behöver inte sätta upp en hel serverinfrastruktur för detta.
3. Återställ backupen till testmiljön. Följ webbhotellets eller pluginets egna återställningsinstruktion. De varierar och det är bättre att följa aktuell dokumentation än att ha utskrivna steg som kan ha ändrats. Skriv upp vad du gör.
4. Kontrollera att sajten fungerar korrekt. Kontrollera startsidan, ett kontaktformulär, en inloggningssida och databaskopplat innehåll som inlägg och produkter. Ser bilderna ut som de ska? Saknas det något?
5. Dokumentera resultatet. Datum, vilken backup som testades, eventuella problem och hur de löstes. Om du hittar ett problem nu är det oändligt mycket bättre än att hitta det under en riktig incident.

Lägg sedan omedelbart in en kalenderpåminnelse för nästa test om tre månader. Det är det enda sättet att säkerställa att det faktiskt blir av.

Vad räknas som ett godkänt test? Sajten är fullt funktionell, inga databasfelmeddelanden, bilder och filer är intakta och formulär fungerar. Är något av det inte uppfyllt är det ett misslyckat test och ett viktigt signalvärde att ta hand om nu, inte sedan.

Webbhotell med inbyggd stagingfunktion gör det här betydligt enklare. Vad du bör kräva av ett säkert webbhotell i övrigt finns samlat i vår guide om säkert webbhotellval.

Om sajten hackas - vad gör du då?

Det här avsnittet finns inte för att skrämma. Det finns för att du ska ha ett förberett svar på det värsta scenariot, precis som brandsläckaren du förhoppningsvis aldrig behöver använda. En plan skriven i lugn och ro är oändligt mer användbar än en improvisation under stress.

Vad ett typiskt förlopp kan se ut som om din WordPress-sajt hackas:

Timme 0 - Du upptäcker problemet. Sajten visar konstig text, Google varnar för skadlig kod, eller du har fått ett e-postmeddelande från webbhotellet. Panikera inte. Agera metodiskt.

Timme 0-1 - Stäng och säkra. Sätt sajten i underhållsläge eller inaktivera den tillfälligt via kontrollpanelen. Byt sedan alla lösenord direkt: webbhotellkonto, FTP/SFTP, databas, WordPress-admin. Gör det i den ordningen, och gör det innan du börjar städa. Annars kan angriparen ta sig in igen medan du återställer.

Timme 1-2 - Identifiera senaste rena backup. Titta på din backuplogg och försök hitta en backup från innan infektionen skedde. Det svåra är att du kanske inte vet exakt när det skedde. Är du osäker, gå längre bakåt i historiken. En sajt som är en vecka gammal men ren är bättre än en hackad version från igår.

Timme 2-4 - Återställ till ren backup. Återställ till stagingmiljön först. Verifiera att den valda backupen är ren och fungerar. Det är kvartalsprotokollstanken tillämpad under press. Sedan återställer du till produktionsmiljön. Skriv upp exakt vad du gör, steg för steg.

Timme 4-6 - Skanna och förstå. Kör en malware-skanning på den återställda sajten, antingen via webbhotellets inbyggda scanner eller ett säkerhetsplugin. Försök förstå hur angriparen kom in. Föråldrat plugin? Svagt lösenord? Stulna inloggningsuppgifter? Stäng den vägen innan sajten är live igen.

Dag 2 - Driftsätt och övervaka. Publicera den rena sajten. Övervaka den extra noga de kommande dagarna. Om personuppgifter kan ha exponerats, till exempel e-postadresser i en databas eller betalningsinformation för e-handlare, gäller GDPR:s 72-timmarsregel för anmälan till Integritetsskyddsmyndigheten. Se vår artikel om GDPR och dataintrång för vad som gäller.

Det du behöver ha klart innan det händer: veta var din lösenordshanterare finns och hur du når den, ha webbhotellets supportnummer tillgängligt och veta exakt var backuploggarna finns. De tre sakerna minskar reaktionstiden markant.

Det starkaste argumentet för kvartalstestning är förresten detta: om infektionen skedde för tre veckor sedan och du aldrig testat dina backuper kan du tvingas gå tillbaka till en version av sajten som är månader gammal. Det är ett reellt scenario, inte ett tankeexperiment.

Vill du informera dina besökare om det behövs? Om e-post eller personuppgifter kan ha exponerats är det GDPR-skyldigt och inte bara en artighetsfråga. Läs mer om webbhotell med starka säkerhetsfunktioner om du vill jämföra leverantörer som hanterar säkerhetsincidenter bättre.

GDPR och dina backuper - ett förbisett problem

Vi pratade nyss om GDPR:s 72-timmarsregel vid intrång, men GDPR påverkar ditt backuparbete på ytterligare ett sätt som ofta glöms bort.

Gamla backuper med personuppgifter som aldrig raderas är ett GDPR-problem. Om din backup från för tre år sedan innehåller kunduppgifter, e-postadresser och orderhistorik, och du fortfarande har den liggandes i en molnmapp, lagrar du personuppgifter utan nödvändigtvis ha ett giltigt syfte kvar. GDPR kräver att personuppgifter bara sparas så länge det finns ett legitimt behov. Det gäller även backupfiler.

I praktiken betyder det att du bör ha en tydlig policy för hur länge backuper sparas och att äldre kopior tas bort systematiskt. Många backupverktyg stöder automatisk radering av kopior äldre än ett visst antal dagar. Använd den funktionen. En rotation där du behåller dagliga backuper i 30 dagar, veckovisa i 3 månader och månatliga i ett år är ett rimligt upplägg för de flesta sajter med personuppgifter. Vad som är rätt för dig beror på vilken typ av data du hanterar. Mer vägledning finns i vår GDPR-checklista för hemsidor.

Din backupchecklista

Gå igenom punkterna nedan. Det som saknas är dina nästa steg.

• Webbhotellets automatiska backup är aktiverad och verifierad. Loggen är kontrollerad, inte bara inställningen.
• En extern offsite-backup är konfigurerad och kopior lagras utanför servern.
• 3-2-1-regeln är uppfylld. Räkna dina tre kopior och var de finns.
• Senaste kvartalstest är genomfört och dokumenterat med datum och resultat.
• Katastrofplan finns nedskriven med lösenordshanterare, backupplats och steg att följa.
• Kalenderpåminnelse är inlagd för nästa test om tre månader.
• Backuper äldre än din retentionspolicy är raderade, så att gamla personuppgifter inte bevaras i onödan.

Backupsystemet är inte klart en gång för alla. Det är ett löpande arbete, och checklistan ovan är utgångspunkten du kan återkomma till varje kvartal. Vill du också se över vilket webbhotell du faktiskt kör på? En leverantör med inbyggd staging, generös backuphistorik och tydliga GDPR-rutiner tar bort en hel del manuellt arbete. Du hittar ett urval i vår jämförelse av webbhotell och kan fördjupa dig i säkerhetsaspekterna specifikt i guiden om vad du bör kräva av ett säkert webbhotell.