Kort sagt: En bæredygtig backupstrategi til servere følger 3-2-1-reglen: tre kopier, to lagringstyper, én kopi uden for huset. For at backups også overlever et angreb, skal mindst én kopi være beskyttet mod sletning fra serveren selv. Og først en vellykket genoprettelsestest viser, at sikringen fungerer i en nødsituation.
Hvad 3-2-1-reglen betyder
3-2-1-reglen er et enkelt, i årevis gennemprøvet princip for datasikring:
- 3 kopier: de originale data og to sikkerhedskopier.
- 2 lagringstyper: for eksempel lokal disk og objektlager, eller serverlager og bånd.
- 1 kopi uden for huset: på et andet sted, hos en anden udbyder eller offline.
For webservere betyder det konkret: En sikkerhedskopi på samme harddisk som websitet tæller ikke som en selvstændig kopi. Falder serveren ud, eller bliver den kompromitteret, er begge tabt. For ledelsen lyder kernespørgsmålet derfor ikke „Har vi backups?“, men „Kan vi genoprette driften fra en kopi, som hændelsen ikke har nået?“
En backupstrategi til servere, der overlever et angreb
Angribere ved, at backups gør deres arbejde til intet. Den, der har adgang til en server, leder derfor ofte også efter sikkerhedskopier for at slette eller kryptere dem. En moderne strategi udvider derfor ofte 3-2-1-reglen til 3-2-1-1-0: en kopi yderligere offline eller uforanderlig, og nul fejl ved genoprettelsestesten.
Tre grundprincipper gør backups modstandsdygtige:
- Pull i stedet for push: Et særskilt backupsystem henter dataene fra webserveren. Webserveren selv har ingen adgangsdata, hvormed den kunne slette backups.
- Uforanderlighed: Objektlager med opbevaringsspærre eller snapshots, som ikke kan slettes i en fastlagt tid.
- Adskilte adgange: Backupkontoen er ikke den samme som hostingens kundekonto og har en egen anden faktor.
Kryptér backups, der ligger uden for huset, og opbevar nøglen adskilt. En tabt nøgle gør backuppen ubrugelig, en nøgle, der er gemt med, gør krypteringen værdiløs.
Hvad der skal sikres
Ved webservere sikres ofte kun webroot. Til en fuldstændig genoprettelse mangler der så vigtige dele.
| Område | Eksempler | Henvisning |
|---|---|---|
| Applikationsfiler | Webroot, uploads, temaer, udvidelser | Uploads ændres hyppigt |
| Databaser | MySQL/MariaDB, PostgreSQL | sikr konsistent, kopiér ikke kun filer |
| Konfiguration | Webserver, PHP-FPM-pools, php.ini, cronjobs | nødvendig til hurtig genopbygning |
| Certifikater og nøgler | TLS-certifikater, applikationsnøgler | læg dem krypteret og adskilt |
| Dokumentation | Adgange, afhængigheder, forløb ved genoprettelse | uden den tager enhver genopbygning længere |
Eksempel: sikr database og filer
Det følgende eksempel viser grundbyggestenene i en daglig sikring. I praksis overtager et backupværktøj med kryptering, deduplikering og opbevaringsregler overførslen uden for huset.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Sikr databasen konsistent; adgangsdata fra beskyttet fil, ikke i kommandoen
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# Applikationsfiler og konfiguration
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Kontrolsummer til senere kontrol
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
Filen .backup-my.cnf indeholder adgangsdata for en databasebruger, der kun må læse, og har rettighederne 0600. --single-transaction sørger ved InnoDB-tabeller for en konsistent status, uden at shoppen standses.
Derefter overfører et særskilt system sikkerhedskopien uden for huset. Vigtigt er, at dette trin overvåges: Et backupjob, der i dagevis fejler stille, opdages ellers først i en nødsituation. En daglig meddelelse om succes, størrelse og varighed er nok, så længe nogen læser den og følger op på afvigelser.
Bruger I desuden backups eller snapshots fra jeres hoster, så afklar skriftligt, hvor længe de opbevares, om I selv kan genoprette, og om sikkerhedskopierne bevares ved en opsagt eller spærret konto. Disse kopier er et godt supplement, men erstatter ikke en egen, uafhængig sikring.
Opbevaring: hvorfor ældre status er vigtig efter PHP2Shell
Efter et angreb er ikke den nyeste backup den mest værdifulde, men den nyeste rene. Ved PHP2Shell blev der ifølge medierapporter den 17.10.2026 observeret et første angrebsforsøg, rettelserne udkom den 21.10.2026. Den, der kun opbevarer i syv dage, har måske ikke længere en status, der med sikkerhed ligger før det mulige indbrud.
Et gennemprøvet skema kombinerer flere tidsrum, for eksempel daglige sikringer i nogle uger, ugentlige i nogle måneder og månedlige i et år. De præcise tidsrum retter sig efter jeres beskyttelsesbehov og efter sletningspligter fra databeskyttelsen.
Vigtigt er også: En backup fra tiden efter et indbrud kan indeholde webshells eller ændrede filer. Spil efter en hændelse aldrig blindt tilbage, men sammenhold filer med en ren status, og kontrollér dem, før websitet kommer online igen. Henvisninger til, hvad I skal være opmærksomme på, finder I under Tegn på kompromittering. En patch fjerner ikke indsmuglet skadelig software, og en backup gør det heller ikke af sig selv.
Test og dokumentér genoprettelsen
En backup uden test er en antagelse. Først genoprettelsen viser, om alle dele er til stede, om nøglen virker, og hvor længe forløbet faktisk tager.
- Spil regelmæssigt en fuldstændig sikkerhedskopi ind i et testmiljø, inklusive database og konfiguration.
- Kontrollér, om websitet bagefter fungerer fuldstændigt: login, bestillinger, formularer, mails.
- Mål varigheden, og notér, hvilke trin der var manuelle. Sammenhold resultatet med den tid, jeres drift højst kan undvære websitet.
- Læg vejledningen til genoprettelse, hvor den også kan nås, når serveren er udfaldet, for eksempel i IT-nødplanen.
Hvordan hjælper PHP SOS konkret?
- Vi gennemgår jeres eksisterende backups for fuldstændighed, opbevaring, adskillelse fra serveren og beskyttelse mod sletning.
- Vi opsætter en 3-2-1-sikring med uforanderlig kopi og tester genoprettelsen sammen med jer.
- Efter en hændelse identificerer vi den sidste rene status og genopretter den på et patchet system som led i malwarefjernelsen.
- I sikkerhedsvedligeholdelsesaftalen overvåger vi sikringerne løbende og gennemfører regelmæssige genoprettelsestests.
Ofte stillede spørgsmål
Hvad betyder 3-2-1-reglen ved backups?
Tre kopier af jeres data, på to forskellige lagringstyper, hvoraf én på et andet sted. Reglen sørger for, at hverken et hardwaredefekt, et angreb eller en brand rammer alle kopier samtidig.
Er min hosters backup nok?
Den er et godt supplement, men sjældent tilstrækkelig. Afklar, hvor længe hosteren opbevarer status, om I selv kan genoprette, og om en angriber med adgang til jeres kundekonto kunne slette backupperne. En egen, uafhængig kopi er at anbefale.
Kan jeg efter et hack bare spille den seneste backup tilbage?
Kun med forsigtighed. Den seneste backup kan allerede indeholde skadelig kode, og den sårbarhed, som angriberen kom ind gennem, er derefter stadig åben. Afklar og luk først årsagen, spil derefter en kontrolleret status tilbage på et patchet system.
Hvor ofte bør jeg teste genoprettelsen?
Regelmæssigt og efter større ændringer af systemet. En fast rytme, f.eks. en fuldstændig genoprettelse pr. kvartal i et testmiljø, har vist sit værd. Vigtigt er, at testen dokumenteres, og at huller udbedres.