Säkerhetskopiering av server: testa återställningen

När jag tar över en server frågar jag först: ”Finns det säkerhetskopior?” Svaret är nästan alltid ”ja”. Nästa fråga — ”När återställde ni senast något från dem?” — möts oftast av tystnad.

Det är där säkerhetskopieringen brukar vara trasig. Inte för att ingen tar kopior, utan för att ingen vet om man faktiskt kan få tillbaka något från dem.

Kort svar: en säkerhetskopia finns först när något har återställts från den. Ha minst tre kopior på två olika lagringsmedier, varav en ligger utanför servern och utom räckhåll för en angripare. Säkerhetskopiera databaser med databasens egna verktyg, inte som filkopia. Och testa återställningen regelbundet — inte först när något redan har försvunnit.

Varför ”vi har backup” ofta inte stämmer

Typiska situationer:

• Backupskriptet slutade fungera för månader sedan — till exempel efter ett lösenordsbyte eller en full disk — och ingen märkte det, eftersom felmeddelandet inte gick till någon.
• Databasen kopierades som filer medan den körde. Kopian finns, men den togs mitt i en skrivning och databasen kanske inte startar från den.
• Säkerhetskopian ligger på samma server. När disken går sönder eller ransomware krypterar servern försvinner kopian tillsammans med originalet.
• Kopian finns, men det finns ingen återställningsrutin. Återställningen tar två dagar i stället för en timme, eftersom ingen minns vilken version, vilken mapp och i vilken ordning.

3-2-1-regeln på vanlig svenska

• 3 kopior av datan (originalet plus två säkerhetskopior),
• på 2 olika medier eller system,
• 1 kopia någon annanstans — i ett annat datacenter eller hos en annan leverantör.

I dag lägger jag till ett krav: minst en kopia ska vara oföränderlig eller på annat sätt skyddad mot en angripare. Ransomware letar medvetet upp säkerhetskopior också. Om servern har både skriv- och raderingsrätt till backuplagringen kan en angripare förstöra kopiorna också. Därför skickar servern ut kopior men kan inte själv radera dem.

Vad som ska säkerhetskopieras — och vad som inte ska det

Säkerhetskopiera:

• Databaser (PostgreSQL, MySQL/MariaDB) med en riktig dump eller en metod som ger ett konsekvent läge. Inte en blind filkopia av en databas som körs.
• Applikationens filer som användarna skapar: uppladdningar, dokument, bilder.
• Konfiguration: webbserverns (Nginx, Apache2) inställningar, applikationens konfigurationsfiler, schemalagda jobb, Docker compose-filer och miljövariabler.
• Certifikat och nycklar — krypterade.

Slösa inte utrymme på:

• operativsystemets filer som kan installeras om;
• cacheminnen och temporära filer;
• Docker-avbilder som kan hämtas igen från ett register (säkerhetskopiera datavolymerna, inte containrarna).

Om servern är väl dokumenterad går det ofta snabbare att bygga upp systemet från grunden än att återställa en hel diskavbild. Säkerhetskopiera alltså framför allt det som inte kan skapas på nytt.

Hur länge kopiorna ska sparas

En enda kopia från i går hjälper inte om felet uppstod för en vecka sedan och redan har hamnat i varje kopia. En typisk rotation kan vara: dagliga kopior i två veckor, veckovisa i ett par månader, månatliga i ett år. Rätt rytm beror på hur snabbt din data ändras och vad bokföringen eller avtal kräver.

Säkerhetskopior ska vara krypterade — särskilt när de ligger i någon annans infrastruktur. Men krypteringsnyckeln måste förvaras någon annanstans än på servern: försvinner nyckeln med servern är den krypterade kopian värdelös.

Återställningstest: två frågor som behöver svar

Innan något händer är det värt att komma överens om två siffror:

• Hur mycket data har du råd att förlora? Om du säkerhetskopierar en gång per dygn kan du i värsta fall förlora en hel dags arbete. Är det för mycket behövs tätare säkerhetskopiering.
• Hur länge får systemet vara nere? Måste återställningen rymmas inom en timme, eller får den ta en dag?

Ett återställningstest visar om de siffrorna verkligen går att nå. Min rutin är enkel:

1. Jag väljer en slumpmässig säkerhetskopia — inte alltid den senaste.
2. Jag återställer den i en separat testmiljö, inte på produktionsservern.
3. Jag kontrollerar att databasen startar, applikationen öppnas och att den senaste datan finns med.
4. Jag mäter hur lång tid det tog och skriver ner allt som inte gick som rutinen sa.

Och ett automatiskt skydd: säkerhetskopieringen behöver ett larm när en kopia uteblir eller är misstänkt liten. Ett tyst fel är det dyraste felet i säkerhetskopiering.

Säkerhetskopiering och återställningstester ingår i min serverdrift — vad mer ett underhållsavtal omfattar beskriver jag i Linux-serverunderhåll: vad avtalet omfattar. Om du ska flytta till en ny server är ett färskt återställningstest också den bästa kontrollen innan du uppgraderar en gammal Ubuntu-server.

Vanliga frågor

Räcker inte webbhotellets säkerhetskopia?

Det är ett bra extra lager, men räcker sällan ensamt. Lagringstiden är ofta kort, man kan bara återställa hela servern på en gång och kopian ligger hos samma leverantör. Om problemet är leverantören eller kontot blir båda kopiorna oåtkomliga samtidigt.

Hur ofta ska man testa återställning?

Minst ett par gånger om året och alltid efter en större förändring: ny server, ny databasversion, ändrat backupskript. Oftare för kritiska system.

Är RAID en säkerhetskopia?

Nej. RAID skyddar mot att en disk går sönder, men en raderad fil eller data som krypterats av ransomware raderas eller krypteras på alla diskar samtidigt.

Säkerhetskopieras en applikation i Docker på ett annat sätt?

Principen är densamma: säkerhetskopiera datan och konfigurationen, inte containern. En databas i en container säkerhetskopieras fortfarande med en riktig databasdump, inte som en rå kopia av volymen medan den körs.

Är dina säkerhetskopior verkligen kontrollerade?

Om du inte vet säkert när något senast återställdes från din servers säkerhetskopior, skriv till mig. Jag går igenom vad som säkerhetskopieras, vart och hur länge det sparas, och gör det första återställningstestet tillsammans med dig. Mer om hur min serverdrift fungerar finns på sidan Linux-serverdrift.