Store datamængder: forensisk kopi af multi‑terabyte‑systemer

Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen

Når kilden er en filserver, et storage-system eller en virtualiseringsplatform med mange terabyte, bliver den forensiske kopi et logistisk projekt. Principperne er de samme som for en enkelt bærbar: læs uden at ændre, verificér med hashværdier, dokumentér alt. Men tiden, kapaciteten og risikoen for fejl undervejs vokser med mængden, og nogle valg, der er ligegyldige på 500 GB, bliver afgørende på 50 TB. Det vigtigste er at regne på tid og plads før start, at vælge et format, der kan opdeles og verificeres i dele, og at overveje, om et fuldt image overhovedet er det rigtige svar på spørgsmålet.

Først: skal det hele kopieres?

Et fuldt image af et stort system er ikke altid den rigtige løsning. Det kan være mere forsvarligt at:

tage fuldt image af de systemer, der er centrale for spørgsmålet, og målrettet indsamling fra resten,
tage snapshots på storage-niveau og kopiere dem i ro bagefter,
bevare data på stedet med et snapshot eller en spærring mod sletning og først kopiere, når afgrænsningen er på plads.

Valget mellem fuldt image og målrettet indsamling er beskrevet i Fysisk, logisk eller målrettet sikring og Triage eller fuld kopi. Uanset valget skal begrundelsen skrives ned. En fuld kopi af alt er ikke automatisk mere forsvarlig, hvis den indeholder store mængder data om personer, der ikke har med sagen at gøre.

Regn på tiden

Tiden afhænger af den langsomste del af kæden: kildens læsehastighed, forbindelsen (USB, SATA, SAS, netværk), kopieringsværktøjets hastighed, hashberegningen og destinationens skrivehastighed. En simpel beregning giver et realistisk billede (tidsforbruget for hele undersøgelsen er beskrevet i Tidsforbrug i en forensisk undersøgelse): Ved en vedvarende hastighed på 200 MB pr. sekund tager 10 TB omkring 14 timer, før verifikationen. Verifikation ved genlæsning af hele kopien kan tage næsten lige så lang tid igen.

Planlæg derfor:

Prøvekørsel: Mål den faktiske hastighed på de første minutter, og regn om.
Parallelle kopier: Flere diske eller volumener kan kopieres samtidig til hver sin destination, hvis forbindelserne tillader det.
Arbejdsvinduer: På produktionssystemer kan læsningen belaste systemet. Aftal tidspunktet med driften.
Overvågning: En kopiering, der kører natten over, skal kunne overvåges, og fejl skal opdages hurtigt.

Regn på pladsen

Destinationen skal have plads til kopien, til en eventuel arbejdskopi og helst til en ekstra kopi. Tommelfingerreglen om mindst to fysisk adskilte kopier af masterkopien gælder også her. → Arbejdskopier og masterkopi

Kompression kan reducere pladsbehovet betydeligt på systemer med meget tom eller ensartet plads, men næsten intet på krypterede eller allerede komprimerede data. Kompression koster CPU-tid og kan gøre kopieringen langsommere. Mål på et udsnit, før du beslutter.

Format og opdeling

Store kopier bør lægges i et format, der:

kan opdeles i segmenter af en fast størrelse, så en enkelt fejl ikke ødelægger hele kopien,
gemmer hashværdier eller kontrolsummer for blokke eller segmenter, så en fejl kan lokaliseres,
kan læses af flere værktøjer,
bærer metadata om kilde, tidspunkt og værktøj inde i selve beholderen.

E01 og AFF4 opfylder disse krav i forskellig grad. AFF4 er designet med store mængder og parallel behandling for øje. Rå kopier er enkle, men skal opdeles manuelt og har ingen indbyggede metadata. Formaterne er sammenlignet i Forensiske diskformater: raw, E01 og AFF4.

Verifikation af store kopier

Verifikation består af to dele: hashværdien beregnet under læsningen af kilden, og en ny beregning ved genlæsning af kopien. Ved store kopier er det fristende at springe den anden del over. Gør det ikke, men planlæg den:

