Immutabel Backup Mot Ransomware: 12 Steg, 90 Min [2026]

Ransomware-grupper publicerade 152 svenska offer på sina läcksajter i slutet av augusti 2026, upp från 135 bara två månader tidigare, enligt Ransomware.live. Samtidigt visar Check Points siffror att svenska verksamheter drabbades av 2 432 cyberattacker i veckan under juni 2026, en ökning med 40 procent jämfört med samma månad året innan. Globalt namngavs 4 472 organisationer på läcksajter under första halvåret 2026, ungefär 745 i månaden, eller ett nytt offer var timme. Den enda försvarslinje som konsekvent fungerar när kryptering redan har slagit till är en backup som angriparen inte kan röra. Den här guiden visar hur du bygger en sådan, steg för steg, med verktyg som redan är gratis och öppen källkod.

Vi går igenom 3-2-1-1-0-regeln, sätter upp restic och MinIO med Object Lock, schemalägger jobben, bygger larm för trasiga körningar och avslutar med en återställningsrunbook som du faktiskt testar. Målgruppen är IT-drift och säkerhetsansvariga på små och medelstora nordiska organisationer som behöver ett tekniskt fungerande skydd, inte bara en policy på papper.

Guiden tar cirka 90 minuter att genomföra från start till en verifierad, schemalagd backup, förutsatt att du redan har en server eller virtuell maskin tillgänglig. Räkna med ytterligare tid första gången ni kör en full återställningsövning, eftersom syftet med den övningen är att mäta hur lång tid processen faktiskt tar, inte att den ska gå snabbt. Allt som beskrivs går att köra på egen hårdvara, hos en nordisk molnleverantör eller hos någon av de stora internationella aktörerna. Verktygen är identiska oavsett var infrastrukturen står.

Hotbilden i augusti 2026: fler grupper, kortare tid till kryptering

Ekosystemet av aktiva ransomware- och utpressningsgrupper fortsätter att växa. Black Kite räknade 146 aktiva grupper i juni 2026, mer än dubbelt så många som de 61 grupperna som var aktiva 2023. Qilin stod för den kraftigaste ökningen i antal, med 1 358 offer under första halvåret, en uppgång på 443 procent jämfört med året innan. Under själva juni månad tog dock The Gentlemen täten med 94 registrerade offer, följt av nykomlingen DeadLock med 81 och Qilin på tredje plats med 71, enligt Breachsense ransomware-rapport för juni 2026.

Taktiken är i stort sett oförändrad men mer effektiv: dubbel utpressning, där data först stjäls och sedan krypteras, följt av hot om publicering om offret vägrar betala eller helt enkelt återställer från backup. Det är just den sista biten som gör traditionella backuper otillräckliga. Om en angripare med administratörsbehörighet kan radera eller kryptera dina backupfiler innan de upptäcks, spelar det ingen roll hur ofta du tar dem. Lösningen är immutabilitet, alltså backupkopior som inte går att ändra eller radera under en bestämd period, oavsett vilken behörighet angriparen har lyckats stjäla.

Initial access varierar mellan grupperna men landar oftast i samma kategorier: sårbara VPN-tjänster och ESXi-hypervisorer (särskilt kopplat till Akira), phishing mot enskilda anställda, och exploatering av redan kända sårbarheter som legat opatchade. Det sistnämnda knyter direkt an till CISA:s KEV-katalog, där en betydande andel av vulnerabiliteterna som läggs till varje månad senare kopplas till just ransomware-kampanjer. Att patcha snabbt och att ha en backup som inte kan förstöras är två sidor av samma försvar, det ena minskar sannolikheten för intrång, det andra begränsar skadan när intrånget ändå sker.

Ett konkret svenskt exempel är Hornavan Hotell, som drabbades av gruppen DeadLock i juni 2026 (attack uppskattad till den 11 juni, upptäckt fyra dagar senare). Ett annat offer registrerades så sent som den 7 augusti 2026, upptäckt två veckor senare, enligt samma källa. Mönstret är tydligt: det är inte bara storbolag som blir mål, utan även hotell, kommuner och mindre tjänsteföretag i hela Norden.

Global sett fortsätter volymen att vara hög trots att enskilda månader svänger. CyberXTron räknade 707 offer globalt i juni 2026, en nedgång på 10,4 procent från majs 789, efter en topp på 867 i april. Det är fortfarande en bråkdel av den totala skadan, eftersom siffrorna bara omfattar organisationer som faktiskt namnges på en läcksajt. Grupper som enbart stjäl data utan att kryptera något, ibland kallade “extortion-only”, räknas ofta inte alls i traditionell ransomware-statistik trots att de skapar samma typ av kris för det drabbade företaget. Det här är en viktig nyans: en immutabel backup löser driftstoppet men gör ingenting åt en redan stulen kunddatabas. De två hoten kräver olika försvar, och den här guiden fokuserar på det förstnämnda.

