Waarom VM-snapshots niet veilig zijn voor transactionele databases: een gids voor DBA’s over gegevensintegriteit

Voor DevOps-engineers en systeembeheerders zijn snapshots van virtuele machines (VM’s) een fundamenteel hulpmiddel. Ze bieden een snelle, handige manier om de status van een server vast te leggen vóór een risicovolle patch, een grote configuratiewijziging of een applicatie-implementatie. Als er iets misgaat, duurt het terugdraaien slechts seconden.

Wanneer dezezelfde methodologie echter wordt toegepast op transactionele databases—zoals PostgreSQL, MySQL, Oracle of Microsoft SQL Server—veranderen VM-snapshots van een vangnet in een tikkende tijdbom.

Vertrouwen op standaard hypervisor-snapshots voor databaseback-ups is een van de meest voorkomende oorzaken van datacorruptie, ’torn pages’ en onherstelbare productie-uitval. In dit artikel onderzoeken we de architecturale botsing tussen hypervisors en database-engines, de mechanismen van datacorruptie tijdens snapshots en de best practices op engineeringgebied die nodig zijn om gevirtualiseerde databases veilig te back-uppen.

De architecturale botsing: Hypervisors vs. Database-engines

Om te begrijpen waarom VM-snapshots databases in gevaar brengen, moeten we eerst onderzoeken hoe beide systemen de status en I/O-operaties beheren.

Hoe hypervisors snapshots uitvoeren

Wanneer een hypervisor (zoals VMware ESXi, Microsoft Hyper-V of KVM) een snapshot maakt, kopieert deze de schijf niet. In plaats daarvan bevriest hij het huidige virtuele schijfbestand (bijv. .vmdk of .vhdx) in een alleen-lezen status en maakt hij een nieuwe delta-schijf (verschilschijf) aan. Alle daaropvolgende schrijfacties worden naar deze delta-schijf gestuurd.

Wanneer de snapshot wordt verwijderd, moet de hypervisor de gegevens van de delta-schijf terugschrijven (consolideren) naar de basisschijf. Standaard snapshots zijn zich totaal niet bewust van de applicaties die in het gastbesturingssysteem draaien. Ze leggen de schijfstatus exact vast zoals deze op die microseconde bestaat.

Hoe transactionele databases de status beheren

Transactionele databases zijn ontworpen rond ACID-eigenschappen (Atomicity, Consistency, Isolation, Durability). Om hoge prestaties te behalen en tegelijkertijd ACID-compliance te behouden, schrijven databases niet elke transactie direct naar de primaire databestanden op de schijf. In plaats daarvan gebruiken ze een complexe, gelaagde architectuur:

1. Buffer Pool / Shared Buffers: Gegevens worden in het systeemgeheugen gelezen en gewijzigd.
2. Write-Ahead Log (WAL) / Redo Logs: Wijzigingen worden sequentieel naar een sterk geoptimaliseerd logbestand op de schijf geschreven om duurzaamheid te garanderen.
3. Checkpoints / Lazy Writers: Periodiek spoelt de database de gewijzigde (dirty) pagina’s uit het geheugen naar de daadwerkelijke databestanden op de schijf.

Vanwege deze architectuur zijn de fysieke databestanden op de schijf bijna altijd niet synchroon met de werkelijke status van de database. De ware status van de database bestaat alleen als een combinatie van de databestanden op de schijf, de WAL/Redo-logs en de gegevens die momenteel in het geheugen staan.

De gevarenzone: Wat gebeurt er tijdens een VM-snapshot

Wanneer u een standaard VM-snapshot van een databaseserver maakt, legt u een crash-consistente status vast.

Crash-consistentie vs. Applicatie-consistentie

Een crash-consistente snapshot is het equivalent van het lostrekken van de stroomkabel van de fysieke server. De schijfstatus wordt vastgelegd, maar alles wat in het geheugen stond is verloren, en alles wat onderweg was naar de opslagcontroller wordt abrupt afgesneden.

Hoewel moderne databases zijn ontworpen om te herstellen van onverwacht stroomverlies door het Write-Ahead Log opnieuw af te spelen, is vertrouwen op crashherstel als uw primaire back-upstrategie zeer gevaarlijk. Als uw database meerdere virtuele schijven beslaat (bijv. databestanden op Drive D: en WAL op Drive E:), maakt de hypervisor mogelijk niet op exact dezelfde microseconde een snapshot van beide schijven. Als de snapshot van de WAL-schijf zelfs een fractie van een seconde na de snapshot van de gegevensschijf wordt gemaakt, kan de database de volgnummers bij het herstel niet reconciliëren, wat resulteert in fatale corruptie.

