Modul 8 · 8.1
En backupplan for din server
Modul 8: Backup og overvågning · Læsetid: 11 minutter
Læringsmål: Efter denne lektion kan du lave en backupplan for din egen server: hvad du gemmer, hvor, hvor tit og hvor længe, og hvordan du er sikker på, at gendannelse virker.
Centrale begreber: 3-2-1-reglen, snapshot, udbyderens backup, egen backup uden for udbyderen, RPO, RTO, databasedump (mariadb-dump, pg_dump), konfiguration i /etc, Docker-volumes, kryptering, ransomware, append-only, gendannelsestest
Hvorfor en plan og ikke bare "der er da en backup"?
Næsten alle, der har mistet en server, troede, at der var en backup. Så viser det sig, at den kun indeholder styresystemet og ikke databasen, eller at den ligger på den samme server, som nu er væk, eller at den er krypteret af den samme ransomware, eller at ingen kender adgangskoden. En backup er først noget værd, når du kan gendanne den. Derfor begynder du med en plan og slutter med en test.
En plan besvarer fem spørgsmål:
- Hvad skal kunne gendannes?
- Hvor mange data må du miste? (RPO)
- Hvor hurtigt skal det virke igen? (RTO)
- Hvor ligger kopierne, og hvor mange er der?
- Hvordan ved du, at det virker?
Hvad skal kunne gendannes?
En server består af lag. Ikke alle lag behøver at være med i backuppen:
| Lag | Eksempel | Backup? |
|---|---|---|
| Styresystem og pakker | Debian, nginx, PHP | Ikke nødvendigvis: kan installeres igen. Men gem en liste: dpkg --get-selections |
| Konfiguration | /etc (nginx, SSH, firewall, systemd-units), dine compose-filer | Ja, lille og uundværlig |
| Applikationer og websites | /var/www, /opt/<app>, /srv | Ja, medmindre de kommer fra Git |
| Data | databaser, uploads, Docker-volumes (/var/lib/docker/volumes) | Ja, det vigtigste |
| Hemmeligheder | adgangskoder, API-nøgler, selve nøglen til din backup | Ja, men separat og krypteret (se nedenfor) |
| Logs, caches, midlertidige filer | /var/log, /var/cache, /tmp | Normalt ikke |
Vær ekstra opmærksom på databaser. En database, der kører, skriver hele tiden. Kopierer du filerne fra en kørende MariaDB eller PostgreSQL, kan du få en beskadiget kopi. Lav derfor først et dump: et konsistent øjebliksbillede som fil, som du derefter tager med i backuppen.
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 hed tidligere mysqldump; den kommando virker som regel stadig.) Kører databasen i en container, gør du det samme med docker compose exec (lektion 9.4).
RPO og RTO: hvor meget må du miste?
To begreber fra fagets praksis hjælper dig med at træffe valg:
- RPO (recovery point objective): hvor meget tid med data må du højst miste? En daglig backup kl. 03:00 betyder: crasher serveren kl. 22:00, har du mistet næsten et døgn. For en webshop med ordrer er det for meget; for en blog, der ændres en gang om ugen, er det fint.
- RTO (recovery time objective): hvor lang tid må der gå, før alt virker igen? At gendanne en fuld backup fra udbyderen kan tage minutter; at bygge en ny server op og gendanne alt i hånden kan tage timer.
Skriv dem ned for din egen server. De afgør, hvor tit du tager backup, og hvordan du opbevarer den.
Snapshot, udbyderens backup, egen backup
På en VPS har du som regel tre slags sikkerhedsnet. De ligner hinanden, men beskytter mod forskellige ting.
1. Snapshottet. Et øjebliksbillede af hele den virtuelle disk, lavet i din udbyders panel. Hurtigt at lave, hurtigt at gendanne. Ideelt lige før en opgradering (lektion 4.3). Men: hos de fleste udbydere ligger et snapshot på samme lager som din server. Går det lager i stykker, eller mister du din konto, er snapshottet også væk. Og et snapshot gemmer du ikke længe: det vokser med alle ændringer bagefter. Et snapshot er ikke en backup.
2. Udbyderens backup. Mange udbydere laver (eventuelt som tilvalg) automatisk hver dag en kopi af hele din server på et andet lager. Hos WebOké er det for eksempel en daglig backup af hele din VPS, som gemmes i syv dage; hos andre udbydere fungerer det på lignende måde med deres egne perioder. Det er et godt andet lag mod defekt hardware og mod dine egne fejl fra i går. Men det er stadig én part: din konto, din betaling, deres nedbrud. Og gendannelse sker som regel for hele serveren på én gang.
3. Din egen backup uden for udbyderen. En kopi af dine data hos en anden part eller et andet sted, som du selv laver og administrerer (lektion 8.2). Det er det lag, der er tilbage, når alt andet går galt.
3-2-1-reglen
En udbredt tommelfingerregel:
- 3 kopier af dine data (originalen plus to backups);
- på 2 forskellige typer lager eller systemer;
- hvoraf 1 ligger et andet sted.
For en VPS kan det være: dataene på serveren, udbyderens daglige backup og en krypteret egen backup med restic til lager hos en anden part. En moderne tilføjelse er, at mindst én kopi ikke kan slettes af den, der overtager serveren (offline eller append-only, lektion 8.2). Ransomware på en server leder aktivt efter backups for også at kryptere eller slette dem. En backup, som serveren selv må slette, beskytter ikke mod det.
Kryptering og adgangskoden til din backup
En backup hos en anden part skal være krypteret: der ligger kundedata, adgangskoder og nøgler i den. restic (lektion 8.2) krypterer som standard. Men dermed opstår en ny risiko: adgangskoden til din backup. Mister du den, er backuppen ubrugelig. Og ligger den kun på den server, du har mistet, er den også væk.
Gem derfor adgangskoden uden for serveren: i din password manager og eventuelt på papir i et pengeskab. Det samme gælder adgangsoplysningerne til det lager, hvor din backup ligger.
Test gendannelse
Den vigtigste del af planen. En gendannelsestest betyder: du gendanner faktisk en backup et sted, hvor det ikke ødelægger noget, og du kontrollerer, at resultatet virker.
- Lille og tit: gendan én fil eller én mappe til
/tmp/terugog sammenlign (diff). For eksempel en gang om måneden. - Stor og af og til: byg en komplet ny testserver op fra backuppen, importér databasen, start websitet. For eksempel en gang om året eller ved hver større ændring. Det er samtidig øvelsen til den dag, hvor det virkelig går galt (lektion 10.3).
Skriv ned, hvor lang tid det tog: det er din reelle RTO.
Opbevaringsperioder
Gem ikke kun den seneste backup. Opdager du først efter to uger, at en fil er beskadiget eller slettet, har du brug for en backup fra for tre uger siden. Et udbredt skema: syv daglige, fire ugentlige og seks månedlige versioner. restic klarer det med forget (lektion 8.2). Tænk også på GDPR (databeskyttelsesforordningen): personoplysninger gemmer du ikke længere end nødvendigt, heller ikke i backups. Skriv dine opbevaringsperioder ned.
I praksis
Brug din udbyders snapshot lige før risikable ændringer, og slet det bagefter; lad udbyderens daglige backup være slået til, hvis den findes; og lav derudover din egen krypterede backup af data og konfiguration til en anden part. Hos WebOké hedder det Snapshots og Backups på VPS-siden; hos andre udbydere er navne og perioder anderledes, men princippet er det samme. En hostingpakke eller en administreret tjeneste har ofte andre aftaler: se, hvad der er aftalt i dit tilfælde.
Opsummering
- En backup er først noget værd, når gendannelse virker; begynd med en plan, og slut med en test.
- Tag især backup af data og konfiguration: databaser som dump,
/etc, websites, Docker-volumes, compose-filer. - Fastlæg RPO (hvor meget må du miste) og RTO (hvor hurtigt skal det virke).
- Snapshot (samme lager, kort tid), udbyderens backup (andet lager, samme part) og en egen backup uden for udbyderen er tre forskellige lag; følg 3-2-1-reglen med mindst én kopi, som serveren ikke selv kan slette.
- Kryptér, gem backupadgangskoden uden for serveren, og test gendannelse: lille og tit, stor af og til.
Quiz
Opgave
Opgave O8.1: Din backupplan. Lav en backupplan på én side for din egen server: hvad skal kunne gendannes (pr. lag), din RPO og RTO, hvilke kopier du har (snapshot, udbyder, egen) og hvor, dine opbevaringsperioder, hvor backupadgangskoden ligger, og hvornår du laver en gendannelsestest. Udfyld formularen; når du har sendt den, ser du en eksempelplan, som du kan sammenligne din egen plan med.
Opgave O8.1: Din backupplan
Denne opgave laver du selv; ingen tjekker den. Afkryds hvad du har gjort, og markér opgaven som udført.
Databaser med et dump, ikke som løse filer fra en kørende database. Dagligt krypteret (restic) til en anden udbyder; snapshot kun omkring ændringer. 7 daglige, 4 ugentlige og 6 månedlige versioner er en god start. Hver måned en lille gendannelse, hvert år en fuld genopbygning. Skriv aldrig en rigtig adgangskode her.
Dine afkrydsninger og noter forbliver kun i denne browser; vi sender dem ingen steder hen. Er du logget ind, gemmer vi kun i Mine kurser, at du har udført opgaven.
Læs mere
- Snapshots og backups af din VPS
- Backupstrategi: 3-2-1-reglen for din egen virksomhed
- Gratis kursus Sikker online for virksomheder 6.1: 3-2-1-reglen, og hvad du skal tage backup af
- Gratis kursus Sikker online for virksomheder 6.2: Backup, der overlever 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
- VPS: fra første login til sikker server 1.5: Snapshots: et sikkerhedsnet til hver stor ændring
- VPS: fra første login til sikker server 1.6: Gendan backup fra WebOké