Rank (juni 2026)	Grupp	Offer i juni	Förändring från maj
1	The Gentlemen	94	+24
2	DeadLock	81	Ny grupp
3	Qilin	71	-30
4	LockBit 5.0	43	+25
5	Akira	30	-22
6	INC_RANSOM	29	-1
7	DragonForce	29	-12
8	Nova	28	+5

Vad är 3-2-1-1-0-regeln?

Den klassiska 3-2-1-regeln har funnits sedan 2000-talet: tre kopior av data, på två olika typer av media, varav en förvaras på annan plats. Med ransomware som ständigt hot har säkerhetsbranschen byggt vidare på formeln med två extra siffror. Den utökade varianten kallas 3-2-1-1-0 och är numera vad som förväntas vid NIS2-relaterade granskningar i EU.

Siffra	Betydelse	Praktiskt exempel
3	Tre kopior av datan totalt	Produktionsdata, lokal backup, molnbackup
2	Två olika typer av lagringsmedia	Lokal disk plus objektlagring i molnet
1	En kopia förvarad på annan plats	Objektlagring i annan region eller hos annan leverantör
1	En air-gapped eller immutabel kopia	MinIO eller S3 med Object Lock i Compliance-läge
0	Noll oupptäckta fel vid återställningstest	Dokumenterad, testad återställning minst en gång per år

Den sista siffrans “0” är den del flest organisationer missar. Det räcker inte att backuperna körs och rapporterar grönt i loggen. Ni måste faktiskt återställa en fullständig kopia och verifiera att den fungerar. Ett backup-jobb som “lyckas” i tre år men aldrig testas är i praktiken en gissning, inte en säkerhetsåtgärd.

Förutsättningar: verktyg, versioner och behörigheter

Den här guiden bygger på fri programvara som du kan köra på egen hårdvara eller hos valfri molnleverantör. Du behöver root- eller sudo-access på minst en Linux-server (Ubuntu 24.04 LTS eller nyare fungerar bra), samt möjlighet att skapa en användare med begränsad behörighet som backup-jobbet ska köras som. Kör aldrig backup-agenten som samma administratörskonto som resten av infrastrukturen. Det är precis det kontot en angripare letar efter.

Verktyg	Version som används i guiden	Senast uppdaterad	Roll
restic	v0.19.1	2026-07-05	Krypterad, deduplicerad backup-klient
BorgBackup	1.4.5	2026-07-18	Alternativ backup-klient för lokala repon
MinIO (Community Edition)	Senaste stabila utgåvan	Kontrolleras vid installation	S3-kompatibelt objektlager med Object Lock
AWS CLI	v2 (senaste)	Kontrolleras vid installation	Hantera S3 Object Lock i molnet
systemd	Ingår i Ubuntu 24.04	–	Schemaläggning av backup- och testjobb

Om ni hellre kör allt i molnet räcker det att byta ut MinIO-stegen mot Amazon S3 eller en S3-kompatibel tjänst som stöder Object Lock, till exempel Wasabi eller Backblaze B2. Principen är identisk: skriv en gång, lås objektet, förhindra radering under en bestämd period.

restic eller BorgBackup: vilket verktyg passar er miljö?

Guiden använder restic som huvudverktyg eftersom det har inbyggt stöd för S3-kompatibel lagring utan extra tillägg och en enkel kommandoradsyntax. BorgBackup är minst lika moget men kräver ett SSH-baserat repo eller en extra proxy för att nå objektlagring, vilket gör konfigurationen något mer komplex i den här specifika uppsättningen. Borgs styrka ligger i dess deduplicering, som ofta är effektivare än restics på stora mängder liknande filer, exempelvis virtuella maskin-avbilder.

Egenskap	restic v0.19.1	BorgBackup 1.4.5
Nativt S3-stöd	Ja, inbyggt	Nej, kräver rclone eller SSH-proxy
Kryptering	AES-256, alltid på	AES-256 eller ChaCha20-Poly1305
Deduplicering	Blocknivå	Blocknivå, ofta effektivare på stora VM-avbilder
Parallell återställning	Ja	Begränsat
Lämplig för denna guide	Ja, förstahandsval	Bra komplement för specifika arbetslaster

