For DevOps-ingeni\u00f8rer og systemadministratorer er \u00f8yeblikksbilder (snapshots) av virtuelle maskiner (VM) et grunnleggende verkt\u00f8y. De gir en rask og praktisk m\u00e5te \u00e5 fange tilstanden til en server f\u00f8r en risikabel oppdatering, en st\u00f8rre konfigurasjonsendring eller en applikasjonsdistribusjon. Hvis noe g\u00e5r galt, tar det bare sekunder \u00e5 rulle tilbake.<\/p>\n
Men n\u00e5r den samme metoden brukes p\u00e5 transaksjonsdatabaser \u2013 som PostgreSQL, MySQL, Oracle eller Microsoft SQL Server \u2013 forvandles VM-snapshots fra et sikkerhetsnett til en tikkende tidsinnstilt bombe.<\/p>\n
\u00c5 stole p\u00e5 standard hypervisor-snapshots for databasesikkerhetskopiering er en av de vanligste \u00e5rsakene til datakorrupsjon, \u00f8delagte sider (torn pages) og uopprettelige produksjonsavbrudd. I denne artikkelen vil vi utforske den arkitektoniske konflikten mellom hypervisorer og databasemotorer, mekanikken bak datakorrupsjon under snapshots, og beste praksis for ingeni\u00f8rarbeid som kreves for \u00e5 sikkerhetskopiere virtualiserte databaser p\u00e5 en trygg m\u00e5te.<\/p>\n
For \u00e5 forst\u00e5 hvorfor VM-snapshots utgj\u00f8r en fare for databaser, m\u00e5 vi f\u00f8rst unders\u00f8ke hvordan begge systemene h\u00e5ndterer tilstand og I\/O-operasjoner.<\/p>\n
N\u00e5r en hypervisor (som VMware ESXi, Microsoft Hyper-V eller KVM) tar et snapshot, kopierer den ikke disken. I stedet fryser den den n\u00e5v\u00e6rende virtuelle diskfilen (f.eks. N\u00e5r snapshotet slettes, m\u00e5 hypervisoren «commit»-e (konsolidere) dataene fra deltadisken tilbake til basisdisken. Standard snapshots er fullstendig uvitende om applikasjonene som kj\u00f8rer inne i gjesteoperativsystemet. De fanger diskens tilstand n\u00f8yaktig slik den eksisterer i det mikrosekundet.<\/p>\n Transaksjonsdatabaser er designet rundt ACID-egenskaper (Atomicity, Consistency, Isolation, Durability). For \u00e5 oppn\u00e5 h\u00f8y ytelse samtidig som ACID-samsvar opprettholdes, skriver ikke databaser hver transaksjon direkte til de prim\u00e6re datafilene p\u00e5 disken umiddelbart. I stedet bruker de en kompleks arkitektur i flere lag:<\/p>\n P\u00e5 grunn av denne arkitekturen er de fysiske datafilene p\u00e5 disken nesten alltid ute av synkronisering med databasens faktiske tilstand. Databasens sanne tilstand eksisterer kun som en kombinasjon av datafilene p\u00e5 disken, WAL\/Redo-loggene og dataene som for \u00f8yeblikket ligger i minnet.<\/p>\n N\u00e5r du tar et standard VM-snapshot av en databaseserver, fanger du en krasj-konsistent<\/strong> tilstand.<\/p>\n Et krasj-konsistent snapshot tilsvarer \u00e5 trekke ut str\u00f8mkabelen fra den fysiske serveren. Disktilstanden fanges opp, men alt som l\u00e5 i minnet g\u00e5r tapt, og alt som var underveis til lagringskontrolleren blir br\u00e5tt avbrutt.<\/p>\n Selv om moderne databaser er designet for \u00e5 gjenopprette fra uventet str\u00f8mbrudd ved \u00e5 spille av Write-Ahead-loggen, er det sv\u00e6rt farlig \u00e5 stole p\u00e5 krasjgjenoppretting som din prim\u00e6re sikkerhetskopieringsstrategi. Hvis databasen din spenner over flere virtuelle disker (f.eks. datafiler p\u00e5 Prosessen med \u00e5 opprette et snapshot \u2013 og enda viktigere, prosessen med \u00e5 konsolidere snapshotet \u2013 for\u00e5rsaker et fenomen kjent som «VM Stun».<\/p>\n For \u00e5 trygt bytte I\/O fra basisdisken til deltadisken, m\u00e5 hypervisoren kort pause (stune) den virtuelle maskinen. For en lett belastet webserver kan denne pausen vare i 10-50 millisekunder og g\u00e5 ubemerket hen. Men for en database med h\u00f8y gjennomstr\u00f8mning og massiv I\/O, kan konsolidering av en stor deltadisk «stune» VM-en i flere sekunder.<\/p>\n Under en VM-stun: Databasemotorer skriver vanligvis data i spesifikke sidest\u00f8rrelser (f.eks. 8 KB for PostgreSQL og SQL Server, 16 KB for InnoDB). Det underliggende operativsystemet og lagringsmatrisene behandler imidlertid I\/O i mindre blokker (f.eks. 4 KB eller 512 byte).<\/p>\n Hvis en hypervisor tar et snapshot n\u00f8yaktig mens databasen skriver en 8 KB-side, kan snapshotet fange de f\u00f8rste 4 KB av de nye dataene og de siste 4 KB av de gamle dataene. Dette skaper en \u00f8delagt side (torn page)<\/strong>. N\u00e5r du pr\u00f8ver \u00e5 gjenopprette snapshotet, vil databasen lese siden, feile i kontrollsumvalideringen og markere databasen som korrupt.<\/p>\n Ulike databasemotorer reagerer p\u00e5 krasj-konsistente snapshots p\u00e5 ulike m\u00e5ter, men ingen av dem h\u00e5ndterer det elegant i et produksjonsmilj\u00f8.<\/p>\n For \u00e5 beskytte transaksjonsdatabaser m\u00e5 du g\u00e5 fra krasj-konsistente sikkerhetskopier til applikasjonskonsistente<\/strong> sikkerhetskopier. Dette krever at sikkerhetskopieringsmekanismen kommuniserer med databasemotoren, og tvinger den til \u00e5 t\u00f8mme minnet til disken og pause I\/O-operasjoner et \u00f8yeblikk mens snapshotet tas.<\/p>\n For Windows (SQL Server):<\/strong> For Linux (PostgreSQL \/ MySQL):<\/strong> Her er et eksempel p\u00e5 et VMware Og det tilh\u00f8rende Selv om applikasjonskonsistente snapshots er bedre enn standard snapshots, b\u00e6rer de fortsatt risikoen for «VM stun». Den sikreste tiln\u00e6rmingen for databasesikkerhetskopiering er \u00e5 bruke innebygde, str\u00f8mmende sikkerhetskopieringsverkt\u00f8y som opererer uavhengig av hypervisoren.<\/p>\n PostgreSQL (pg_basebackup):<\/strong><\/p>\n MySQL\/MariaDB (Percona XtraBackup \/ Mariabackup):<\/strong> SQL Server (T-SQL):<\/strong><\/p>\n Et daglig snapshot eller en fullstendig sikkerhetskopi beskytter deg bare frem til minuttet den ble tatt. Hvis databasen krasjer kl. 16:00 og ditt siste snapshot var kl. 02:00, mister du 14 timer med transaksjonsdata.<\/p>\n For \u00e5 oppn\u00e5 ekte bedriftsresiliens m\u00e5 du kombinere fullstendige applikasjonskonsistente sikkerhetskopier med kontinuerlig loggarkivering (sikkerhetskopiering av WAL, Redo-logger eller transaksjonslogger hvert par minutter). Dette gj\u00f8r at databaseadministratorer kan gjenopprette databasen til et spesifikt minutt eller til og med en spesifikk transaksjons-ID f\u00f8r en katastrofe inntraff.<\/p>\n \u00c5 administrere tilpassede «pre-freeze»-skript, cron-jobber for innebygde dumper og loggforsendelse p\u00e5 tvers av dusinvis av databaseservere er et operasjonelt mareritt for DevOps-team. Det er her en plattform i bedriftsklassen som CloudSave blir kritisk.<\/p>\n CloudSave bygger bro mellom virtualisering og databasearkitektur. I stedet for \u00e5 stole p\u00e5 blinde hypervisor-snapshots, bruker CloudSave applikasjonsbevisste agenter som integreres direkte med SQL Server, PostgreSQL, MySQL og Oracle.<\/p>\n N\u00e5r CloudSave initierer en sikkerhetskopi: Ved \u00e5 overlate kompleksiteten med applikasjonskonsistens til CloudSave, kan databaseadministratorer og systemadministratorer garantere dataintegritet uten \u00e5 ofre ytelsen eller tilgjengeligheten til produksjonsklyngene sine.<\/p>\n \u00d8yeblikksbilder av virtuelle maskiner er et utrolig verkt\u00f8y for infrastrukturstyring, men de er fundamentalt uforenlige med ACID-kravene til transaksjonsdatabaser. \u00c5 stole p\u00e5 krasj-konsistente hypervisor-snapshots eksponerer organisasjonen din for \u00f8delagte sider, \u00f8delagte replikeringskjeder og katastrofalt datatap.<\/p>\n For \u00e5 beskytte dine forretningskritiske data m\u00e5 du implementere applikasjonsbevisst «quiescing», bruke innebygde metoder for databasesikkerhetskopiering og opprettholde kontinuerlige arkiver av transaksjonslogger. Ved \u00e5 ta i bruk spesialbygde sikkerhetskopieringsl\u00f8sninger for bedrifter, kan du sikre at databasene dine forblir h\u00f8yt tilgjengelige, fullstendig gjenopprettbare og helt 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":[591],"tags":[3428,3764,3765,3766,3767,3768,3769],"class_list":["post-5501","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 oppretter en ny deltadisk (differensieringsdisk). Alle p\u00e5f\u00f8lgende skriveoperasjoner blir dirigert til denne deltadisken.<\/p>\nHvordan transaksjonsdatabaser h\u00e5ndterer tilstand<\/h3>\n
\n
Faresonen: Hva skjer under et VM-snapshot<\/h2>\n
Krasj-konsistens vs. applikasjonskonsistens<\/h3>\n
Disk D:<\/code> og WAL p\u00e5 Disk E:<\/code>), kan det hende at hypervisoren ikke tar snapshot av begge diskene p\u00e5 n\u00f8yaktig samme mikrosekund. Hvis WAL-diskens snapshot fanges bare en br\u00f8kdel av et sekund etter snapshotet av datadisken, kan ikke databasen avstemme sekvensnumrene ved gjenoppretting, noe som resulterer i fatal korrupsjon.<\/p>\n«VM Stun»-effekten p\u00e5 systemer med mange transaksjoner<\/h3>\n
\n* Nettverkstilkoblinger brytes, noe som for\u00e5rsaker tidsavbrudd (timeouts) i applikasjoner.
\n* H\u00f8y-tilgjengelighetsklynger (som SQL Server Always On, PostgreSQL Patroni eller MySQL Galera) g\u00e5r glipp av «heartbeat»-sjekker.
\n* Klyngen kan anta at den stunned noden er d\u00f8d, noe som utl\u00f8ser en un\u00f8dvendig og forstyrrende failover (split-brain-scenario).<\/p>\n\u00d8delagte sider (Torn Pages) og I\/O-feiljustering<\/h3>\n
Konsekvenser i den virkelige verden for spesifikke databasemotorer<\/h2>\n
\n
pg_wal<\/code>-katalogen. Hvis et snapshot fanger datakatalogen ($PGDATA<\/code>) og WAL-loggen ute av synkronisering, vil ikke PostgreSQL starte, og vil kaste en PANIC: could not locate a valid checkpoint record<\/code>-feil.<\/li>\nibdata1<\/code>-filen og ib_logfile<\/code> fanges ute av synkronisering, vil InnoDB-motoren krasje ved gjenoppretting.<\/li>\nBeste praksis for sikker sikkerhetskopiering av virtualiserte databaser<\/h2>\n
1. Utnytt applikasjonsbevisst «quiescing» (VSS og fsfreeze)<\/h3>\n
\nS\u00f8rg alltid for at sikkerhetskopieringsl\u00f8sningen din bruker Microsoft Volume Shadow Copy Service (VSS). N\u00e5r en VSS-bevisst sikkerhetskopi utl\u00f8ses, fryser SQL Server VSS Writer database-I\/O, t\u00f8mmer ventende transaksjoner til disken og sikrer at snapshotet er perfekt applikasjonskonsistent.<\/p>\n
\nLinux har ikke en innebygd ekvivalent til VSS. For \u00e5 oppn\u00e5 applikasjonskonsistens m\u00e5 du bruke «pre-freeze»- og «post-thaw»-skript i kombinasjon med hypervisorens gjesteverkt\u00f8y (f.eks. VMware Tools).<\/p>\npre-freeze-script<\/code> for PostgreSQL 15+ som trygt forbereder databasen for et snapshot:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# S\u00f8rg for at dette skriptet er kj\u00f8rbart (chmod +x)\n\n# 1. Be PostgreSQL om \u00e5 forberede seg p\u00e5 en sikkerhetskopi\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. T\u00f8m filsystemets buffere til disk\nsync\n\n# 3. Frys filsystemet (forutsatt at data ligger p\u00e5 \/var\/lib\/pgsql)\nfsfreeze -f \/var\/lib\/pgsql\n<\/code><\/pre>\npost-thaw-script<\/code> for \u00e5 gjenoppta operasjoner:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/post-thaw-script\n\n# 1. Opphev frysing av filsystemet\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Fortell PostgreSQL at sikkerhetskopieringen er fullf\u00f8rt\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. Bruk innebygde verkt\u00f8y for databasesikkerhetskopiering<\/h3>\n
pg_basebackup -h localhost -U replication_user -D \/mnt\/backups\/pg_backup -Ft -z -P\n<\/code><\/pre>\n
\nDisse verkt\u00f8yene tar «hot», ikke-blokkerende sikkerhetskopier ved \u00e5 kopiere datafilene og samtidig spore endringer 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 loggarkivering<\/h3>\n
Bedriftssikkerhetskopiering med CloudSave<\/h2>\n
\n1. Kommuniserer den direkte med databasemotoren via innebygde API-er (som VSS for Windows eller innebygd WAL-str\u00f8mming for Linux).
\n2. Orkestrerer den t\u00f8mming av minnebuffere til disk uten \u00e5 for\u00e5rsake forstyrrende VM-stuns.
\n3. Fanger den sikkert datafilene og administrerer automatisk trunkering av transaksjonslogger.
\n4. Sikkerhetskopierer den kontinuerlig transaksjonslogger, noe som muliggj\u00f8r granul\u00e6r Point-in-Time Recovery (PITR) med noen f\u00e5 klikk.<\/p>\nKonklusjon<\/h2>\n