Het “VM Stun”-effect op systemen met veel transacties

Het proces van het maken van een snapshot—en nog belangrijker, het proces van snapshot-consolidatie—veroorzaakt een fenomeen dat bekend staat als “VM Stun”.

Om I/O veilig van de basisschijf naar de delta-schijf te schakelen, moet de hypervisor de virtuele machine kort pauzeren (stunnen). Voor een licht belaste webserver kan deze stun 10-50 milliseconden duren en onopgemerkt blijven. Voor een database met een hoge doorvoer en enorme I/O kan het consolideren van een grote delta-schijf de VM echter enkele seconden stunnen.

Tijdens een VM stun:
* Verbreken netwerkverbindingen, wat leidt tot time-outs van applicaties.
* Missen high-availability clusters (zoals SQL Server Always On, PostgreSQL Patroni of MySQL Galera) heartbeat-checks.
* Kan het cluster aannemen dat de gestunnde node dood is, wat een onnodige en verstorende failover (split-brain scenario) activeert.

Torn pages en I/O-misalignment

Database-engines schrijven gegevens doorgaans in specifieke paginagroottes (bijv. 8KB voor PostgreSQL en SQL Server, 16KB voor InnoDB). Het onderliggende besturingssysteem en de opslagarrays verwerken I/O echter in kleinere blokken (bijv. 4KB of 512 bytes).

Als een hypervisor een snapshot maakt precies terwijl de database een 8KB-pagina schrijft, kan de snapshot de eerste 4KB van de nieuwe gegevens en de laatste 4KB van de oude gegevens vastleggen. Dit creëert een torn page. Wanneer u probeert de snapshot te herstellen, zal de database de pagina lezen, de checksum-validatie niet doorstaan en de database als corrupt markeren.

Gevolgen in de praktijk voor specifieke database-engines

Verschillende database-engines reageren op verschillende manieren op crash-consistente snapshots, maar geen van hen gaat er in een productieomgeving netjes mee om.

• PostgreSQL: PostgreSQL vertrouwt zwaar op de pg_wal-directory. Als een snapshot de datadirectory ($PGDATA) en de WAL niet synchroon vastlegt, zal PostgreSQL niet opstarten en de foutmelding PANIC: could not locate a valid checkpoint record geven.
• MySQL/InnoDB: InnoDB gebruikt een doublewrite-buffer om torn pages te voorkomen, wat enige bescherming biedt tegen crash-consistente statussen. Als het ibdata1-bestand en het ib_logfile echter niet synchroon worden vastgelegd, zal de InnoDB-engine crashen bij herstel.
• Microsoft SQL Server: SQL Server is zeer gevoelig voor het bevriezen van I/O. Zonder de juiste VSS-integratie (Volume Shadow Copy Service) zal het herstellen van een SQL Server vanaf een standaard VM-snapshot vaak resulteren in ‘suspect’ databases en verbroken log-ketens, waardoor uw Point-in-Time Recovery (PITR)-mogelijkheden worden vernietigd.

Best practices voor het veilig back-uppen van gevirtualiseerde databases

Om transactionele databases te beschermen, moet u overstappen van crash-consistente back-ups naar applicatie-consistente back-ups. Dit vereist dat het back-upmechanisme communiceert met de database-engine, waardoor deze wordt gedwongen het geheugen naar de schijf te spoelen en I/O-operaties tijdelijk te pauzeren terwijl de snapshot wordt gemaakt.

1. Maak gebruik van applicatie-bewuste quiescing (VSS en fsfreeze)

Voor Windows (SQL Server):
Zorg er altijd voor dat uw back-upoplossing gebruikmaakt van de Microsoft Volume Shadow Copy Service (VSS). Wanneer een VSS-bewuste back-up wordt geactiveerd, bevriest de SQL Server VSS Writer de database-I/O, spoelt hij lopende transacties naar de schijf en zorgt hij ervoor dat de snapshot perfect applicatie-consistent is.

Voor Linux (PostgreSQL / MySQL):
Linux heeft geen native equivalent van VSS. Om applicatie-consistentie te bereiken, moet u pre-freeze en post-thaw scripts gebruiken in combinatie met de gasttools van de hypervisor (bijv. VMware Tools).