Lad værktøjet beregne flere algoritmer i samme gennemløb, fx MD5 og SHA-256, så der ikke skal læses flere gange.
Verificér på destinationen, ikke over netværket, hvis muligt.
Ved opdelte kopier: Gem hashværdien for hvert segment ud over den samlede værdi. Hvis en samlet verifikation fejler, kan fejlen så lokaliseres til et segment.
Ved kilder, der kører under kopieringen, kan en ny læsning af kilden give en anden hashværdi. Kopien verificeres da mod den værdi, der blev beregnet under læsningen.

Hvis hashværdierne ikke stemmer, skal årsagen findes og beskrives, før kopien bruges. → Når hashværdien ikke stemmer

RAID, storage-systemer og virtualisering

Store systemer ligger sjældent på én disk. Tre tilgange er typiske:

Den logiske volumen: Kopiér den samlede volumen, som styresystemet eller controlleren præsenterer. Det er enklest og giver en kopi, der kan analyseres direkte.
De fysiske diske: Kopiér hver disk for sig. Det bevarer mest, men kræver, at RAID-opsætningen senere genskabes korrekt, og det er både tidskrævende og fejlbehæftet.
Storage-snapshots: Tag et snapshot på storage- eller hypervisorniveau, og kopiér det. Det giver et konsistent tidspunkt uden at belaste produktionen længe.

Uanset tilgang skal RAID-niveau, stripe-størrelse, diskrækkefølge og controller noteres, så kopien kan forstås og eventuelt genskabes. Hypervisorens egen konfiguration bør eksporteres sammen med kopien.

Når kopien skal analyseres bagefter

En stor kopi er kun nyttig, hvis den kan behandles. Indeksering, carving og tidslinjer over mange terabyte tager tid og kræver arbejdsstationer med tilstrækkelig hukommelse og hurtig lagring. Overvej allerede ved sikringen, hvordan analysen skal ske:

Kan kopien åbnes direkte i analyseværktøjet, eller skal den først konverteres?
Skal der laves en arbejdskopi på hurtig lagring, mens masterkopien ligger på langsommere medier?
Kan analysen deles op pr. volumen eller pr. virtuel maskine, så det relevante behandles først?

Hver konvertering og hver ny kopi skal verificeres mod masterkopien og registreres i bevisloggen.

Cloud som kilde eller destination

Ligger kilden i cloud, fx som virtuelle diske hos en udbyder, er det ofte bedre at tage et snapshot og lave kopien i samme cloudmiljø end at hente alt ned over internettet. Udgående datatrafik kan desuden have en pris. Bruges cloudlagring som destination, gælder de samme krav om kryptering, adgangskontrol og logning som for fysiske medier, og placeringen skal fremgå af dokumentationen. → Snapshots af cloud-diske som forensisk kopi

Typiske fejl

At destinationsdisken løber fuld efter mange timer, fordi kompressionen var mindre end ventet.
At kopieringen afbrydes, og at genoptagelsen ikke er understøttet, så alt må startes forfra.
At verifikationen springes over “midlertidigt” og aldrig bliver gjort.
At en destinationsdisk med sektorfejl giver en kopi, der ikke kan læses senere. Brug kontrollerede, nye eller testede medier.
At ingen har noteret, hvilke segmentfiler der hører sammen, når kopien er fordelt på flere diske.
At filsystemet på destinationen har en grænse for filstørrelse, der gør, at store segmenter fejler.

Hvad en stor kopi kan og ikke kan bevise

En korrekt verificeret kopi af et stort system bevarer data i samme tilstand som ved sikringen, uanset størrelsen. Størrelsen ændrer ikke beviskraften, men den øger risikoen for, at en fejl i processen går ubemærket hen. Det er derfor dokumentationen af hvert segment og hver verifikation, der gør kopien troværdig.

Dokumentation

Notér kilden med identifikation og kapacitet, RAID- og storage-opsætning, valgt tilgang og begrundelse, format, segmentstørrelse og kompression, start- og sluttid, hastighed, hashværdier pr. segment og samlet, verifikationsresultat og placeringen af hver destinationsdisk. Ved overdragelse af store mængder til modtagere uden for sagen, se Sikker deling af store datamængder med retten og modparten.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Når MSP’en henvender sig på kundens vegne

Del af: Sikring: metoderne samlet

Læs også: Kopiering af netværksdrev og filshares uden at ændre tidsstempler · Defekte og fejlende diske: dataredning eller forensic?

→ Forensisk sikring · For sagkyndige · 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