En uforanderlig backup er en kopi, som ingen kan slette eller ændre, før en fastsat periode er udløbet. Ordet dækker i praksis tre forskellige ting, nemlig en lås i lageret, en adskilt konto og en kopi uden netforbindelse, og hver af dem beskytter mod noget forskelligt.
Producenter bruger ordet “immutable” om meget. Når en tjeneste eller et produkt kaldes uforanderligt, er det første spørgsmål derfor, hvem der stadig kan slette, og hvordan. Svaret står sjældent på forsiden, men det står ofte i dokumentationen.
Lås i lageret
Den mest udbredte form er en lås på objekterne i et objektlager. Den kaldes ofte objektlås, efter funktionen Object Lock i Amazon S3, som mange andre lagre efterligner. AWS beskriver to tilstande. I governance-tilstand kan brugere med en særlig rettighed omgå låsen. I compliance-tilstand kan ingen bruger slette eller overskrive objektet i perioden, heller ikke kontoens rodbruger. AWS skriver selv, at den eneste måde at slette et objekt i compliance-tilstand før tid er at slette den konto, objektet ligger i.
Låsen kræver, at versionering er slået til, og den beskytter kun den version, der er låst. Nye versioner kan stadig skrives oven på. Det er sådan, det skal være: backupsoftwaren skal kunne skrive nye kopier, mens de gamle står fast.
Microsoft beskriver en tilsvarende mekanisme for Azure Blob. En tidsbaseret opbevaringspolitik starter ulåst, så den kan testes. Først når den låses, er den uforanderlig, og derefter kan den ikke slettes, og perioden kan ikke forkortes. Microsoft anbefaler at låse den inden for typisk et døgn. En politik, der aldrig blev låst, beskytter altså mindre, end navnet lover.
Ikke alle lagre har låsen. Garage, et open source-objektlager, oplyser selv, at det ikke understøtter Object Lock og ikke versionering. Bruges det til backup, må uforanderligheden komme et andet sted fra. Hvad der ellers mangler i de S3-kompatible lagre, står i S3-kompatibel.
Adskilt konto
En lås i samme konto som produktionen beskytter mod en bruger, der vil slette. Den beskytter ikke mod, at kontoen lukkes, mistes eller overtages helt. Vores læsning af AWS’ egen formulering er, at kontoen er den yderste grænse for låsen.
Derfor er en adskilt konto en selvstændig del af uforanderligheden. Backupen lægges i en konto eller hos en udbyder med egne administratorer, eget login og egen genopretning af adgang. Administratorerne af produktionen bør ikke have adgang. Det gør det sværere at drive, og det er netop meningen. Hvor den adskilte konto kan ligge, står i backup i Europa.
Offline
Den tredje form er en kopi uden forbindelse til nettet, typisk på bånd eller på diske, der tages ud og opbevares et andet sted. En kopi, der ikke kan nås, kan ikke slettes over nettet. Til gengæld kræver den fysisk håndtering, og gendannelse tager længere tid. Proxmox Backup Server har fx båndbackup ifølge producentens dokumentation, og mange andre backupprodukter har det også.
Hvad en administrator stadig kan
Uforanderlighed flytter risikoen og fjerner den ikke helt. Der er fire steder at se efter.
Opbevaringsperioden kan være sat for kort. Er perioden en uge, og opdages et angreb efter ti dage, er de låste kopier allerede udløbet.
Backupsoftwaren kan have egne sletteknapper. Låsen i lageret er kun så stærk som forbindelsen mellem software og lager. Hvad de enkelte backupprodukter tillader en administrator, er ikke gennemgået her, og det skal læses i producentens egen dokumentation.
Ulåste politikker kan stå hen. Microsofts egen anbefaling om at låse inden for et døgn viser, at det er et kendt hul.
Kontoen kan forsvinde. Det er grunden til den adskilte konto.
NIS2 og ordet uforanderlig
Ordet uforanderlig står ikke i NIS2-loven. Loven nævner backupstyring og reetablering efter en katastrofe som foranstaltning (§ 6, stk. 1, nr. 3). At en låst kopi er den rigtige måde at opfylde det på, er en faglig vurdering. Loven stiller ikke det krav. Vurderingen bør stå i jeres dokumentation.
Hvad det kræver, og hvad det koster at lade være
En uforanderlig kopi kræver lager med lås eller medier, der kan tages ud, en besluttet opbevaringsperiode, en adskilt konto med egne administratorer og en procedure for, hvem der må ændre perioden. Lageret bliver større, fordi låste kopier ikke kan ryddes op før tid. Posterne er lager efter forbrug, licens til backupsoftware, eventuelt bånd og håndtering, og timer til drift og test.
At lade være betyder, at alle kopier kan nås af den, der har nået produktionen. Brug jeres egne tal for prisen ved at stå uden data og uden en kopi at gå tilbage til, og sammenhold det med de faste poster.
Det skal I lade være med
- At stole på ordet immutable i et tilbud · spørg, hvem der kan slette, og i hvilken tilstand låsen står.
- At lade en opbevaringspolitik stå ulåst efter testen · den beskytter først, når den er låst.
- At lægge den låste kopi i samme konto som produktionen og kalde opgaven løst · kontoen er stadig fælles.
Det skal valget kunne vise
- ☐ Hvilken form for uforanderlighed hver kopi har: lås, adskilt konto eller offline.
- ☐ Låsens tilstand og opbevaringsperiode.
- ☐ Hvem der kan ændre perioden eller slette kontoen.
- ☐ Dato for seneste test af gendannelse fra den låste kopi.
Kilder
- AWS, Locking objects with Object Lock: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
- Microsoft Learn, Immutable storage for Azure Blob: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview
- Garage, S3 compatibility: https://garagehq.deuxfleurs.fr/documentation/reference-manual/s3-compatibility/
- Proxmox Backup Server, dokumentation: https://pbs.proxmox.com/docs/introduction.html
- NIS2-loven, lov nr. 434 af 6/5 2025, § 6: https://www.retsinformation.dk/eli/lta/2025/434
Senest gennemgået: november 2026.
Næste skridt
Find den kopi, I regner for uforanderlig, og skriv ned, hvem der kan slette den i dag.
Læs også: Objektlager i Europa · Backup as a Service
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