Hier is een voorbeeld van een VMware pre-freeze-script voor PostgreSQL 15+ dat de database veilig voorbereidt op een snapshot:

#!/bin/bash
# /usr/sbin/pre-freeze-script
# Zorg ervoor dat dit script uitvoerbaar is (chmod +x)

# 1. Vertel PostgreSQL om zich voor te bereiden op een back-up
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""

# 2. Spoel bestandssysteembuffers naar de schijf
sync

# 3. Bevries het bestandssysteem (ervan uitgaande dat gegevens op /var/lib/pgsql staan)
fsfreeze -f /var/lib/pgsql

En het bijbehorende post-thaw-script om de operaties te hervatten:

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

# 1. Ontdooi het bestandssysteem
fsfreeze -u /var/lib/pgsql

# 2. Vertel PostgreSQL dat de back-up voltooid is
su - postgres -c "psql -c "SELECT pg_backup_stop();""

2. Gebruik native database back-uphulpprogramma’s

Hoewel applicatie-consistente snapshots beter zijn dan standaard snapshots, dragen ze nog steeds het risico op VM stun met zich mee. De veiligste aanpak voor databaseback-ups is het gebruik van native, streaming back-uphulpprogramma’s die onafhankelijk van de hypervisor werken.

PostgreSQL (pg_basebackup):

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

MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Deze tools maken hot, non-blocking back-ups door de databestanden te kopiëren en tegelijkertijd wijzigingen in het redo-logboek bij te houden.

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. Implementeer Point-in-Time Recovery (PITR) via log-archivering

Een dagelijkse snapshot of volledige back-up beschermt u alleen tot het moment dat deze werd gemaakt. Als uw database crasht om 16:00 uur en uw laatste snapshot was om 02:00 uur, verliest u 14 uur aan transactionele gegevens.

Om echte enterprise-resilience te bereiken, moet u volledige applicatie-consistente back-ups combineren met continue log-archivering (het elke paar minuten back-uppen van de WAL, Redo Logs of Transaction Logs). Hierdoor kunnen DBA’s de database herstellen tot een specifiek minuut of zelfs een specifiek transactie-ID vóór een ramp.

Enterprise back-upstrategieën met CloudSave

Het beheren van aangepaste pre-freeze scripts, cron-jobs voor native dumps en log-shipping over tientallen databaseservers is een operationele nachtmerrie voor DevOps-teams. Dit is waar een enterprise-grade platform zoals CloudSave cruciaal wordt.

CloudSave overbrugt de kloof tussen virtualisatie en database-architectuur. In plaats van te vertrouwen op blinde hypervisor-snapshots, gebruikt CloudSave applicatie-bewuste agents die native integreren met SQL Server, PostgreSQL, MySQL en Oracle.

Wanneer CloudSave een back-up start:
1. Communiceert het direct met de database-engine via native API’s (zoals VSS voor Windows of native WAL-streaming voor Linux).
2. Orchestreert het het spoelen van geheugenbuffers naar de schijf zonder verstorende VM-stuns te veroorzaken.
3. Legt het veilig de databestanden vast en beheert het automatisch de truncatie van transactielogs.
4. Back-upt het continu transactielogs, waardoor granulaire Point-in-Time Recovery (PITR) met een paar klikken mogelijk wordt.

Door de complexiteit van applicatie-consistentie uit te besteden aan CloudSave, kunnen DBA’s en systeembeheerders de gegevensintegriteit garanderen zonder de prestaties of beschikbaarheid van hun productieclusters op te offeren.

Conclusie

Snapshots van virtuele machines zijn een ongelooflijk hulpmiddel voor infrastructuurbeheer, maar ze zijn fundamenteel onverenigbaar met de ACID-vereisten van transactionele databases. Vertrouwen op crash-consistente hypervisor-snapshots stelt uw organisatie bloot aan torn pages, verbroken replicatieketens en catastrofaal gegevensverlies.

Om uw bedrijfskritieke gegevens te beschermen, moet u applicatie-bewuste quiescing implementeren, native back-upmethodologieën voor databases gebruiken en continue archieven van transactielogs bijhouden. Door gebruik te maken van speciaal gebouwde enterprise back-upoplossingen, kunt u ervoor zorgen dat uw databases zeer beschikbaar, volledig herstelbaar en volledig veilig blijven.