För de flesta nordiska små och medelstora organisationer räcker restic som ensamt verktyg. Lägg bara till Borg om ni redan har arbetslaster där dess specifika deduplicering ger en tydlig fördel, exempelvis stora, likartade virtuella maskiner som byggs om ofta.

Steg 1: Kartlägg kritiska system och sätt RTO och RPO

Innan du skriver en enda rad kod behöver du veta vad som faktiskt måste överleva en attack. Lista era system efter verksamhetskritikalitet och sätt två mått per system: RPO (Recovery Point Objective, hur mycket data ni har råd att förlora) och RTO (Recovery Time Objective, hur lång tid återställningen får ta). För de flesta affärssystem räcker en RPO på 24 timmar, alltså daglig backup. För system som databaser med hög transaktionsvolym kan ni behöva inkrementella backuper varje timme.

• Kritiska system (ERP, kunddatabas, autentisering): RPO 1–4 timmar, RTO under 8 timmar
• Viktiga system (interna verktyg, filservrar): RPO 24 timmar, RTO under 24 timmar
• Övriga system (testmiljöer, arkiv): RPO 1 vecka, RTO under 72 timmar

Dokumentera detta i ett enkelt kalkylark innan ni går vidare. Hela resten av den tekniska uppsättningen härleds från de här siffrorna, inte tvärtom.

Steg 2: Installera restic och skapa ett krypterat repo

Restic krypterar all data innan den lämnar servern, deduplicerar automatiskt och stöder ett tiotal olika lagringsmål, inklusive S3-kompatibel lagring. Installera senaste versionen direkt från GitHub-releasen eller via paketansvarig för din distribution.

# Ladda ner och installera restic v0.19.1 på Ubuntu/Debian
curl -L -o restic.bz2 https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic.bz2
chmod +x restic_0.19.1_linux_amd64
sudo mv restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

# Skapa en dedikerad backup-användare utan sudo-rättigheter
sudo useradd -r -m -d /var/lib/backupsvc backupsvc
sudo -u backupsvc mkdir -p /var/lib/backupsvc/.config/restic

Spara lösenordet till repot i en separat hemlighetshanterare, aldrig i klartext i skriptet. Om ni inte redan har ett verktyg för det räcker en krypterad fil med restriktiva filrättigheter (chmod 600) som ett minimum för en mindre organisation.

Steg 3: Sätt upp MinIO med Object Lock i Compliance-läge

Det här är kärnan i hela upplägget. MinIO Object Lock bygger på samma WORM-princip (write once, read many) som Amazon S3 Object Lock. En bucket måste skapas med lock aktiverat från start, det går inte att lägga till i efterhand. Det finns två lägen: Governance, där en användare med särskild behörighet kan häva spärren, och Compliance, där ingen, inte ens en administratör, kan radera objektet innan retentionstiden gått ut. För ransomware-skydd ska ni använda Compliance-läge.

# Starta MinIO-servern (körs som egen tjänst, separerad från produktionsnätet)
export MINIO_ROOT_USER=backupadmin
export MINIO_ROOT_PASSWORD=
minio server /data/minio --console-address ":9001"

# Konfigurera mc-klienten mot MinIO-instansen
mc alias set immutable-backup http://10.20.0.5:9000 backupadmin 

# Skapa en bucket MED object lock aktiverat direkt vid skapandet
mc mb --with-lock immutable-backup/restic-repo

# Sätt standardretention till Compliance-läge, 35 dagar
mc retention set --default compliance 35d immutable-backup/restic-repo

35 dagar är ett rimligt startvärde för dagliga backuper. Det ger marginal att upptäcka en attack innan den äldsta immutabla kopian går ur lås. Justera upp om er hotmodell kräver längre detektionstid. Vissa grupper, särskilt de som specialiserar sig på dataexfiltrering innan kryptering, kan ligga tysta i miljön i flera veckor för att kartlägga vilka system som är mest värdefulla att kryptera och vilka backuper som finns tillgängliga att förstöra. En kortare retention gör er sårbara exakt mot den taktiken.

Steg 4: Alternativet med S3 Object Lock i molnet

Vill ni slippa drifta MinIO själva går samma princip att applicera direkt i Amazon S3 eller en S3-kompatibel molntjänst. Skillnaden mot MinIO är i huvudsak var infrastrukturen ligger, inte hur den fungerar.

# Skapa en S3-bucket med object lock aktiverat vid skapandet
aws s3api create-bucket --bucket foretag-immutable-backup --object-lock-enabled-for-bucket

# Sätt standardretention: Compliance-läge, 35 dagar
aws s3api put-object-lock-configuration --bucket foretag-immutable-backup \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":35}}}'

