ext4, XFS, Btrfs og LVM: sletning og snapshots på Linux

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

På Linux-servere er gendannelse af slettede filer generelt sværere end på Windows. ext4 og XFS fjerner ved sletning de oplysninger, der forbinder filens navn med dens datablokke, så gendannelse oftest afhænger af filsystemets journal eller af carving. Til gengæld kan LVM-snapshots og Btrfs-snapshots indeholde hele tidligere versioner af et volumen, og de skal identificeres og sikres, før de fjernes. Denne artikel beskriver, hvad der realistisk kan gendannes, og hvad snapshots kan bruges til.

ext4

ext4 er det mest udbredte filsystem på Linux. Filer beskrives af inoder, som peger på datablokkene via et træ af extents. Ved sletning sker der typisk følgende:

Mappeposten fjernes eller markeres ubrugt.
Inoden markeres fri, og ext4 nulstiller extent-oplysningerne i inoden, så forbindelsen til datablokkene går tabt.
Datablokkene markeres frie, men indholdet bliver liggende, indtil det overskrives eller fjernes af TRIM.

Fordi extent-oplysningerne nulstilles, kan en slettet fil sjældent gendannes med navn og indhold samlet. Mulighederne er:

Journalen. ext4’s journal (jbd2) indeholder kopier af metadatablokke, der er ændret for nylig. En ældre kopi af en inodeblok kan stadig indeholde de extents, der pegede på filens data. Det giver en reel chance for kort tid efter sletningen. Standardtilstanden er ordered, hvor kun metadata journalføres, og journalens størrelse vælges ved formateringen ud fra filsystemets størrelse. Tilstand og størrelse aflæses i superblokken på det konkrete filsystem, og da journalen genbruges cirkulært, afhænger rækkevidden af aktiviteten.
Carving i frie blokke efter kendte filsignaturer. Giver indhold uden navn og tidsstempler. → File carving
Mappeblokke kan stadig indeholde gamle filnavne, selv om inoden er genbrugt.

Inoder har fire tidsstempler: adgang, ændring af indhold, ændring af metadata og, på inoder i det nyere store format, oprettelse (crtime) med nanosekundopløsning. Ved sletning sættes desuden et slettetidspunkt, som kan bruges i en tidslinje, hvis inoden ikke er genbrugt.

XFS

XFS bruges ofte på store servere og er standardfilsystem i Red Hat Enterprise Linux og de distributioner, der bygger på den. Ved sletning frigøres inoden og dens extents, og en del af inodens indhold kan blive stående, indtil inoden genbruges. Gendannelse med navn og indhold er mulig i nogle tilfælde, men værktøjsunderstøttelsen er mere begrænset end for ext4. XFS har også en metadatajournal, som kan give tidlige spor efter sletning. Hvor meget der kan gendannes, afhænger af XFS-versionen, aktiviteten efter sletningen og det anvendte værktøj, så resultatet bør kontrolleres med mere end ét værktøj, før det bærer en konklusion.

Btrfs

Btrfs skriver ændringer nye steder (copy-on-write) og holder generationer af sine metadatatræer. Det betyder:

Ældre versioner af træerne kan pege på data fra før en sletning, så længe blokkene ikke er genbrugt.
Subvolumer og snapshots er indbygget. Mange distributioner og NAS-enheder laver automatiske snapshots før opdateringer eller efter tidsplan.
Data kan være komprimeret og fordelt over flere enheder, hvilket kræver værktøjer, der forstår formatet.

Btrfs-snapshots er ofte den mest værdifulde kilde til tidligere versioner på systemer, der bruger filsystemet. → NAS-enheder som datakilde

LVM

LVM (Logical Volume Manager) ligger mellem disken og filsystemet. En eller flere fysiske diske samles i en volumengruppe, som deles op i logiske volumener. For undersøgelsen har det flere konsekvenser:

Kopien skal tages af de fysiske diske, og LVM-strukturen skal genskabes på analysemaskinen. En kopi af kun et logisk volumen mister ikke-allokeret plads i volumengruppen.
Snapshots. Klassiske LVM-snapshots gemmer de oprindelige blokke, når volumenet ændres, og indeholder dermed volumenets tilstand på snapshottidspunktet. Tynde volumener (thin provisioning) har tilsvarende snapshots med delt lager.
Metadatahistorik. LVM gemmer typisk sikkerhedskopier af sin konfiguration ved ændringer: den aktuelle under /etc/lvm/backup og tidligere udgaver under /etc/lvm/archive, hvor hver fil angiver tidspunkt og den kommando, der udløste ændringen. Arkivet kan vise, hvornår volumener og snapshots blev oprettet, ændret eller fjernet. Om arkivering er slået til, og hvor længe filerne bevares, styres i lvm.conf og kan aflæses med lvmconfig.
Ikke-allokeret plads i volumengruppen kan indeholde rester af tidligere logiske volumener.

