Kort sagt: En hållbar backupstrategi för servrar följer 3-2-1-regeln: tre kopior, två lagringstyper, en kopia utanför huset. För att säkerhetskopior ska överleva ett angrepp behöver minst en kopia skydd mot radering från själva servern. Och först ett lyckat återställningstest visar att säkerhetskopian fungerar när det är allvar.
Vad 3-2-1-regeln betyder
3-2-1-regeln är en enkel, sedan år beprövad princip för datasäkerhetskopiering:
- 3 kopior: originaldata och två säkerhetskopior.
- 2 lagringstyper: till exempel lokal disk och objektlagring, eller serverlagring och band.
- 1 kopia utanför huset: på en annan plats, hos en annan leverantör eller offline.
För webbservrar betyder det konkret: En säkerhetskopia på samma hårddisk som webbplatsen räknas inte som en självständig kopia. Faller servern bort eller komprometteras den är båda förlorade. För ledningen lyder kärnfrågan därför inte ”Har vi säkerhetskopior?” utan ”Kan vi återställa driften från en kopia som incidenten inte nådde?”
En backupstrategi för servrar som överlever ett angrepp
Angripare vet att säkerhetskopior gör deras arbete om intet. Den som har åtkomst till en server söker därför ofta också efter säkerhetskopior för att radera eller kryptera dem. En modern strategi utvidgar därför ofta 3-2-1-regeln till 3-2-1-1-0: en kopia till offline eller oföränderlig, och noll fel vid återställningstestet.
Tre grundprinciper gör säkerhetskopior motståndskraftiga:
- Pull i stället för push: Ett separat backupsystem hämtar data från webbservern. Webbservern själv har inga inloggningsuppgifter med vilka den kunde radera säkerhetskopior.
- Oföränderlighet: Objektlagring med lagringsspärr eller ögonblicksbilder som inte går att radera under en fastställd tid.
- Åtskilda åtkomster: Backupkontot är inte detsamma som hostingkundkontot och har en egen andra faktor.
Kryptera säkerhetskopior som ligger utanför huset och förvara nyckeln åtskilt. En förlorad nyckel gör säkerhetskopian oanvändbar, en medlagrad nyckel gör krypteringen värdelös.
Vad som måste säkras
Vid webbservrar säkras ofta bara webbroten. För en fullständig återställning saknas då viktiga delar.
| Område | Exempel | Anmärkning |
|---|---|---|
| Applikationsfiler | Webbrot, uppladdningar, teman, tillägg | Uppladdningar ändras ofta |
| Databaser | MySQL/MariaDB, PostgreSQL | säkra konsekvent, kopiera inte bara filer |
| Konfiguration | Webbserver, PHP-FPM-pooler, php.ini, cronjobb | behövs för snabb ominstallation |
| Certifikat och nycklar | TLS-certifikat, applikationsnycklar | förvara krypterat och åtskilt |
| Dokumentation | Åtkomster, beroenden, förlopp för återställningen | utan den tar varje ominstallation längre tid |
Exempel: säkra databas och filer
Följande exempel visar grundbyggstenarna i en daglig säkerhetskopiering. I praktiken tar ett backupverktyg med kryptering, deduplicering och lagringsregler över överföringen utanför huset.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Säkra databasen konsekvent; inloggningsuppgifter från skyddad fil, inte i kommandot
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# Applikationsfiler och konfiguration
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Kontrollsummor för senare kontroll
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
Filen .backup-my.cnf innehåller inloggningsuppgifterna för en databasanvändare som bara får läsa och har rättigheterna 0600. --single-transaction ger för InnoDB-tabeller en konsekvent nivå utan att stoppa butiken.
Därefter överför ett separat system säkerhetskopian utanför huset. Viktigt är att det steget övervakas: Ett backupjobb som tyst misslyckats i flera dagar märks annars först när det är allvar. Ett dagligt meddelande om lyckat resultat, storlek och varaktighet räcker, så länge någon läser det och följer upp avvikelser.
Använder ni dessutom webbhotellets säkerhetskopior eller ögonblicksbilder, klarlägg skriftligt hur länge de sparas, om ni själva kan återställa och om säkerhetskopiorna finns kvar vid ett uppsagt eller spärrat konto. De kopiorna är ett bra komplement men ersätter ingen egen, oberoende säkerhetskopia.
Lagring: varför äldre nivåer är viktiga efter PHP2Shell
Efter ett angrepp är inte den senaste säkerhetskopian den mest värdefulla utan den senaste rena. Vid PHP2Shell observerades enligt mediarapporter ett första angreppsförsök den 17 oktober 2026, patcharna kom den 21 oktober 2026. Den som bara sparar sju dagar har kanske ingen nivå kvar som med säkerhet ligger före det möjliga intrånget.
Ett beprövat schema kombinerar flera tidsperioder, till exempel dagliga säkerhetskopior i några veckor, veckovisa i några månader och månadsvisa i ett år. De exakta tidsperioderna beror på ert skyddsbehov och på raderingsskyldigheter inom dataskyddet.
Viktigt är också: En säkerhetskopia från tiden efter ett intrång kan innehålla webshells eller ändrade filer. Återställ aldrig blint efter en incident, utan jämför filer med en ren nivå och granska dem innan webbplatsen går online igen. Anvisningar om vad ni ska vara uppmärksamma på finns under Tecken på komprometterad server. En patch tar inte bort insmugglad skadlig programvara, och en säkerhetskopia gör det inte heller av sig själv.
Testa och dokumentera återställningen
En säkerhetskopia utan test är ett antagande. Först återställningen visar om alla delar finns, om nyckeln fungerar och hur lång tid förloppet faktiskt tar.
- Återställ regelbundet en fullständig säkerhetskopia i en testmiljö, inklusive databas och konfiguration.
- Kontrollera att webbplatsen därefter fungerar fullt ut: inloggning, beställningar, formulär, e-post.
- Mät varaktigheten och anteckna vilka steg som var manuella. Jämför resultatet med den tid som er verksamhet som längst klarar sig utan webbplats.
- Lägg anvisningen för återställningen där den går att nå även när servern är nere, till exempel i it-nödlägesplanen.
Hur hjälper PHP SOS konkret?
- Vi granskar era befintliga säkerhetskopior efter fullständighet, lagring, separation från servern och skydd mot radering.
- Vi sätter upp en 3-2-1-säkerhetskopiering med oföränderlig kopia och testar återställningen tillsammans med er.
- Efter en incident identifierar vi den senaste rena nivån och återställer den på ett patchat system inom ramen för borttagningen av skadlig kod.
- I säkerhetsunderhållsavtalet övervakar vi säkerhetskopiorna löpande och genomför regelbundna återställningstester.
Vanliga frågor
Vad betyder 3-2-1-regeln vid säkerhetskopiering?
Tre kopior av era data, på två olika lagringstyper, varav en på en annan plats. Regeln ser till att varken ett maskinvarufel, ett angrepp eller en brand drabbar alla kopior samtidigt.
Räcker mitt webbhotells säkerhetskopia?
Den är ett bra komplement men sällan tillräcklig. Klarlägg hur länge webbhotellet sparar nivåer, om ni själva kan återställa och om en angripare med ert kundkonto skulle kunna radera säkerhetskopiorna. En egen, oberoende kopia rekommenderas.
Kan jag efter en hackning bara återställa den senaste säkerhetskopian?
Bara med försiktighet. Den senaste säkerhetskopian kan redan innehålla skadlig kod, och sårbarheten som angriparen kom in genom är därefter fortfarande öppen. Klarlägg och stäng först orsaken, återställ sedan en granskad nivå på ett patchat system.
Hur ofta bör jag testa återställningen?
Regelbundet och efter större ändringar i systemet. En fast rytm, till exempel en fullständig återställning per kvartal i en testmiljö, har visat sig fungera. Viktigt är att testet dokumenteras och att luckor åtgärdas.