Tänk på att Compliance-läge i S3 inte går att ångra ens av kontots ägare. Testa alltid först mot en separat testbucket innan ni sätter policyn i produktion. Räkna även med extra kostnad för lagring under retentionsperioden, eftersom objekt som är låsta inte kan tas bort för att frigöra utrymme förrän tiden har löpt ut, oavsett hur mycket ni egentligen skulle vilja städa upp i mellantiden.

Steg 5: Skriv backup-skriptet med retention-policy

Nu kopplar vi ihop restic med det immutabla målet och lägger till en tydlig retention-policy som håller reda på hur många dagliga, veckovisa och månatliga snapshots som ska sparas.

#!/usr/bin/env bash
set -euo pipefail

export RESTIC_REPOSITORY="s3:http://10.20.0.5:9000/restic-repo"
export RESTIC_PASSWORD_FILE="/var/lib/backupsvc/.config/restic/password"
export AWS_ACCESS_KEY_ID="backupadmin"
export AWS_SECRET_ACCESS_KEY_FILE="/var/lib/backupsvc/.config/restic/secret"

LOGFILE="/var/log/backupsvc/restic-$(date +%F).log"

restic backup /var/data/produktion /etc --tag dagligt >> "$LOGFILE" 2>&1
RESTIC_EXIT=$?

# Behåll 7 dagliga, 4 veckovisa och 12 månatliga snapshots
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune >> "$LOGFILE" 2>&1

exit $RESTIC_EXIT

Notera att restic forget aldrig kan radera de objekt som fortfarande ligger under aktiv retention i MinIO eller S3, oavsett vad restics egen policy säger. Object Lock vinner alltid över klientens instruktion, vilket är precis poängen.

Steg 6: Schemalägg backuper med systemd timers

Cron fungerar, men systemd-timers ger bättre loggning och gör det enklare att se senaste körning och nästa schemalagda tid direkt i systemet.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Daglig immutabel backup med restic

[Service]
Type=oneshot
User=backupsvc
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Kör restic-backup varje natt kl 02:00

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

Steg 7: Lägg till en air-gapped offline-kopia

Object Lock skyddar mot radering från nätverket, men en riktigt paranoid uppsättning lägger till en fysiskt frånkopplad kopia som komplement. Det behöver inte vara komplicerat: en extern disk som ansluts manuellt en gång i veckan, synkas, och sedan kopplas bort helt är fortfarande ett av de mest effektiva skydden som finns. Ingen mjukvara i världen kan kryptera en disk som inte sitter i uttaget.

# Manuell veckovis synk till frånkopplingsbar disk (körs av en människa, inte automatiskt)
restic -r /mnt/offline-disk/restic-repo backup /var/data/produktion --tag veckovis
# Efter synk: koppla loss disken fysiskt och förvara den separat från serverrummet

Ju mer automatiserat det här steget är, desto mindre “air gap” har ni egentligen. Håll det manuellt med vilje.

Steg 8: Verifiera integritet med restic check

En backup som aldrig verifieras kan vara trasig i månader utan att någon märker det. Lägg till en fristående kontroll som körs efter varje backup-jobb.

# Verifiera reposets struktur och att en delmängd av datablocken faktiskt går att läsa
restic check --read-data-subset=5%

# En gång i månaden: full kontroll av all data (tar längre tid, kör nattetid)
restic check --read-data

Kör --read-data-subset dagligen och den fulla --read-data månadsvis. Det ger en bra balans mellan snabb daglig kontroll och grundlig verifiering utan att belasta nätverket varje natt.

Steg 9: Övervaka backupjobb och larma vid fel

Ett backup-jobb som failar tyst i en logg ingen läser är inte mycket bättre än att inte ha någon backup alls. Skicka statusen till en kanal ni faktiskt bevakar, till exempel Slack eller Microsoft Teams via webhook. Bygg gärna in tre nivåer av larm: ett grönt kvitto varje natt så att ni vet att systemet lever, en varning om jobbet tar avsevärt längre tid än normalt (vilket ofta är ett tidigt tecken på att något i miljön redan är komprometterat eller att en disk håller på att gå sönder), och ett akut larm om jobbet faktiskt misslyckas. Den mellersta nivån är den flesta organisationer missar helt, men den ger ofta första varningen innan en attack blir uppenbar på andra sätt.

#!/usr/bin/env bash
# Läggs till i slutet av restic-backup.sh
if [ $RESTIC_EXIT -ne 0 ]; then
  curl -s -X POST -H 'Content-type: application/json' \
    --data "{\"text\":\"Restic-backup misslyckades på $(hostname), exitkod $RESTIC_EXIT. Se $LOGFILE.\"}" \
    "$SLACK_WEBHOOK_URL"
