Hvorfor VM-snapshots ikke er sikre til transaktionsdatabaser: En DBA’s guide til dataintegritet

For DevOps-ingeniører og systemadministratorer er snapshots af virtuelle maskiner (VM) et fundamentalt værktøj. De giver en hurtig og bekvem måde at indfange tilstanden af en server før en risikabel opdatering, en større konfigurationsændring eller en applikationsudrulning. Hvis noget går galt, tager det kun få sekunder at rulle tilbage.

Men når den samme metode anvendes på transaktionsdatabaser – såsom PostgreSQL, MySQL, Oracle eller Microsoft SQL Server – forvandles VM-snapshots fra et sikkerhedsnet til en tikkende bombe.

At stole på standard hypervisor-snapshots til database-backups er en af de mest almindelige årsager til datakorruption, “torn pages” (delvist skrevne sider) og uoprettelige nedbrud i produktionen. I denne artikel vil vi udforske den arkitektoniske konflikt mellem hypervisorer og databasemotorer, mekanismerne bag datakorruption under snapshots og de tekniske best practices, der kræves for sikkert at tage backup af virtualiserede databaser.

Arkitekturkonflikten: Hypervisorer vs. Databasemotorer

For at forstå, hvorfor VM-snapshots bringer databaser i fare, må vi først undersøge, hvordan begge systemer håndterer tilstand og I/O-operationer.

Hvordan hypervisorer udfører snapshots

Når en hypervisor (såsom VMware ESXi, Microsoft Hyper-V eller KVM) tager et snapshot, kopierer den ikke disken. I stedet fryser den den nuværende virtuelle diskfil (f.eks. .vmdk eller .vhdx) i en skrivebeskyttet tilstand og opretter en ny delta-disk (differencing disk). Alle efterfølgende skrivninger dirigeres til denne delta-disk.

Når snapshotet slettes, skal hypervisoren committe (konsolidere) dataene fra delta-disken tilbage til basisdisken. Standard-snapshots er fuldstændig uvidende om de applikationer, der kører inde i gæsteoperativsystemet. De indfanger diskens tilstand præcis, som den eksisterer i det mikrosekund.

Hvordan transaktionsdatabaser håndterer tilstand

Transaktionsdatabaser er designet omkring ACID-egenskaber (Atomicity, Consistency, Isolation, Durability). For at opnå høj ydeevne og samtidig opretholde ACID-overholdelse, skriver databaser ikke hver transaktion direkte til de primære datafiler på disken med det samme. I stedet bruger de en kompleks arkitektur i flere lag:

1. Buffer Pool / Shared Buffers: Data læses ind i og ændres i systemets hukommelse.
2. Write-Ahead Log (WAL) / Redo Logs: Ændringer skrives sekventielt til en højt optimeret logfil på disken for at sikre holdbarhed.
3. Checkpoints / Lazy Writers: Med jævne mellemrum tømmer databasen de ændrede (dirty) sider fra hukommelsen til de faktiske datafiler på disken.

På grund af denne arkitektur er de fysiske datafiler på disken næsten altid ude af synkronisering med databasens faktiske tilstand. Databasens sande tilstand eksisterer kun som en kombination af datafilerne på disken, WAL/Redo-logfilerne og de data, der i øjeblikket ligger i hukommelsen.

Farezonen: Hvad sker der under et VM-snapshot

Når du tager et standard VM-snapshot af en databaseserver, indfanger du en crash-konsistent tilstand.

Crash-konsistens vs. applikationskonsistens

Et crash-konsistent snapshot svarer til at trække strømstikket ud af den fysiske server. Diskens tilstand indfanges, men alt, hvad der lå i hukommelsen, går tabt, og alt, hvad der var undervejs til storage-controlleren, bliver brat afbrudt.

Selvom moderne databaser er designet til at genoprette efter uventet strømsvigt ved at afspille Write-Ahead Loggen, er det yderst farligt at stole på crash-recovery som din primære backup-strategi. Hvis din database spænder over flere virtuelle diske (f.eks. datafiler på Drev D: og WAL på Drev E:), tager hypervisoren måske ikke snapshot af begge diske i præcis samme mikrosekund. Hvis WAL-diskens snapshot indfanges blot en brøkdel af et sekund efter data-diskens snapshot, kan databasen ikke afstemme sekvensnumrene ved gendannelse, hvilket resulterer i fatal korruption.

