For DevOps-ingeni\u00f8rer og systemadministratorer er snapshots af virtuelle maskiner (VM) et fundamentalt v\u00e6rkt\u00f8j. De giver en hurtig og bekvem m\u00e5de at indfange tilstanden af en server f\u00f8r en risikabel opdatering, en st\u00f8rre konfigurations\u00e6ndring eller en applikationsudrulning. Hvis noget g\u00e5r galt, tager det kun f\u00e5 sekunder at rulle tilbage.<\/p>\n
Men n\u00e5r den samme metode anvendes p\u00e5 transaktionsdatabaser \u2013 s\u00e5som PostgreSQL, MySQL, Oracle eller Microsoft SQL Server \u2013 forvandles VM-snapshots fra et sikkerhedsnet til en tikkende bombe.<\/p>\n
At stole p\u00e5 standard hypervisor-snapshots til database-backups er en af de mest almindelige \u00e5rsager 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\u00e6ves for sikkert at tage backup af virtualiserede databaser.<\/p>\n
For at forst\u00e5, hvorfor VM-snapshots bringer databaser i fare, m\u00e5 vi f\u00f8rst unders\u00f8ge, hvordan begge systemer h\u00e5ndterer tilstand og I\/O-operationer.<\/p>\n
N\u00e5r en hypervisor (s\u00e5som VMware ESXi, Microsoft Hyper-V eller KVM) tager et snapshot, kopierer den ikke disken. I stedet fryser den den nuv\u00e6rende virtuelle diskfil (f.eks. N\u00e5r snapshotet slettes, skal hypervisoren committe (konsolidere) dataene fra delta-disken tilbage til basisdisken. Standard-snapshots er fuldst\u00e6ndig uvidende om de applikationer, der k\u00f8rer inde i g\u00e6steoperativsystemet. De indfanger diskens tilstand pr\u00e6cis, som den eksisterer i det mikrosekund.<\/p>\n Transaktionsdatabaser er designet omkring ACID-egenskaber (Atomicity, Consistency, Isolation, Durability). For at opn\u00e5 h\u00f8j ydeevne og samtidig opretholde ACID-overholdelse, skriver databaser ikke hver transaktion direkte til de prim\u00e6re datafiler p\u00e5 disken med det samme. I stedet bruger de en kompleks arkitektur i flere lag:<\/p>\n P\u00e5 grund af denne arkitektur er de fysiske datafiler p\u00e5 disken n\u00e6sten altid ude af synkronisering med databasens faktiske tilstand. Databasens sande tilstand eksisterer kun som en kombination af datafilerne p\u00e5 disken, WAL\/Redo-logfilerne og de data, der i \u00f8jeblikket ligger i hukommelsen.<\/p>\n N\u00e5r du tager et standard VM-snapshot af en databaseserver, indfanger du en crash-konsistent<\/strong> tilstand.<\/p>\n Et crash-konsistent snapshot svarer til at tr\u00e6kke str\u00f8mstikket ud af den fysiske server. Diskens tilstand indfanges, men alt, hvad der l\u00e5 i hukommelsen, g\u00e5r tabt, og alt, hvad der var undervejs til storage-controlleren, bliver brat afbrudt.<\/p>\n Selvom moderne databaser er designet til at genoprette efter uventet str\u00f8msvigt ved at afspille Write-Ahead Loggen, er det yderst farligt at stole p\u00e5 crash-recovery som din prim\u00e6re backup-strategi. Hvis din database sp\u00e6nder over flere virtuelle diske (f.eks. datafiler p\u00e5 Processen med at oprette et snapshot \u2013 og endnu vigtigere, processen med at konsolidere det \u2013 for\u00e5rsager et f\u00e6nomen kendt som “VM Stun”.<\/p>\n 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\u00e5 ubem\u00e6rket hen. Men for en database med h\u00f8j gennemstr\u00f8mning og massiv I\/O kan konsolidering af en stor delta-disk fryse VM’en i flere sekunder.<\/p>\n Under et VM-stun: Databasemotorer skriver typisk data i specifikke sidest\u00f8rrelser (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).<\/p>\n Hvis en hypervisor tager et snapshot pr\u00e6cis mens databasen skriver en 8KB-side, kan snapshotet indfange de f\u00f8rste 4KB af de nye data og de sidste 4KB af de gamle data. Dette skaber en torn page<\/strong>. N\u00e5r du fors\u00f8ger at gendanne snapshotet, vil databasen l\u00e6se siden, fejle i checksum-valideringen og markere databasen som korrupt.<\/p>\n Forskellige databasemotorer reagerer p\u00e5 crash-konsistente snapshots p\u00e5 forskellige m\u00e5der, men ingen af dem h\u00e5ndterer det elegant i et produktionsmilj\u00f8.<\/p>\n For at beskytte transaktionsdatabaser skal du bev\u00e6ge dig fra crash-konsistente backups til applikationskonsistente<\/strong> backups. Dette kr\u00e6ver, at backup-mekanismen kommunikerer med databasemotoren, hvilket tvinger den til at t\u00f8mme hukommelsen til disken og pause I\/O-operationer et \u00f8jeblik, mens snapshotet tages.<\/p>\n Til Windows (SQL Server):<\/strong> Til Linux (PostgreSQL \/ MySQL):<\/strong> Her er et eksempel p\u00e5 et VMware Og det tilsvarende Selvom applikationskonsistente snapshots er bedre end standard-snapshots, b\u00e6rer de stadig risikoen for VM-stun. Den sikreste tilgang til database-backups er at bruge native, streamende backup-v\u00e6rkt\u00f8jer, der opererer uafh\u00e6ngigt af hypervisoren.<\/p>\n PostgreSQL (pg_basebackup):<\/strong><\/p>\n MySQL\/MariaDB (Percona XtraBackup \/ Mariabackup):<\/strong> SQL Server (T-SQL):<\/strong><\/p>\n 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.<\/p>\n For at opn\u00e5 \u00e6gte 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\u00f8r en katastrofe.<\/p>\n At administrere tilpassede pre-freeze-scripts, cron-jobs til native dumps og log-shipping p\u00e5 tv\u00e6rs af dusinvis af databaseservere er et operationelt mareridt for DevOps-teams. Det er her, en enterprise-platform som CloudSave bliver kritisk.<\/p>\n CloudSave bygger bro mellem virtualisering og databasearkitektur. I stedet for at stole p\u00e5 blinde hypervisor-snapshots, bruger CloudSave applikationsbevidste agenter, der integreres native med SQL Server, PostgreSQL, MySQL og Oracle.<\/p>\n N\u00e5r CloudSave initierer en backup: Ved at udlicitere kompleksiteten af applikationskonsistens til CloudSave kan DBA’er og sysadmins garantere dataintegritet uden at ofre ydeevnen eller tilg\u00e6ngeligheden af deres produktionsklynger.<\/p>\n Snapshots af virtuelle maskiner er et fantastisk v\u00e6rkt\u00f8j til infrastrukturstyring, men de er fundamentalt uforenelige med ACID-kravene i transaktionsdatabaser. At stole p\u00e5 crash-konsistente hypervisor-snapshots uds\u00e6tter din organisation for torn pages, \u00f8delagte replikeringsk\u00e6der og katastrofalt datatab.<\/p>\n 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\u00f8sninger kan du sikre, at dine databaser forbliver h\u00f8jtilg\u00e6ngelige, fuldt gendannelige og fuldst\u00e6ndig sikre.<\/p>\n","protected":false},"excerpt":{"rendered":" > Discover why standard VM snapshots cause data corruption in transactional databases like PostgreSQL and SQL Server. Learn DBA best practices for application-consistent backups, avoiding VM stun, and ensuring data integrity with CloudSave.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"Why VM Snapshots Are Unsafe for Transactional Databases","rank_math_description":"> Discover why standard VM snapshots cause data corruption in transactional databases like PostgreSQL and SQL Server. Learn DBA best practices for application-consistent backups, avoiding VM stun, and ensuring data integrity with CloudSave.","rank_math_focus_keyword":"VM snapshots transactional databases","footnotes":""},"categories":[391],"tags":[3328,3614,3615,3616,3617,3618,3619],"class_list":["post-5475","post","type-post","status-publish","format-standard","hentry","category-database-backup","tag-data-integrity","tag-database-corruption","tag-database-recovery","tag-dba-guide","tag-hypervisor-snapshots","tag-transactional-databases","tag-vm-snapshots"],"yoast_head":"\n.vmdk<\/code> eller .vhdx<\/code>) i en skrivebeskyttet tilstand og opretter en ny delta-disk (differencing disk). Alle efterf\u00f8lgende skrivninger dirigeres til denne delta-disk.<\/p>\nHvordan transaktionsdatabaser h\u00e5ndterer tilstand<\/h3>\n
\n
Farezonen: Hvad sker der under et VM-snapshot<\/h2>\n
Crash-konsistens vs. applikationskonsistens<\/h3>\n
Drev D:<\/code> og WAL p\u00e5 Drev E:<\/code>), tager hypervisoren m\u00e5ske ikke snapshot af begge diske i pr\u00e6cis samme mikrosekund. Hvis WAL-diskens snapshot indfanges blot en br\u00f8kdel af et sekund efter data-diskens snapshot, kan databasen ikke afstemme sekvensnumrene ved gendannelse, hvilket resulterer i fatal korruption.<\/p>\n“VM Stun”-effekten p\u00e5 systemer med mange transaktioner<\/h3>\n
\n* Netv\u00e6rksforbindelser afbrydes, hvilket for\u00e5rsager timeouts i applikationer.
\n* High-availability-klynger (som SQL Server Always On, PostgreSQL Patroni eller MySQL Galera) misser heartbeat-tjek.
\n* Klyngen kan antage, at den frosne node er d\u00f8d, hvilket udl\u00f8ser en un\u00f8dvendig og forstyrrende failover (split-brain-scenarie).<\/p>\nTorn pages og I\/O-forskydning<\/h3>\n
Virkelige konsekvenser for specifikke databasemotorer<\/h2>\n
\n
pg_wal<\/code>-mappen. Hvis et snapshot indfanger datamappen ($PGDATA<\/code>) og WAL ude af synkronisering, vil PostgreSQL ikke kunne starte og kaste en PANIC: could not locate a valid checkpoint record<\/code>-fejl.<\/li>\nibdata1<\/code>-filen og ib_logfile<\/code> indfanges ude af synkronisering, vil InnoDB-motoren crashe ved gendannelse.<\/li>\nBest practices for sikker backup af virtualiserede databaser<\/h2>\n
1. Udnyt applikationsbevidst quiescing (VSS og fsfreeze)<\/h3>\n
\nS\u00f8rg altid for, at din backup-l\u00f8sning bruger Microsoft Volume Shadow Copy Service (VSS). N\u00e5r en VSS-bevidst backup udl\u00f8ses, fryser SQL Server VSS Writer database-I\/O, t\u00f8mmer ventende transaktioner til disken og sikrer, at snapshotet er fuldst\u00e6ndig applikationskonsistent.<\/p>\n
\nLinux har ikke en indbygget \u00e6kvivalent til VSS. For at opn\u00e5 applikationskonsistens skal du bruge pre-freeze- og post-thaw-scripts i forbindelse med hypervisorens g\u00e6stev\u00e6rkt\u00f8jer (f.eks. VMware Tools).<\/p>\npre-freeze-script<\/code> til PostgreSQL 15+, der sikkert forbereder databasen til et snapshot:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# S\u00f8rg for, at dette script er eksekverbart (chmod +x)\n\n# 1. Fort\u00e6l PostgreSQL at forberede sig p\u00e5 en backup\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. T\u00f8m filsystemets buffere til disken\nsync\n\n# 3. Frys filsystemet (forudsat at data ligger p\u00e5 \/var\/lib\/pgsql)\nfsfreeze -f \/var\/lib\/pgsql\n<\/code><\/pre>\npost-thaw-script<\/code> for at genoptage driften:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/post-thaw-script\n\n# 1. Frigiv filsystemet\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Fort\u00e6l PostgreSQL at backuppen er fuldf\u00f8rt\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. Brug native database-backupv\u00e6rkt\u00f8jer<\/h3>\n
pg_basebackup -h localhost -U replication_user -D \/mnt\/backups\/pg_backup -Ft -z -P\n<\/code><\/pre>\n
\nDisse v\u00e6rkt\u00f8jer tager “hot”, ikke-blokerende backups ved at kopiere datafilerne og samtidig spore \u00e6ndringer i redo-loggen.<\/p>\nmariabackup --backup --target-dir=\/mnt\/backups\/mysql_backup --user=root --password=SecurePass\n<\/code><\/pre>\nBACKUP DATABASE [ProductionDB] \nTO DISK = N'Z:BackupsProductionDB.bak' \nWITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup', \nSKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;\nGO\n<\/code><\/pre>\n3. Implementer Point-in-Time Recovery (PITR) via log-arkivering<\/h3>\n
Enterprise backup-strategier med CloudSave<\/h2>\n
\n1. Kommunikerer den direkte med databasemotoren via native API’er (som VSS til Windows eller native WAL-streaming til Linux).
\n2. Orkestrerer den t\u00f8mning af hukommelsesbuffere til disken uden at for\u00e5rsage forstyrrende VM-stuns.
\n3. Indfanger den sikkert datafilerne og administrerer automatisk trunkering af transaktionslogs.
\n4. Tager den kontinuerlig backup af transaktionslogs, hvilket muligg\u00f8r granul\u00e6r Point-in-Time Recovery (PITR) med f\u00e5 klik.<\/p>\nKonklusion<\/h2>\n