ZFS og ReFS: copy‑on‑write og snapshots

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

ZFS og ReFS overskriver ikke data på stedet, når en fil ændres. De skriver de nye data et nyt sted og opdaterer derefter metadata, så de peger på den nye placering. Det giver to forensiske konsekvenser: ældre versioner af data kan overleve længere end på klassiske filsystemer, og snapshots kan bevare hele filsystemets tilstand på et tidspunkt. Til gengæld er værktøjsstøtten mere begrænset, og fortolkningen kræver kendskab til, hvordan filsystemet deler blokke mellem filer. ZFS findes især på NAS-enheder og Linux- og BSD-servere, ReFS på Windows Server.

En generel sammenligning af filsystemer står i filsystemer sammenlignet, og NAS-enheder som datakilde er beskrevet i NAS-enheder.

Copy-on-write kort fortalt

På NTFS eller ext4 overskrives en fils blokke typisk, når filen ændres på stedet. På et copy-on-write-filsystem skrives ændringen til ledige blokke, og først når skrivningen er gennemført, flyttes pegepinden. De gamle blokke frigives, medmindre noget andet stadig refererer til dem, fx et snapshot eller en klon.

Det betyder, at tidligere versioner af en fil kan ligge i frigivne blokke, indtil de genbruges. Hvor længe det varer, afhænger af hvor fyldt puljen er, af skriveaktiviteten og af, om TRIM bruges på SSD’er. Copy-on-write er derfor ikke en garanti for, at gamle data findes, men en grund til at lede.

ZFS

Puljer og datasæt. ZFS samler en eller flere diske i en pulje (pool) og opretter datasæt ovenpå. En pulje kan være spejlet eller bruge RAIDZ, hvor data og paritet fordeles over flere diske. En enkelt disk fra en RAIDZ-pulje kan ikke læses alene.

Snapshots. Et ZFS-snapshot er ifølge OpenZFS-dokumentationen en skrivebeskyttet kopi af et datasæt på et bestemt tidspunkt. Det fylder i starten intet, men vokser, efterhånden som det aktive datasæt ændres, fordi snapshottet holder fast i de gamle blokke. Snapshots kan tilgås gennem den skjulte mappe .zfs/snapshot i datasættets rod.

Kloner og bookmarks. En klon er et skrivbart datasæt, der starter som en kopi af et snapshot. Et bookmark gemmer kun tidspunktet for et snapshot og overlever, selvom snapshottet slettes, men det indeholder ingen data.

Historik. zpool history viser de kommandoer, der er udført mod puljen, fx oprettelse og sletning af snapshots og datasæt, med tidspunkter. Det er en af de mest værdifulde kilder i en sag om sletning, fordi den kan vise, hvornår et snapshot forsvandt, og med hvilken kommando.

Kryptering og komprimering. ZFS kan kryptere og komprimere pr. datasæt. Et krypteret datasæt kræver nøglen for at kunne læses, også i en kopi.

ReFS

ReFS er Microsofts filsystem til store datamængder og virtualisering. Det bruger checksummer til metadata og valgfrit til fildata (integrity streams), og det understøtter blokkloning, hvor en kopi af en fil laves som en metadataændring i stedet for en fysisk kopi.

Blokkloning. Ifølge Microsoft deler flere filer de samme fysiske klynger, og ReFS holder en referencetælling for hver. Skrives der til en delt region, allokeres et nyt område til skrivningen. Forensisk betyder det, at to filer kan dele indhold fysisk, og at en “kopi” ikke nødvendigvis har skrevet nye data på disken. Fra Windows 11 24H2 og Windows Server 2025 sker blokkloning ifølge Microsoft automatisk i understøttede kopieringer i Windows.

Snapshots og USN. ReFS understøtter volumen-snapshots, og fra Windows Server 2022 også snapshots på filniveau. USN-journalen findes også på ReFS og kan vise ændringer i filer. Volume Shadow Copies kan bruges på ReFS-volumener; se Volume Shadow Copies.

