Konsistent sikring af en database: dump, snapshot eller kopi

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

En database i drift kan ikke sikres ved at kopiere datafilerne, som man kopierer et dokument. Databasen har data i hukommelsen, som endnu ikke er skrevet til disken, den skriver løbende i flere filer på én gang, og filerne er ofte låst. En filkopi taget midt i det kan være inkonsistent eller helt ubrugelig. Der er fire brugbare metoder: et logisk dump, en native backup, et snapshot af lageret eller den virtuelle maskine, og en kold kopi efter at databasen er stoppet. Valget afhænger af, hvad der skal undersøges, hvor meget systemet må påvirkes, og om slettede data og logs er relevante.

Sikring af hele servere og virtuelle maskiner er beskrevet i Virtuelle maskiner og servere. Hvilke historiske spor en database kan rumme, står i Databaser som bevis. Her handler det om selve databasen.

Hvorfor en filkopi går galt

Databasesystemer bruger en buffer i hukommelsen og en transaktionslog. En ændring skrives først i loggen og senere i datafilen. Kopieres datafilen og loggen ikke i samme øjeblik, passer de ikke sammen. Kopieres datafilen, mens en side er halvt skrevet, kan siden være beskadiget. Databasen kan i bedste fald gendanne sig selv ved opstart ud fra loggen, i værste fald nægte at starte.

Hertil kommer, at kopiering af låste filer kan fejle, eller at kopiværktøjet springer over dem uden tydelig fejl. Et resultat, der ser fuldstændigt ud, kan mangle netop databasen.

De fire metoder

Logisk dump · Fordele: Læsbart, kan indlæses i en anden version, påvirker ikke datafilerne · Ulemper: Ingen slettede data, ingen fysisk struktur, ingen transaktionslog
Native backup · Fordele: Konsistent, fuld fysisk kopi af databasen, kendt gendannelsesvej · Ulemper: Kræver databasens egne værktøjer, kan påvirke backupkæden
Snapshot · Fordele: Hele lageret eller den virtuelle maskine, inklusive logs og fri plads · Ulemper: Crash-konsistent, kræver adgang til hypervisor eller lager
Kold kopi · Fordele: Filerne i hvilende tilstand, fuld fysisk kopi · Ulemper: Kræver nedetid

Logisk dump

Et logisk dump er databasens indhold eksporteret som SQL-sætninger eller i et eksportformat. De fleste systemer kan lave et konsistent dump ved at læse alle tabeller inden for én transaktion, så resultatet svarer til ét tidspunkt. I MySQL og MariaDB kræver det indstillingen --single-transaction og en transaktionel lagringsmotor som InnoDB; tabeller i fx MyISAM kan stadig ændre sig undervejs. PostgreSQL’s pg_dump laver altid et konsistent udtræk, også mens databasen er i brug. SQL Server har ikke et tilsvarende dumpværktøj, så her er den indbyggede backup den naturlige vej til et konsistent sæt.

Dumpet er velegnet, når spørgsmålet handler om de aktuelle data, fx hvad en kundeliste eller en ordretabel indeholdt. Det er ikke egnet, når slettede rækker, ubrugt plads eller transaktionsloggen er relevant, fordi dumpet kun indeholder de rækker, databasen viser.

Native backup

Databasesystemets egen backup er konsistent og indeholder normalt de fysiske datasider, herunder dele med slettede data, og den del af transaktionsloggen, der er nødvendig for at gendanne. Det er ofte den bedste kombination af konsistens og fuldstændighed i et system i drift.

Pas på backupkæden. I SQL Server kan en almindelig fuld backup ændre grundlaget for kundens egne differentielle backups. En kopi-backup undgår det. Tilsvarende kan en ekstra logbackup afkorte transaktionsloggen. Aftal metoden med den, der drifter databasen, og notér indstillingerne.

Snapshot

Et snapshot af en virtuel maskine eller af et lagersystem fanger alle filer på samme tidspunkt. Resultatet svarer til et strømsvigt: crash-konsistent, men databasen kan genoprette sig fra det. Applikationskonsistente snapshots beder databasen om at skrive alt til disk først, hvilket giver en renere tilstand, men kræver integration i gæstesystemet. Snapshots bevarer også fri plads og logs på disken. I cloud er snapshots ofte den eneste fysiske vej, se Cloud-snapshots som forensisk kopi.