Et eksisterende LVM-snapshot må ikke fjernes eller sammenlægges som led i sikringen. Det registreres og sikres som en selvstændig kilde.

Andre filsystemer på Linux

Servere kan også bruge ZFS, som ligesom Btrfs arbejder med copy-on-write og har indbyggede snapshots, eller ældre ext3 og ext2. På ext3 og ext2 nulstilles bloklister ved sletning på lignende måde som på ext4, men værktøjsunderstøttelsen er bred. ZFS kræver værktøjer, der forstår puljer og datasæt, og er ofte bedst sikret logisk fra det kørende system kombineret med kopier af de fysiske diske. Uanset filsystem gælder samme fremgangsmåde: kortlæg, kopiér det fysiske lag, sikr snapshots særskilt, og dokumentér begrænsninger.

Kryptering og TRIM

Mange Linux-servere bruger diskkryptering under LVM eller filsystemet. Kopien af den fysiske disk er så krypteret og kræver nøglen eller adgang via det kørende system. → Krypterede data: de lovlige adgangsveje

På SSD’er og virtuelle diske med discard slettes frie blokke ofte i den underliggende lagring. Er discard aktiveret, eller køres TRIM periodisk, er chancerne for gendannelse små. Konfigurationen bør noteres, fordi den forklarer resultatet. → SSD, TRIM og gendannelse

Sikring

Kortlæg lagringen: fysiske diske, partitioner, kryptering, volumengrupper, logiske volumener, filsystemer og snapshots. Notér det før kopieringen.
Kopiér de fysiske diske eller de virtuelle diskfiler, så hele LVM-strukturen og den ikke-allokerede plads er med.
Sikr eksisterende snapshots som særskilte kilder, med tidspunkt og navn.
Hash alle kopier og noter værktøj og version.
Er serveren i drift, og en fuld kopi ikke kan tages straks, så sikr logs og nøglefiler først og lav et snapshot på hypervisorniveau. → Linux-servere: journald, auth-log og shellhistorik

Snapshots i analysen

Når et snapshot er sikret, er den mest direkte analyse en sammenligning med volumenets aktuelle tilstand:

Lav fillister for både snapshot og aktuelt volumen med sti, størrelse, tidsstempler og hash.
Sammenlign listerne. Filer, der kun findes i snapshottet, er slettet eller flyttet efter snapshottidspunktet. Filer med samme sti, men forskellig hash, er ændret.
Indsnævr tidspunktet med andre kilder. Snapshottet giver et “før”, sikringen et “efter”. Logs, journaler og filsystemets tidsstempler kan placere ændringen mere præcist i intervallet.
Gentag for hvert snapshot, hvis der er flere. En række snapshots giver en serie af tilstande, som kan vise, hvornår en fil forsvandt.

Sammenligningen skal foretages på kopierne, ikke på det kørende system. Montering af et snapshot på originalen med skriveadgang kan ændre det.

Det samme princip gælder for snapshots på NAS-enheder og i backupsystemer. Forskellen er alene, hvor snapshottet er lagret, og hvem der kontrollerer det.

Fejlkilder

Gendannet er ikke nødvendigvis helt. Carvede filer kan være fragmenterede eller sammensat af forkerte blokke. Kontrollér, at indholdet er sammenhængende.
Tidsstempler på gendannede filer stammer fra journalkopier eller genbrugte inoder og skal bekræftes.
Snapshotdato er oprettelsesdato. Indholdet afspejler tilstanden på det tidspunkt, ikke hvornår filerne blev lavet.
Værktøjsunderstøttelse. Ikke alle forensiske værktøjer forstår XFS, Btrfs eller tynde LVM-volumener. Afgørende fund kontrolleres i mere end ét værktøj.

Hvad det kan og ikke kan bevise

Et snapshot kan vise, at en fil fandtes med et bestemt indhold på et bestemt tidspunkt. Journalrester og carving kan vise, at data har været til stede på disken. Ingen af delene viser alene, hvem der slettede noget, eller hvorfor. Det kræver logs og adgangsspor.

Dokumentation

Rapporten bør beskrive lagringsstakken lag for lag, hvilke snapshots der fandtes, hvilke metoder der er brugt til gendannelse, og hvilke dele af resultatet der er rekonstrueret. Forbehold om kryptering og TRIM skal fremgå.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: macOS- og Linux-forensik

Læs også: Linux-servere i undersøgelser: journald, auth-log og shellhistorik · NAS-enheder som datakilde: logs, papirkurv og snapshots

→ 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