else
  curl -s -X POST -H 'Content-type: application/json' \
    --data "{\"text\":\"Restic-backup klar på $(hostname) $(date +%F).\"}" \
    "$SLACK_WEBHOOK_URL"
fi

Sätt även upp ett larm som slår till om ingen notis alls har kommit på över 26 timmar. Det fångar upp fall där själva timer-tjänsten har slutat köra helt.

Steg 10: Bygg en testad återställningsrunbook

Runbooken är dokumentet ni öppnar mitt i natten när kryptovirus redan har krypterat filservern. Den ska inte kräva att någon läser en README på GitHub eller minns ett kommando utantill, och den ska fungera även om den person som skrev den är på semester eller inte svarar i telefon. Skriv den så att en tekniker som aldrig satt upp pipelinen ändå kan följa den steg för steg klockan tre på natten. Förvara den både digitalt, på en plats som inte ligger på samma infrastruktur som kan bli krypterad, och i pappersform i ett brandsäkert skåp. Strukturera den i tydliga faser.

• Isolering: koppla bort drabbade system från nätverket omedelbart, innan något annat görs
• Roller: vem leder incidenten, vem pratar med ledningen, vem kontaktar MSB och vem hanterar kommunikation utåt
• Bedömning: vilka system är krypterade, vilka backuper finns, hur gammal är den senaste rena kopian
• Återställning: exakt vilka restic-kommandon som ska köras, i vilken ordning, mot vilket mål
• Verifiering: hur ni kontrollerar att återställda system är rena innan de kopplas tillbaka till nätverket
• Rapportering: tidsfrister för anmälan enligt NIS2 och kontakt med Polisen och IMY vid personuppgiftsincidenter

# Exempel: återställning av ett helt system från senaste rena snapshot
restic snapshots --tag dagligt
restic restore latest --target /mnt/restore-clean --tag dagligt
# Verifiera innan systemet återansluts till produktionsnätet
sha256sum -c /mnt/restore-clean/checksums.txt

Steg 11: Öva återställning kvartalsvis

Det är den här delen de flesta organisationer hoppar över, och det är exakt den delen som gör att 0:an i 3-2-1-1-0 fungerar i verkligheten. Boka in en återkommande kalenderpunkt, inte “när vi har tid”: delrestore av ett kritiskt system varje kvartal och en full återställningsövning minst en gång per år, med dokumenterat resultat.

#!/usr/bin/env bash
# Kvartalsvis automatiserat testrestore till en isolerad testmiljö
set -euo pipefail
TESTMILJO="/mnt/quarterly-restore-test"
restic restore latest --target "$TESTMILJO" --tag dagligt

if diff -rq "$TESTMILJO/etc" /etc/backup-referens > /tmp/restore-diff.log; then
  echo "Återställningstest OK: $(date +%F)" >> /var/log/backupsvc/restore-tests.log
else
  echo "Avvikelse i återställningstest, se /tmp/restore-diff.log" | mail -s "Restore-test avvek" [email protected]
fi

Mät hur lång tid hela processen tog, från kommando till verifierat resultat, och jämför mot det RTO ni satte i steg 1. Om testet tar 14 timmar men ert mål är 8, har ni ett verkligt gap att åtgärda, inte ett papper som säger att allt är i sin ordning.

Steg 12: Koppla resultatet till NIS2-rapportering

Organisationer som omfattas av NIS2 förväntas kunna visa att kontinuitetsplaner faktiskt fungerar, inte bara att de finns. Spara resultatet från varje återställningstest, inklusive datum, uppmätt RTO, eventuella avvikelser och åtgärder som vidtogs. Det här underlaget är precis vad en tillsynsmyndighet eller revisor kommer att efterfråga vid en granskning, och det är samma dokumentation ni behöver internt för att veta om skyddet faktiskt håller.

Bygg en enkel logg, gärna i samma system som ni redan använder för incidenthantering, med en rad per test: datum, vilket system som återställdes, uppmätt tid från start till verifierad drift, och en kort not om vad som gick bra respektive dåligt. Efter fyra kvartal har ni ett faktiskt dataunderlag för hur er organisations verkliga återhämtningsförmåga ser ut, istället för en känsla av att “det borde fungera”.

MSB:s vägledning för samhällsviktiga och viktiga entiteter pekar i samma riktning: segregerade backupmiljöer, regelbundet testade återställningar och en dokumenterad plan för återgång till normal drift. Immutabel lagring täcker den tekniska biten. Den skriftliga, övade runbooken täcker den processuella. Vid en faktisk incident är det också CERT-SE som koordinerar den nationella hanteringen och kan vara en viktig kontakt utöver den interna eskaleringen.