Kold kopi

Stoppes databasetjenesten kontrolleret, skrives alt til disk, og filerne kan kopieres som almindelige filer eller med en diskkopi. Det er den metode, der bevarer mest og er nemmest at verificere, men den kræver nedetid, og stoppet ændrer selv filerne en smule ved nedlukningen. Notér tidspunkt og fremgangsmåde.

Valg af metode

Kun aktuelle data relevante, systemet må ikke stoppes: logisk dump eller native backup.
Slettede data eller logs relevante: native backup, snapshot eller kold kopi, gerne suppleret med et dump til hurtig analyse.
Administreret clouddatabase uden filadgang: tjenestens snapshot eller eksport samt tjenestens auditlogs.
Stor database og kort tid: snapshot først, analyse senere.

Ofte er det bedste at kombinere to metoder, fx et snapshot for fuldstændighed og et dump for læsbarhed. De generelle overvejelser om fysiske, logiske og målrettede metoder står i Fysisk, logisk eller målrettet sikring.

Tidspunkt og position

En sikring af en database i drift skal kunne placeres præcist i tid. Notér ud over klokkeslættet databasens interne position, når systemet har en: logsekvensnummer, binlog-fil og -position eller transaktions-id. Det gør det muligt at koble sikringen til transaktionslogs, og at vise, hvilke ændringer der ligger før og efter.

Hvem udfører handlingerne?

I praksis er det ofte kundens egen databaseadministrator eller driftsleverandør, der har adgangen og kender systemet. Det er i orden, så længe handlingerne er planlagt, overvåget og dokumenteret. En god fremgangsmåde er:

Den sagkyndige beskriver metoden og kommandoerne på forhånd.
Administratoren udfører dem, mens den sagkyndige ser med, og skærmen optages eller kommandoerne logges.
Der bruges en konto med de nødvendige rettigheder og intet mere, gerne en konto oprettet til formålet, så handlingerne kan skelnes i databasens egne logs.
Resultatfilerne overføres direkte til sikringsmediet, og hashværdien beregnes, før nogen andre håndterer dem.

Er administratoren selv en del af det, der undersøges, eller kan rollen give anledning til tvivl, bør en anden udføre sikringen, eller kilderne bør suppleres med data, som den pågældende ikke har kontrol over.

Verifikation

Hashværdien af et dump eller en backupfil viser, at filen er uændret efter sikringen. Den kan ikke genskabes fra den kørende database, fordi et nyt dump vil have andre tidspunkter og måske andre data. Supplér derfor med:

antal rækker pr. tabel, taget i samme transaktion som dumpet eller fra den gendannede kopi,
kontrolsummer pr. tabel med databasens egne funktioner, hvor de findes,
en testgendannelse på et isoleret system, der viser, at kopien kan åbnes og svarer til tællingerne.

Samles mange filer, bør hashværdierne ligge i et manifest, se Hashmanifest for filsamlinger.

Typiske fejlkilder

Kopiering af kørende datafiler uden snapshot.
Glemte filer: transaktionslog, binlog, konfiguration og brugeroplysninger er ikke med.
Forkert tegnsæt i dumpet ødelægger tekst med æ, ø og å.
Belastning: et dump på et travlt system kan låse tabeller og påvirke driften.
Afbrudt backupkæde hos kunden.
Kun én database sikret. Applikationer bruger ofte flere databaser, fx en til data og en til logning eller brugere. Kortlæg dem alle, før sikringen starter.

Hvad sikringen kan og ikke kan bevise

En konsistent sikring viser databasens indhold på et kendt tidspunkt. Den viser ikke, hvordan data så ud tidligere, medmindre logs, backup eller fysiske sider indgår. Den viser heller ikke, hvem der har ændret data.

I rapporten

Beskriv system og version, valgt metode og begrundelse, indstillinger, tidspunkt og intern position, hashværdier og verifikationen med tællinger, kontrolsummer og testgendannelse.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Analyse og fortolkning

Læs også: Databaser som bevis: transaktionslogs, audittabeller og binlogs · Download dine data: platformenes udtræk som bevis

→ Digital forensics-undersøgelse · 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