Begrænsninger. ReFS kan ikke bruges på flytbare medier og kan ikke være startdrev. Det mangler en række NTFS-funktioner, bl.a. objekt-id’er og korte filnavne. ReFS findes også i Windows 11 som grundlag for Dev Drive til udviklingsmapper.

Værktøjsstøtte. Mange forensiske værktøjer er bygget til NTFS og kan læse ReFS med begrænsninger eller slet ikke, især på nyere ReFS-versioner. Test værktøjet på et referencevolumen af samme version, før fund bruges.

Sikring

Valget står mellem fysisk og logisk sikring:

Fysisk image af alle diske i puljen. Giver adgang til frigivne blokke og dermed tidligere versioner. Kræver alle medlemmer af puljen, korrekt rækkefølge og et værktøj, der kan genopbygge puljen. Ved store NAS-enheder kan det tage lang tid; se store datamængder.
Logisk sikring af datasæt og snapshots. Hurtigere og mere målrettet. Et snapshot er skrivebeskyttet og kan kopieres uden at ændre det aktive datasæt, og zfs send kan danne en strøm af et snapshot. Frigivne blokke kommer ikke med.

Første skridt er i begge tilfælde at standse automatisk oprydning. Mange NAS-enheder og servere har politikker, der automatisk sletter snapshots efter et antal dage. Dokumentér politikken og listen over eksisterende snapshots med oprettelsestider, og sæt sletningen på pause, før noget andet sker. Gem output fra zpool history, zfs list -t snapshot og puljestatus som tekstfiler med hashværdi.

På Windows Server dokumenteres ReFS-versionen, om integrity streams er slået til, og hvilke snapshots og skyggekopier der findes.

Fejlkilder i fortolkningen

Snapshotnavne lyver. Navnet på et snapshot er valgt af en bruger eller et script. Brug egenskaben creation, ikke navnet, som tidspunkt.
Delte blokke. En gendannet blok kan tilhøre flere filer eller flere versioner. Uden metadata kan den ikke henføres sikkert.
Komprimering og deduplikering. Rådata på disken svarer ikke til filens indhold, og søgning i rå sektorer kan overse tekst.
Tidsstempler ved blokkloning. En klonet fil får sine egne filtidsstempler, selvom indholdet fysisk er det samme. Fildatoen siger ikke, hvornår indholdet blev skrevet.
Sletning af snapshot. At et snapshot er væk, beviser ikke, hvem der slettede det. zpool history og systemets egne logs skal sammenholdes med adgangslogs.

Dokumentation

Rapporten bør beskrive puljens opbygning (antal diske, redundans, serienumre), filsystemets version, eventuel kryptering og komprimering, og præcis hvilke snapshots der blev sikret, med navn, oprettelsestid og hashværdi af den sikrede kopi. Er der foretaget en logisk sikring, skal det fremgå, at frigivne blokke ikke er med, så læseren ikke tror, at fravær af en tidligere version betyder, at den aldrig har eksisteret. Notér også, hvilke værktøjer og versioner der er brugt til at læse filsystemet, og om de er testet mod et referencevolumen.

Hvad sporene kan og ikke kan vise

Snapshots kan vise, hvordan et datasæt så ud på bestemte tidspunkter, og forskellen mellem to snapshots kan vise, hvad der er ændret eller slettet. Puljehistorikken kan vise, hvornår snapshots og datasæt blev oprettet og slettet. Frigivne blokke kan indeholde tidligere versioner, men uden metadata er det ofte uklart, hvilken fil og hvilket tidspunkt de stammer fra. Konklusioner om personers handlinger kræver kobling til login- og adgangslogs; se ext4, XFS, Btrfs og LVM for tilsvarende overvejelser på Linux.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Formateret eller wipet? Tekniske tegn på en overskrevet disk · SSD, TRIM og gendannelse af slettede filer

→ Forensisk undersøgelse af en computer · 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