Kostnad och resursbehov: vad kräver det här i praktiken?

Den största kostnaden i upplägget är inte licenser, den är lagringsutrymme och arbetstid. Restic, BorgBackup och MinIO Community Edition är samtliga fria att använda. Det ni betalar för är hårddiskutrymme för den immutabla kopian (dubbelt så mycket som er faktiska datamängd om ni behåller flera generationer), eventuell molnlagringskostnad om ni väljer S3 eller en S3-kompatibel tjänst istället för egen MinIO-server, samt tid för att sätta upp, dokumentera och öva på återställningsrutinen.

Jämfört med en genomsnittlig lösensumma och de återställningskostnader som följer (driftstopp, forensik, juridiskt arbete, eventuella böter), som enligt flera 2025–2026-rapporter ofta blir flera gånger högre än själva lösensumman, är kostnaden för en immutabel backup-pipeline försumbar. Den vanligaste invändningen, “vi har inte tid just nu”, är exakt den invändning som gör nästa incident dyrare än den behövde bli.

Vanliga misstag som gör immutabel backup värdelös

Även en tekniskt perfekt uppsättning kan undermineras av små konfigurationsmisstag. De flesta av dem upptäcks aldrig förrän under en verklig incident, vilket är exakt fel tillfälle att lära sig något nytt om sin egen backup-miljö. Här är de vanligaste vi ser hos organisationer som satt upp immutabel backup men ändå förlorat data vid en attack.

• Governance-läge istället för Compliance: om en administratörsroll kan häva låset, och den rollen komprometteras, är skyddet borta. Använd Compliance för allt som ska vara ransomware-säkert.
• Samma autentiseringsuppgifter överallt: om backup-kontot delar lösenord eller nycklar med produktionsmiljön kan en angripare som redan är inne nå backuparna direkt.
• För kort retention: vissa grupper väntar veckor innan de utlöser krypteringen, för att hinna exfiltrera data ostört. En retention på bara 7 dagar kan redan vara för snålt tilltagen.
• Ingen isolering av backup-nätverket: om backup-servern nås från samma nätverkssegment som resten av infrastrukturen är den ett lika bra mål som allt annat.
• Aldrig testad återställning: det vanligaste misstaget av alla. Backupen “finns” men ingen vet om den går att använda förrän det är för sent.
• Larm som ingen läser: ett Slack-meddelande i en kanal med 40 olästa notiser är inte samma sak som ett larm som når rätt person.

Felsökning: vanliga problem och lösningar

Nedan är de problem som oftast dyker upp vid drift av en immutabel backup-pipeline, och hur ni löser dem. Spara den här listan tillsammans med runbooken, för det är precis den typen av felmeddelanden som dyker upp klockan tre på natten när ingen har tid att googla sig fram till svaret.

• “Access Denied” vid restic forget: objektet ligger fortfarande under aktiv retention. Det är avsett beteende, inte ett fel. Vänta ut retentionsperioden.
• MinIO-bucket kan inte aktivera lock i efterhand: Object Lock måste sättas vid skapandet av bucketen. Skapa en ny bucket med --with-lock och migrera data.
• Restic-backup tar mycket längre tid än förväntat: kontrollera nätverksbandbredden mot MinIO-instansen och överväg att köra restic backup med färre parallella anslutningar under kontorstid.
• restic check rapporterar korrupta pack-filer: kör restic rebuild-index följt av en ny restic check --read-data. Om felet kvarstår, återställ från en äldre snapshot.
• Systemd-timern kör inte som förväntat: kontrollera med systemctl status restic-backup.timer och verifiera att servern faktiskt var påslagen vid schemalagd tid, annars aktivera Persistent=true.
• Slack-webhook ger 404: webhook-URL:en har sannolikt upphört att gälla eller kanalen har tagits bort. Generera en ny från Slack-appens inställningar.
• Återställning stannar på grund av diskutrymme: restore-målet behöver minst lika mycket ledigt utrymme som den okomprimerade datamängden. Använd en separat volym för testrestore, aldrig samma disk som produktionen.
• Object Lock-policyn blockerar en legitim borttagning: det finns ingen genväg i Compliance-läge, det är avsiktligt. Planera retention-tiden efter verksamhetens faktiska behov innan ni sätter policyn, inte efter.

Avancerade tips för mogna säkerhetsteam