“VM Stun”-effekten på systemer med mange transaktioner

Processen med at oprette et snapshot – og endnu vigtigere, processen med at konsolidere det – forårsager et fænomen kendt som “VM Stun”.

For sikkert at skifte I/O fra basisdisken til delta-disken, skal hypervisoren kortvarigt pause (stun) den virtuelle maskine. For en let belastet webserver kan dette stun vare 10-50 millisekunder og gå ubemærket hen. Men for en database med høj gennemstrømning og massiv I/O kan konsolidering af en stor delta-disk fryse VM’en i flere sekunder.

Under et VM-stun:
* Netværksforbindelser afbrydes, hvilket forårsager timeouts i applikationer.
* High-availability-klynger (som SQL Server Always On, PostgreSQL Patroni eller MySQL Galera) misser heartbeat-tjek.
* Klyngen kan antage, at den frosne node er død, hvilket udløser en unødvendig og forstyrrende failover (split-brain-scenarie).

Torn pages og I/O-forskydning

Databasemotorer skriver typisk data i specifikke sidestørrelser (f.eks. 8KB for PostgreSQL og SQL Server, 16KB for InnoDB). Det underliggende operativsystem og storage-arrays behandler dog I/O i mindre blokke (f.eks. 4KB eller 512 bytes).

Hvis en hypervisor tager et snapshot præcis mens databasen skriver en 8KB-side, kan snapshotet indfange de første 4KB af de nye data og de sidste 4KB af de gamle data. Dette skaber en torn page. Når du forsøger at gendanne snapshotet, vil databasen læse siden, fejle i checksum-valideringen og markere databasen som korrupt.

Virkelige konsekvenser for specifikke databasemotorer

Forskellige databasemotorer reagerer på crash-konsistente snapshots på forskellige måder, men ingen af dem håndterer det elegant i et produktionsmiljø.

• PostgreSQL: PostgreSQL er stærkt afhængig af pg_wal-mappen. Hvis et snapshot indfanger datamappen ($PGDATA) og WAL ude af synkronisering, vil PostgreSQL ikke kunne starte og kaste en PANIC: could not locate a valid checkpoint record-fejl.
• MySQL/InnoDB: InnoDB bruger en doublewrite-buffer til at forhindre torn pages, hvilket giver en vis beskyttelse mod crash-konsistente tilstande. Men hvis ibdata1-filen og ib_logfile indfanges ude af synkronisering, vil InnoDB-motoren crashe ved gendannelse.
• Microsoft SQL Server: SQL Server er meget følsom over for I/O-frysning. Uden korrekt VSS-integration (Volume Shadow Copy Service) vil gendannelse af en SQL Server fra et standard VM-snapshot ofte resultere i “suspect”-databaser og ødelagte logkæder, hvilket ødelægger dine muligheder for Point-in-Time Recovery (PITR).

Best practices for sikker backup af virtualiserede databaser

For at beskytte transaktionsdatabaser skal du bevæge dig fra crash-konsistente backups til applikationskonsistente backups. Dette kræver, at backup-mekanismen kommunikerer med databasemotoren, hvilket tvinger den til at tømme hukommelsen til disken og pause I/O-operationer et øjeblik, mens snapshotet tages.

1. Udnyt applikationsbevidst quiescing (VSS og fsfreeze)

Til Windows (SQL Server):
Sørg altid for, at din backup-løsning bruger Microsoft Volume Shadow Copy Service (VSS). Når en VSS-bevidst backup udløses, fryser SQL Server VSS Writer database-I/O, tømmer ventende transaktioner til disken og sikrer, at snapshotet er fuldstændig applikationskonsistent.

Til Linux (PostgreSQL / MySQL):
Linux har ikke en indbygget ækvivalent til VSS. For at opnå applikationskonsistens skal du bruge pre-freeze- og post-thaw-scripts i forbindelse med hypervisorens gæsteværktøjer (f.eks. VMware Tools).

