Modul 8 · 8.1
En plan för säkerhetskopior av din server
Modul 8: Säkerhetskopior och övervakning · Lästid: 11 minuter
Lärandemål: Efter den här lektionen kan du göra en plan för säkerhetskopior av din egen server: vad du sparar, var, hur ofta och hur länge, och hur du vet säkert att återställningen fungerar.
Nyckelbegrepp: 3-2-1-regeln, snapshot, leverantörens säkerhetskopia, egen säkerhetskopia utanför leverantören, RPO, RTO, databasdump (mariadb-dump, pg_dump), konfiguration i /etc, Docker-volymer, kryptering, ransomware, append-only, återställningstest
Varför en plan, och inte "det finns ju en säkerhetskopia"?
Nästan alla som har förlorat en server trodde att det fanns en säkerhetskopia. Sedan visar det sig att den bara innehåller operativsystemet och inte databasen, eller att den ligger på samma server som nu är borta, eller att den har krypterats av samma ransomware, eller att ingen vet lösenordet. En säkerhetskopia är bara värd något om du kan återställa den. Därför börjar du med en plan och avslutar med ett test.
En plan svarar på fem frågor:
- Vad måste kunna återställas?
- Hur mycket data får du förlora? (RPO)
- Hur snabbt måste det fungera igen? (RTO)
- Var finns kopiorna, och hur många är de?
- Hur vet du att det fungerar?
Vad måste kunna återställas?
En server består av lager. Alla lager behöver inte ingå i säkerhetskopian:
| Lager | Exempel | Säkerhetskopia? |
|---|---|---|
| Operativsystem och paket | Debian, nginx, PHP | Inte nödvändigtvis: kan installeras om. Spara däremot en lista: dpkg --get-selections |
| Konfiguration | /etc (nginx, SSH, brandvägg, systemd-units), dina compose-filer | Ja, litet och oumbärligt |
| Applikationer och webbplatser | /var/www, /opt/<app>, /srv | Ja, om de inte kommer från Git |
| Data | databaser, uppladdningar, Docker-volymer (/var/lib/docker/volumes) | Ja, det viktigaste |
| Hemligheter | lösenord, API-nycklar, nyckeln till själva säkerhetskopian | Ja, men separat och krypterat (se nedan) |
| Loggar, cacheminnen, tillfälliga filer | /var/log, /var/cache, /tmp | Oftast inte |
Var extra uppmärksam på databaser. En databas som körs skriver hela tiden. Kopierar du filerna från en MariaDB eller PostgreSQL som körs kan du få en skadad kopia. Gör därför först en dump: en konsekvent ögonblicksbild som en fil, som du sedan tar med i säkerhetskopian.
root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz(mariadb-dump hette tidigare mysqldump; det kommandot fungerar oftast fortfarande.) Körs databasen i en container gör du samma sak med docker compose exec (lektion 9.4).
RPO och RTO: hur mycket får du förlora?
Två begrepp från yrkeslivet hjälper dig att göra val:
- RPO (recovery point objective): hur mycket tid av data får du som mest förlora? En daglig säkerhetskopia klockan 03:00 betyder: om servern kraschar klockan 22:00 har du förlorat nästan en dag. För en webbutik med beställningar är det för mycket; för en blogg som ändras en gång i veckan går det bra.
- RTO (recovery time objective): hur lång tid får det ta innan allt fungerar igen? Att återställa en fullständig säkerhetskopia från leverantören kan gå på några minuter; att bygga upp en ny server och återställa allt för hand kan ta timmar.
Skriv ner dem för din egen server. De avgör hur ofta du gör en säkerhetskopia och hur du sparar den.
Snapshot, leverantörens säkerhetskopia, egen säkerhetskopia
På en VPS har du oftast tre sorters skyddsnät. De liknar varandra, men skyddar mot olika saker.
1. Snapshoten. En ögonblicksbild av hela den virtuella disken, som du gör i leverantörens panel. Snabb att göra, snabb att återställa. Perfekt precis före en uppgradering (lektion 4.3). Men: hos de flesta leverantörer ligger en snapshot på samma lagring som din server. Går den lagringen sönder, eller förlorar du ditt konto, är snapshoten också borta. Och en snapshot sparar du inte länge: den växer med alla ändringar som görs efteråt. En snapshot är ingen säkerhetskopia.
2. Leverantörens säkerhetskopia. Många leverantörer gör (ibland som tillval) automatiskt varje dag en kopia av hela din server, på annan lagring. Hos WebOké är det till exempel en daglig säkerhetskopia av hela VPS:en som sparas i sju dagar; hos andra leverantörer fungerar det på liknande sätt, med egna tidsgränser. Det är ett bra andra lager mot trasig hårdvara och mot dina egna misstag från igår. Men det är fortfarande en och samma part: ditt konto, din betalning, deras driftstörning. Och återställningen gäller oftast hela servern på en gång.
3. Din egen säkerhetskopia, utanför leverantören. En kopia av dina data hos en annan part eller på en annan plats, som du själv gör och sköter (lektion 8.2). Det är det lager som finns kvar när allt annat går fel.
3-2-1-regeln
En vanlig tumregel:
- 3 kopior av dina data (originalet plus två säkerhetskopior);
- på 2 olika sorters lagring eller system;
- varav 1 på en annan plats.
För en VPS kan det vara: data på servern, leverantörens dagliga säkerhetskopia och en krypterad egen säkerhetskopia med restic till lagring hos en annan part. Ett modernt tillägg är att minst en kopia inte ska kunna raderas av den som tar över servern (offline, eller append-only, lektion 8.2). Ransomware på en server letar aktivt efter säkerhetskopior för att kryptera eller radera även dem. En säkerhetskopia som servern själv får radera ger inget skydd mot det.
Kryptering och lösenordet till din säkerhetskopia
En säkerhetskopia hos en annan part måste vara krypterad: den innehåller kunddata, lösenord och nycklar. restic (lektion 8.2) krypterar som standard. Men då uppstår en ny risk: lösenordet till din säkerhetskopia. Har du tappat bort det är säkerhetskopian oanvändbar. Och finns det bara på servern som du har förlorat, likaså.
Spara därför lösenordet även utanför servern: i din lösenordshanterare, och gärna på papper i ett kassaskåp. Detsamma gäller inloggningsuppgifterna till lagringen där din säkerhetskopia finns.
Testa återställningen
Den viktigaste delen av planen. Ett återställningstest betyder: du återställer verkligen en säkerhetskopia, på en plats där det inte förstör något, och du kontrollerar att resultatet fungerar.
- Litet och ofta: återställ en fil eller en mapp till
/tmp/terugoch jämför (diff). Till exempel en gång i månaden. - Stort och ibland: bygg upp en helt ny testserver från säkerhetskopian, importera databasen, starta webbplatsen. Till exempel en gång om året, eller vid varje stor ändring. Det är samtidigt övningen inför den dag då det verkligen går fel (lektion 10.3).
Skriv ner hur lång tid det tog: det är din verkliga RTO.
Lagringstider
Spara inte bara den senaste säkerhetskopian. Upptäcker du först efter två veckor att en fil är skadad eller raderad behöver du en säkerhetskopia från tre veckor tillbaka. Ett vanligt schema: sju dagliga, fyra veckovisa och sex månatliga versioner. restic sköter det med forget (lektion 8.2). Tänk också på GDPR (dataskyddsförordningen): personuppgifter sparar du inte längre än nödvändigt, inte heller i säkerhetskopior. Dokumentera dina lagringstider.
I praktiken
Använd leverantörens snapshot precis före riskfyllda ändringar och ta bort den efteråt; låt leverantörens dagliga säkerhetskopia vara påslagen om den finns; och gör dessutom din egen krypterade säkerhetskopia av data och konfiguration till en annan part. Hos WebOké heter det Snapshots och Backups i VPS-vyn; hos andra leverantörer är namnen och tidsgränserna annorlunda, men principen är densamma. Ett webbhotellspaket eller en hanterad tjänst har ofta andra villkor: kontrollera vad som gäller i ditt fall.
Sammanfattning
- En säkerhetskopia är bara värd något om återställningen fungerar; börja med en plan och avsluta med ett test.
- Säkerhetskopiera framför allt data och konfiguration: databaser som dump,
/etc, webbplatser, Docker-volymer, compose-filer. - Bestäm RPO (hur mycket du får förlora) och RTO (hur snabbt det måste fungera).
- Snapshot (samma lagring, kort tid), leverantörens säkerhetskopia (annan lagring, samma part) och en egen säkerhetskopia utanför leverantören är tre olika lager; följ 3-2-1-regeln med minst en kopia som servern själv inte kan radera.
- Kryptera, spara lösenordet till säkerhetskopian utanför servern och testa återställningen: litet och ofta, stort ibland.
Quiz
Uppgift
Uppgift O8.1: Din plan för säkerhetskopior. Gör en plan för säkerhetskopior av din egen server på en sida: vad som måste kunna återställas (per lager), din RPO och RTO, vilka kopior du har (snapshot, leverantör, egen) och var, dina lagringstider, var lösenordet till säkerhetskopian finns och när du gör ett återställningstest. Fyll i formuläret; när du har skickat in det ser du en exempelplan som du kan jämföra din egen plan med.
Uppgift O8.1: Din plan för säkerhetskopior
Den här uppgiften gör du själv; ingen kontrollerar den. Bocka av vad du har gjort och markera uppgiften som klar.
Databaser med en dump, inte som lösa filer från en databas som körs. Dagligen krypterat (restic) till en annan leverantör; snapshot bara kring ändringar. 7 dagliga, 4 veckovisa och 6 månatliga versioner är en bra början. Varje månad en liten återställning, varje år en fullständig återuppbyggnad. Fyll aldrig i ett riktigt lösenord.
Dina bockar och anteckningar sparas bara i den här webbläsaren; vi skickar dem ingenstans. Är du inloggad sparar vi i Mina kurser bara att du har gjort uppgiften.
Läs mer
- Snapshots och backuper av din VPS
- Backupstrategi: 3-2-1-regeln för ditt eget företag
- I kursen Säker online: lektionerna om 3-2-1-regeln och säkerhetskopior som klarar ransomware.
- MariaDB, mariadb-dump: https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
- PostgreSQL, Backup and Restore (SQL Dump): https://www.postgresql.org/docs/current/backup-dump.html