När grundpipelinen är på plats finns flera sätt att höja skyddsnivån ytterligare. Separera backup-kontots IAM-behörigheter så att kontot bara får skriva nya objekt, aldrig radera eller lista hela bucketen i klartext. Lägg till en andra, oberoende molnleverantör för offsite-kopian så att en enda leverantörs driftstörning eller komprometterade konto inte slår ut båda kopiorna samtidigt. Använd multifaktorautentisering med hårdvarunyckel för de få konton som faktiskt har rättighet att ändra retention-policyn, inte bara lösenord.

För större miljöer är det värt att komplettera restic med BorgBackup för specifika arbetslaster där dess deduplicering över flera repon passar bättre, och att köra båda mot samma immutabla mål som redundans mot buggar i ett enskilt verktyg. Dokumentera vem som har vilken behörighet i backup-infrastrukturen och granska listan var sjätte månad. Kontot för en anställd som slutat för åtta månader sedan ska inte fortfarande kunna nå backuparna.

Överväg också att öva incidenten som en fullständig tabletop-övning, inte bara en teknisk restore. SANS har länge förespråkat att incidenthanteringsövningar ska inkludera hela kedjan, från upptäckt och isolering till kommunikation och återgång till drift, snarare än att bara testa en enskild teknisk komponent i taget. Bjud in någon utanför IT-avdelningen, till exempel kommunikation eller juridik, till minst en av de årliga övningarna så att hela organisationen vet sin roll när larmet väl går på riktigt.

Om er infrastruktur i huvudsak består av virtuella maskiner i molnet, komplettera filbaserad backup med leverantörens egna immutabla snapshot-funktioner (till exempel AWS Backup Vault Lock eller motsvarande hos Azure och GCP). En snapshot återställer en hel maskin på minuter, medan en filbaserad restore med restic ofta är snabbare för enskilda dokument eller databaser. De två metoderna kompletterar varandra snarare än att ersätta varandra, och en mogen strategi använder båda beroende på vad som ska återställas.

Komplett exempelprojekt: hela pipelinen på en gång

Så här ser hela flödet ut när alla steg är sammansatta, från installation till schemalagd, övervakad och testad backup.

# 1. Installera restic
curl -L -o restic.bz2 https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic.bz2 && chmod +x restic_0.19.1_linux_amd64 && sudo mv restic_0.19.1_linux_amd64 /usr/local/bin/restic

# 2. Skapa immutabel MinIO-bucket
mc mb --with-lock immutable-backup/restic-repo
mc retention set --default compliance 35d immutable-backup/restic-repo

# 3. Initiera restic-repo
restic init --repo s3:http://10.20.0.5:9000/restic-repo

# 4. Aktivera schemaläggning
sudo systemctl enable --now restic-backup.timer

# 5. Kör första manuella backupen och verifiera
restic backup /var/data/produktion --tag dagligt
restic check --read-data-subset=5%

# 6. Testa återställning i isolerad miljö
restic restore latest --target /mnt/quarterly-restore-test --tag dagligt

# 7. Dokumentera resultatet i runbooken med datum och uppmätt RTO

Exempel på utskrift från ett lyckat testrestore ser ut ungefär så här:

$ restic restore latest --target /mnt/quarterly-restore-test --tag dagligt
repository c4a8f21b opened (version 2, compression level auto)
restoring <Snapshot 9e2b7f1c of [/var/data/produktion] at 2026-08-23 02:00:14 by backupsvc@server01>
Summary: Restored 48213 files/dirs (212.4 GiB) in 00:41:07

$ restic check --read-data-subset=5%
using temporary cache in /tmp/restic-check-cache
create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs
read 5% of data pack files
no errors were found

GDPR och immutabel backup: en konflikt värd att planera för

Object Lock i Compliance-läge skapar en juridisk fråga som få tänker på förrän den blir akut: om en registrerad person begär att få sina personuppgifter raderade enligt GDPR, och de uppgifterna ligger i en immutabel backup som inte kan ändras förrän retentionstiden löpt ut, hur uppfyller ni då gallringskravet? Svaret som de flesta dataskyddsombud landar i är att en immutabel backup som inte aktivt bearbetas eller exponeras räknas som en tillfällig, tidsbegränsad avvikelse från gallringsplikten, förutsatt att retentionstiden är rimlig och dokumenterad i förväg som en del av er säkerhetsåtgärd.

Sätt därför retentionstiden med detta i åtanke, inte bara utifrån hur snabbt ni tror att en ransomware-attack upptäcks. En retention på 35–90 dagar är i normalfallet försvarbar. Om ni sätter den till flera år “för säkerhets skull” bygger ni samtidigt in ett gallringsproblem som blir svårt att motivera vid en tillsyn från Integritetsskyddsmyndigheten. Dokumentera resonemanget skriftligt i er registerförteckning, det är den typen av spårbarhet en tillsynsmyndighet efterfrågar, inte en gissning i efterhand.

