Gendannelse fra backup til forensisk brug: metode og dokumentation

Forside › macOS- og Linux-forensik · Gennemgået oktober 2026 · Af John Nielsen

Når originalen er slettet, ændret eller krypteret, er backuppen ofte den eneste kilde til en tidligere tilstand. En gendannelse er dog ikke en neutral handling. Den kan ændre tidsstempler, rettigheder og metadata, den kan overskrive nyere data, hvis den sker til den oprindelige placering, og backupsystemets egne logs og kataloger er en del af beviset. En forensisk gendannelse sker derfor altid til et isoleret mål, med dokumentation af backupsystem, gendannelsespunkt og indstillinger, og med hash af resultatet. Hvorfor backup kan være et bevis, og hvad den grundlæggende værdi er, står på hub-sitet: → Backup som bevis: når originalen er væk

Denne artikel er metoden for selve gendannelsen. Hvornår en backup blev slettet eller ændret, står i Backup-logs, og særlige forhold ved backup af Microsoft 365 i Tredjepartsbackup af Microsoft 365 som kilde.

Før gendannelsen: sikr backupsystemet

Backupsystemet er i sig selv en kilde, der kan ændre sig. Gamle gendannelsespunkter slettes efter opbevaringspolitikken, og en fejlagtig gendannelse kan overskrive data. Første skridt er derfor at fastholde:

Opbevaringspolitikken: hvor mange punkter og hvor langt tilbage. Sæt automatisk sletning på pause for de relevante job efter aftale, hvis perioden er ved at udløbe.
Kataloget: listen over gendannelsespunkter med tidspunkter, job og status. Eksportér eller dokumentér det.
Backuplogs: hvilke job der kørte, lykkedes eller fejlede, og om nogen har slettet eller ændret punkter. → Backup-logs: hvornår blev backuppen slettet eller ændret?
Uforanderlighed: om backuppen er gemt på uforanderligt lager (immutable) eller offline, hvilket styrker, at den ikke er ændret efter oprettelsen.

Vælg gendannelsespunktet

Vælg det punkt eller de punkter, der bedst dækker den relevante periode, og dokumentér begrundelsen. Ofte er det nyttigt at gendanne flere punkter, fx det sidste før og det første efter en hændelse, så ændringer kan ses. Notér for hvert punkt:

backupsystem, version og job,
punktets tidspunkt og hvad det betyder i det konkrete system (start eller afslutning af jobbet, eller tidspunktet for et underliggende snapshot),
backuptype: fuld, inkrementel, differentiel eller syntetisk fuld,
om punktet er verificeret af systemet.

Gendan til et isoleret mål

Gendannelsen må aldrig ske til den oprindelige placering. Brug et separat mål, som ingen andre har adgang til:

Klargør målet: en tom, forberedt disk eller mappe på analyseudstyret eller en isoleret virtuel maskine uden netværk.
Vælg indstillinger bevidst: bevar tidsstempler og rettigheder, hvis systemet tilbyder det, og notér indstillingerne.
Gennemfør gendannelsen og gem systemets egen log over gendannelsen.
Hash de gendannede filer og lav et hashmanifest over hele samlingen. → Hashmanifest for filsamlinger
Sammenlign med kataloget: antal filer, størrelser og eventuelle checksummer, som backupsystemet selv har gemt.

Er backuppen et image af en hel maskine, kan den ofte monteres skrivebeskyttet eller eksporteres til en virtuel diskfil, der kan behandles som en forensisk kopi. Det er at foretrække frem for at starte maskinen, som ændrer systemet ved opstart.

Hvad gendannelsen ændrer

Gendannelse er ikke det samme som at hente den oprindelige fil. Typiske ændringer:

Oprettelsestid sættes ofte til gendannelsestidspunktet, mens ændringstiden kan være bevaret.
Seneste adgang er sjældent meningsfuld efter gendannelse.
Rettigheder og ejer kan ændres, hvis målet ikke kender de oprindelige konti.
Alternate data streams og udvidede attributter, fx Zone.Identifier, kan mangle, hvis backupsystemet ikke gemmer dem.
Mail gendannet til en postkasse får nye interne id’er og nogle gange nye tidsstempler for modtagelse i mappen.

Hvilke metadata der bevares, afhænger af backupsystem og indstilling. Kendes adfærden ikke, afprøves den med testfiler på samme system og version. → Tidsstempler ved kopiering, zip, upload og mail