Her er et eksempel på et VMware pre-freeze-script til PostgreSQL 15+, der sikkert forbereder databasen til et snapshot:

#!/bin/bash
# /usr/sbin/pre-freeze-script
# Sørg for, at dette script er eksekverbart (chmod +x)

# 1. Fortæl PostgreSQL at forberede sig på en backup
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""

# 2. Tøm filsystemets buffere til disken
sync

# 3. Frys filsystemet (forudsat at data ligger på /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql

Og det tilsvarende post-thaw-script for at genoptage driften:

#!/bin/bash
# /usr/sbin/post-thaw-script

# 1. Frigiv filsystemet
fsfreeze -u /var/lib/pgsql

# 2. Fortæl PostgreSQL at backuppen er fuldført
su - postgres -c "psql -c "SELECT pg_backup_stop();""

2. Brug native database-backupværktøjer

Selvom applikationskonsistente snapshots er bedre end standard-snapshots, bærer de stadig risikoen for VM-stun. Den sikreste tilgang til database-backups er at bruge native, streamende backup-værktøjer, der opererer uafhængigt af hypervisoren.

PostgreSQL (pg_basebackup):

pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P

MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Disse værktøjer tager “hot”, ikke-blokerende backups ved at kopiere datafilerne og samtidig spore ændringer i redo-loggen.

mariabackup --backup --target-dir=/mnt/backups/mysql_backup --user=root --password=SecurePass

SQL Server (T-SQL):

BACKUP DATABASE [ProductionDB] 
TO DISK = N'Z:BackupsProductionDB.bak' 
WITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
GO

3. Implementer Point-in-Time Recovery (PITR) via log-arkivering

Et dagligt snapshot eller en fuld backup beskytter dig kun op til det minut, det blev taget. Hvis din database crasher kl. 16:00, og dit sidste snapshot var kl. 02:00, mister du 14 timers transaktionsdata.

For at opnå ægte enterprise-resiliens skal du kombinere fulde applikationskonsistente backups med kontinuerlig log-arkivering (backup af WAL, Redo Logs eller Transaction Logs hvert par minutter). Dette giver DBA’er mulighed for at gendanne databasen til et specifikt minut eller endda et specifikt transaktions-ID før en katastrofe.

Enterprise backup-strategier med CloudSave

At administrere tilpassede pre-freeze-scripts, cron-jobs til native dumps og log-shipping på tværs af dusinvis af databaseservere er et operationelt mareridt for DevOps-teams. Det er her, en enterprise-platform som CloudSave bliver kritisk.

CloudSave bygger bro mellem virtualisering og databasearkitektur. I stedet for at stole på blinde hypervisor-snapshots, bruger CloudSave applikationsbevidste agenter, der integreres native med SQL Server, PostgreSQL, MySQL og Oracle.

Når CloudSave initierer en backup:
1. Kommunikerer den direkte med databasemotoren via native API’er (som VSS til Windows eller native WAL-streaming til Linux).
2. Orkestrerer den tømning af hukommelsesbuffere til disken uden at forårsage forstyrrende VM-stuns.
3. Indfanger den sikkert datafilerne og administrerer automatisk trunkering af transaktionslogs.
4. Tager den kontinuerlig backup af transaktionslogs, hvilket muliggør granulær Point-in-Time Recovery (PITR) med få klik.

Ved at udlicitere kompleksiteten af applikationskonsistens til CloudSave kan DBA’er og sysadmins garantere dataintegritet uden at ofre ydeevnen eller tilgængeligheden af deres produktionsklynger.

Konklusion

Snapshots af virtuelle maskiner er et fantastisk værktøj til infrastrukturstyring, men de er fundamentalt uforenelige med ACID-kravene i transaktionsdatabaser. At stole på crash-konsistente hypervisor-snapshots udsætter din organisation for torn pages, ødelagte replikeringskæder og katastrofalt datatab.

For at beskytte dine forretningskritiske data skal du implementere applikationsbevidst quiescing, bruge native database-backupmetoder og vedligeholde kontinuerlige transaktionslog-arkiver. Ved at adoptere specialbyggede enterprise-backup-løsninger kan du sikre, at dine databaser forbliver højtilgængelige, fuldt gendannelige og fuldstændig sikre.