Så gäller detta för svenska och nordiska organisationer

Sverige toppar inte längre bara nordisk ransomware-statistik i teorin. Siffrorna från 2026 visar över 2 100 rapporterade incidenter under året, och antalet svenska offer på ransomware-läcksajter fortsätter att stiga månad för månad. Kombinationen av NIS2-krav på dokumenterad kontinuitet och en verklig hotbild från grupper som Qilin, The Gentlemen och DeadLock gör immutabel backup till en av de mest kostnadseffektiva åtgärderna en organisation kan vidta. Verktygen som beskrivs här, restic, BorgBackup och MinIO, är samtliga fria att använda, vilket gör att kostnaden i huvudsak ligger i arbetstid, inte licenser.

För verksamheter som omfattas av NIS2 är det värt att stämma av MSB:s vägledning direkt och kontrollera att dokumentationen av återställningstester matchar vad tillsynen förväntar sig, snarare än att gissa. Samma runbook som skyddar mot ett produktionsavbrott är också det underlag ni behöver visa upp vid en eventuell revision.

Vanliga frågor

Räcker det med daglig backup för att skydda mot ransomware?

Nej. Frekvensen avgör hur mycket data ni kan förlora, inte om backupen går att lita på under en attack. Utan immutabilitet kan en angripare med rätt behörighet radera eller kryptera även dagliga backuper innan de upptäcks.

Är MinIO gratis att använda i produktion?

MinIO Community Edition är öppen källkod och fri att köra. Kontrollera alltid aktuella licensvillkor på projektets webbplats innan driftsättning, eftersom villkoren för olika utgåvor kan skilja sig åt.

Vad är skillnaden mellan Governance- och Compliance-läge i Object Lock?

I Governance-läge kan en användare med särskild behörighet häva eller korta ner en spärr. I Compliance-läge går det inte att göra under några omständigheter förrän retentionstiden löpt ut, inte ens för kontots ägare. För ransomware-skydd är Compliance det enda alternativet som ger fullt skydd.

Hur ofta bör vi testa återställning?

Minst en gång per kvartal för kritiska system, med en full återställningsövning minst en gång per år. Det är samma nivå som förväntas vid NIS2-relaterade granskningar.

Kan restic och BorgBackup användas samtidigt?

Ja, flera organisationer kör båda mot samma immutabla mål som redundans, så att en bugg eller sårbarhet i det ena verktyget inte äventyrar hela backup-strategin.

Skyddar immutabel backup mot dataläckage och utpressning?

Nej. Immutabel backup säkerställer att ni kan återställa drift utan att betala lösensumma, men den hindrar inte en angripare som redan har exfiltrerat data från att publicera eller sälja den. Det kräver separata åtgärder som segmentering, kryptering och begränsad datalagring.

Hur lång retention-tid bör vi sätta på immutabla objekt?

35 dagar är ett rimligt startvärde för de flesta organisationer, men om er hotmodell inkluderar grupper som väntar längre innan de utlöser kryptering bör ni överväga 60–90 dagar för de mest kritiska systemen.

Behöver vi fortfarande en fysisk offline-kopia om vi redan har Object Lock?

Det rekommenderas som ett extra lager, särskilt för de mest kritiska systemen. Object Lock skyddar mot radering via nätverket, men en fysiskt frånkopplad kopia är immun mot alla former av nätverksbaserad attack, inklusive sådana som ännu inte är kända.

Vad kostar det att bygga den här pipelinen för en mindre organisation?

Programvaran är gratis. Den huvudsakliga kostnaden blir lagringsutrymme, typiskt två till tre gånger er faktiska datamängd beroende på hur många generationer ni behåller, samt arbetstid för att sätta upp och dokumentera pipelinen, vilket för en van drifttekniker brukar handla om en till två arbetsdagar inklusive den första återställningsövningen.

Relaterad läsning

• Ransomware 2026: Sverige värst i Norden, 60 incidenter
• Ransomware Träffar Lifesum, CISA Lägger Till 8 CVE
• CISA KEV Patchhantering: 12 Steg, 45 Min
• NIS2-incidentplan: 12 Steg, 3-5 Dagar
• EDR vs XDR
• Verizon DBIR 2026: 22 000 Dataintrång, Sårbarhet Tar Täten

Fler artiklar om hotbild, härdning och incidenthantering finns samlade på shattered.io:s säkerhetssida.