Backup af cloudtjenester

Backup af Microsoft 365, Google Workspace og andre SaaS-tjenester gemmes hos tredjepart og gendannes typisk tilbage til tjenesten. Det rejser særlige spørgsmål: Gendannelse til den oprindelige postkasse eller drev ændrer den levende kilde, og indholdet kan blive synkroniseret til brugerens enheder. Brug eksport til fil i stedet for gendannelse, hvor det er muligt, eller gendan til en særskilt konto. → Tredjepartsbackup af Microsoft 365 som kilde

Databaser, mailservere og ældre medier

Nogle typer data kræver særlig omhu ved gendannelse:

Databaser gendannes bedst til en separat databaseinstans i samme version som originalen. Notér, om backuppen er en fuld sikkerhedskopi, en serie af transaktionslogs eller en fil-kopi af en database, der kørte. En gendannelse til et bestemt tidspunkt (point in time) ved hjælp af transaktionslogs er i sig selv en rekonstruktion, der skal beskrives trin for trin. → Databaser som bevis: transaktionslogs og audittabeller
Lokale mailservere gendannes ofte som databasefiler, der skal monteres i et gendannelsesmiljø, før postkasser kan eksporteres. Eksportformatet og eventuelle konverteringer skal fremgå.
Bånd og ældre backupformater kræver kompatibelt udstyr og software. Hvis backupsystemets katalog mangler, skal det genopbygges ved at læse medierne, hvilket tager tid og skal dokumenteres. → Ældre medier og båndbackup i sager

I alle tilfælde gælder, at den gendannede kilde bevares uændret, og at analysen foregår på en kopi af resultatet.

Hvem udfører gendannelsen?

Ofte er det IT-afdelingen eller IT-leverandøren, der har adgang til backupsystemet. Det er i orden, når det sker under kontrollerede forhold, men det skal dokumenteres:

hvem der udførte gendannelsen, og med hvilken konto,
hvem der overværede, eller om den blev optaget,
at målet var isoleret, og at resultatet blev overdraget med hash og kvittering.

Er leverandøren selv part i sagen, fx ved en tvist om netop backuppen, bør gendannelsen udføres eller overværes af en uafhængig.

Når gendannelsen fejler

Backupsystemer melder ikke altid fejl tydeligt. Filer kan blive sprunget over på grund af rettigheder, lange stier eller beskadigede blokke, mens jobbet stadig ender som “gennemført med advarsler”. Gennemgå derfor gendannelsens log for advarsler, og sammenhold antallet af gendannede filer med kataloget. Fejler en gendannelse helt, må den ikke gentages ukritisk mod samme mål. Bevar loggen fra det mislykkede forsøg, ryd eller udskift målet, og gentag med dokumentation af, hvad der blev ændret. Gentagne forsøg er ikke en fejl i metoden, men de skal fremgå.

Fejlkilder i fortolkningen

Backuptidspunkt er ikke filens tidspunkt. Et gendannelsespunkt viser tilstanden ved backuppen, ikke hvornår filerne blev oprettet eller ændret.
Inkrementelle kæder kræver, at alle led er intakte. Et beskadiget led kan give ufuldstændige eller forkerte filer uden tydelig fejl.
Udelukkelser. Backupjob udelader ofte bestemte filtyper, mapper eller åbne filer. Fravær i backuppen viser ikke, at filen ikke fandtes.
Deduplikering og komprimering i backupsystemet er transparente, men gør det umuligt at sammenligne lagringsblokke direkte med originalen.

Hvad gendannede data kan og ikke kan bevise

Gendannede data kan vise, at filer med et bestemt indhold fandtes på et bestemt system på backuptidspunktet, under forudsætning af at backupsystemet og kæden er intakte. De kan ikke vise ændringer mellem to backups, og deres tidsstempler skal læses med forbehold for gendannelsens påvirkning.

Dokumentation

Rapporten bør beskrive backupsystemet, opbevaringspolitik og uforanderlighed, valgte punkter med begrundelse, gendannelsens indstillinger, mål og isolering, hvem der udførte den, hashmanifest og sammenligning med kataloget samt kendte ændringer i metadata.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: macOS- og Linux-forensik

Læs også: NAS-enheder som datakilde: logs, papirkurv og snapshots · VDI og Citrix: hvor ligger brugerens spor?

→ Forensisk undersøgelse af en computer · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik