Per gli ingegneri DevOps e gli amministratori di sistema, gli snapshot delle macchine virtuali (VM) sono uno strumento fondamentale. Offrono un modo rapido e conveniente per catturare lo stato di un server prima di una patch rischiosa, di una modifica importante alla configurazione o di un deployment di un’applicazione. Se qualcosa va storto, il ripristino richiede pochi secondi.<\/p>\n
Tuttavia, quando questa stessa metodologia viene applicata ai database transazionali (come PostgreSQL, MySQL, Oracle o Microsoft SQL Server), gli snapshot delle VM si trasformano da rete di sicurezza a bomba a orologeria.<\/p>\n
Affidarsi agli snapshot standard dell’hypervisor per i backup dei database \u00e8 una delle cause pi\u00f9 comuni di corruzione dei dati, pagine frammentate (torn pages) e interruzioni di produzione non recuperabili. In questo articolo, esploreremo lo scontro architettonico tra hypervisor e motori di database, le meccaniche della corruzione dei dati durante gli snapshot e le migliori pratiche ingegneristiche necessarie per eseguire il backup in sicurezza dei database virtualizzati.<\/p>\n
Per capire perch\u00e9 gli snapshot delle VM mettono in pericolo i database, dobbiamo prima esaminare come entrambi i sistemi gestiscono lo stato e le operazioni di I\/O.<\/p>\n
Quando un hypervisor (come VMware ESXi, Microsoft Hyper-V o KVM) esegue uno snapshot, non copia il disco. Invece, blocca il file del disco virtuale corrente (es. Quando lo snapshot viene eliminato, l’hypervisor deve eseguire il commit (consolidamento) dei dati dal disco delta al disco base. Gli snapshot standard non sono affatto consapevoli delle applicazioni in esecuzione all’interno del sistema operativo guest. Catturano lo stato del disco esattamente come esiste in quel microsecondo.<\/p>\n I database transazionali sono progettati attorno alle propriet\u00e0 ACID (Atomicit\u00e0, Consistenza, Isolamento, Durabilit\u00e0). Per ottenere prestazioni elevate mantenendo la conformit\u00e0 ACID, i database non scrivono ogni transazione direttamente sui file di dati primari su disco immediatamente. Invece, utilizzano un’architettura complessa a pi\u00f9 livelli:<\/p>\n A causa di questa architettura, i file di dati fisici su disco sono quasi sempre non sincronizzati con lo stato effettivo del database. Il vero stato del database esiste solo come combinazione dei file di dati su disco, dei log WAL\/Redo e dei dati attualmente residenti in memoria.<\/p>\n Quando si esegue uno snapshot standard di una VM di un server database, si sta catturando uno stato di crash-consistent<\/strong> (coerente in caso di crash).<\/p>\n Uno snapshot crash-consistent \u00e8 l’equivalente di staccare il cavo di alimentazione dal server fisico. Lo stato del disco viene catturato, ma tutto ci\u00f2 che era in memoria va perduto e tutto ci\u00f2 che era in transito verso il controller di archiviazione viene bruscamente interrotto.<\/p>\n Sebbene i database moderni siano progettati per recuperare da un’improvvisa interruzione di corrente riproducendo il Write-Ahead Log, fare affidamento sul ripristino da crash come strategia di backup principale \u00e8 estremamente pericoloso. Se il database si estende su pi\u00f9 dischi virtuali (es. file di dati su Il processo di creazione dello snapshot, e ancora pi\u00f9 importante, il processo di consolidamento dello snapshot, causa un fenomeno noto come “VM Stun” (stordimento della VM).<\/p>\n Per passare in sicurezza l’I\/O dal disco base al disco delta, l’hypervisor deve mettere brevemente in pausa (stun) la macchina virtuale. Per un server web leggermente carico, questo stordimento potrebbe durare 10-50 millisecondi e passare inosservato. Tuttavia, per un database ad alto throughput con un I\/O massiccio, il consolidamento di un grande disco delta pu\u00f2 bloccare la VM per diversi secondi.<\/p>\n Durante uno stordimento della VM: I motori di database scrivono tipicamente i dati in dimensioni di pagina specifiche (es. 8KB per PostgreSQL e SQL Server, 16KB per InnoDB). Tuttavia, il sistema operativo sottostante e gli array di archiviazione elaborano l’I\/O in blocchi pi\u00f9 piccoli (es. 4KB o 512 byte).<\/p>\n Se un hypervisor esegue uno snapshot esattamente mentre il database sta scrivendo una pagina da 8KB, lo snapshot potrebbe catturare i primi 4KB dei nuovi dati e gli ultimi 4KB dei vecchi dati. Questo crea una pagina frammentata (torn page)<\/strong>. Quando si tenta di ripristinare lo snapshot, il database legger\u00e0 la pagina, fallir\u00e0 la convalida del checksum e contrassegner\u00e0 il database come corrotto.<\/p>\n Diversi motori di database reagiscono agli snapshot crash-consistent in vari modi, ma nessuno di essi li gestisce correttamente in un ambiente di produzione.<\/p>\n Per proteggere i database transazionali, \u00e8 necessario passare da backup crash-consistent a backup application-consistent<\/strong> (coerenti a livello applicativo). Ci\u00f2 richiede che il meccanismo di backup comunichi con il motore del database, costringendolo a scaricare la memoria su disco e a mettere in pausa momentaneamente le operazioni di I\/O mentre viene eseguito lo snapshot.<\/p>\n Per Windows (SQL Server):<\/strong> Per Linux (PostgreSQL \/ MySQL):<\/strong> Ecco un esempio di uno script E il corrispondente Sebbene gli snapshot application-consistent siano migliori di quelli standard, comportano comunque il rischio di VM stun. L’approccio pi\u00f9 sicuro per i backup dei database \u00e8 utilizzare utility di backup in streaming native che operano indipendentemente dall’hypervisor.<\/p>\n PostgreSQL (pg_basebackup):<\/strong><\/p>\n MySQL\/MariaDB (Percona XtraBackup \/ Mariabackup):<\/strong> SQL Server (T-SQL):<\/strong><\/p>\n Uno snapshot giornaliero o un backup completo protegge solo fino al minuto in cui \u00e8 stato eseguito. Se il database va in crash alle 16:00 e l’ultimo snapshot era alle 02:00, si perdono 14 ore di dati transazionali.<\/p>\n Per ottenere una vera resilienza aziendale, \u00e8 necessario combinare backup completi application-consistent con l’archiviazione continua dei log (eseguendo il backup di WAL, Redo Log o Transaction Log ogni pochi minuti). Ci\u00f2 consente ai DBA di ripristinare il database a un minuto specifico o persino a un ID transazione specifico prima di un disastro.<\/p>\n Gestire script pre-freeze personalizzati, cron job per dump nativi e log shipping su decine di server database \u00e8 un incubo operativo per i team DevOps. \u00c8 qui che una piattaforma di livello aziendale come CloudSave diventa fondamentale.<\/p>\n CloudSave colma il divario tra virtualizzazione e architettura del database. Invece di affidarsi a snapshot ciechi dell’hypervisor, CloudSave utilizza agenti application-aware che si integrano nativamente con SQL Server, PostgreSQL, MySQL e Oracle.<\/p>\n Quando CloudSave avvia un backup: Delegando la complessit\u00e0 della coerenza applicativa a CloudSave, i DBA e gli amministratori di sistema possono garantire l’integrit\u00e0 dei dati senza sacrificare le prestazioni o la disponibilit\u00e0 dei loro cluster di produzione.<\/p>\n Gli snapshot delle macchine virtuali sono uno strumento incredibile per la gestione dell’infrastruttura, ma sono fondamentalmente incompatibili con i requisiti ACID dei database transazionali. Affidarsi a snapshot dell’hypervisor crash-consistent espone l’organizzazione a pagine frammentate, catene di replica interrotte e perdita catastrofica di dati.<\/p>\n Per proteggere i dati mission-critical, \u00e8 necessario implementare il quiescing application-aware, utilizzare metodologie di backup del database native e mantenere archivi continui dei log delle transazioni. Adottando soluzioni di backup aziendali appositamente progettate, \u00e8 possibile garantire che i database rimangano altamente disponibili, completamente recuperabili e totalmente sicuri.<\/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":[503],"tags":[3384,3698,3699,3700,3701,3702,3703],"class_list":["post-5489","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> o .vhdx<\/code>) in uno stato di sola lettura e crea un nuovo disco delta (disco di differenziazione). Tutte le scritture successive vengono indirizzate a questo disco delta.<\/p>\nCome i database transazionali gestiscono lo stato<\/h3>\n
\n
La zona di pericolo: cosa succede durante uno snapshot di una VM<\/h2>\n
Coerenza in caso di crash vs. Coerenza applicativa<\/h3>\n
Drive D:<\/code> e WAL su Drive E:<\/code>), l’hypervisor potrebbe non eseguire lo snapshot di entrambi i dischi nello stesso identico microsecondo. Se lo snapshot del disco WAL viene catturato anche solo una frazione di secondo dopo lo snapshot del disco dati, il database non pu\u00f2 riconciliare i numeri di sequenza al momento del ripristino, causando una corruzione fatale.<\/p>\nL’effetto “VM Stun” sui sistemi ad alta transazione<\/h3>\n
\n* Le connessioni di rete si interrompono, causando timeout dell’applicazione.
\n* I cluster ad alta disponibilit\u00e0 (come SQL Server Always On, PostgreSQL Patroni o MySQL Galera) perdono i controlli di heartbeat.
\n* Il cluster potrebbe presumere che il nodo bloccato sia morto, innescando un failover non necessario e dirompente (scenario split-brain).<\/p>\nPagine frammentate (Torn Pages) e disallineamento I\/O<\/h3>\n
Conseguenze nel mondo reale per specifici motori di database<\/h2>\n
\n
pg_wal<\/code>. Se uno snapshot cattura la directory dei dati ($PGDATA<\/code>) e il WAL non sincronizzati, PostgreSQL non riuscir\u00e0 ad avviarsi, restituendo un errore PANIC: could not locate a valid checkpoint record<\/code>.<\/li>\nibdata1<\/code> e il file ib_logfile<\/code> vengono catturati non sincronizzati, il motore InnoDB andr\u00e0 in crash al momento del ripristino.<\/li>\nBest practice per eseguire il backup in sicurezza dei database virtualizzati<\/h2>\n
1. Sfruttare il Quiescing Application-Aware (VSS e fsfreeze)<\/h3>\n
\nAssicurarsi sempre che la soluzione di backup utilizzi il Microsoft Volume Shadow Copy Service (VSS). Quando viene attivato un backup compatibile con VSS, il VSS Writer di SQL Server blocca l’I\/O del database, scarica le transazioni in sospeso su disco e garantisce che lo snapshot sia perfettamente coerente a livello applicativo.<\/p>\n
\nLinux non ha un equivalente nativo di VSS. Per ottenere la coerenza applicativa, \u00e8 necessario utilizzare script pre-freeze e post-thaw in combinazione con gli strumenti guest dell’hypervisor (es. VMware Tools).<\/p>\npre-freeze-script<\/code> VMware per PostgreSQL 15+ che prepara in sicurezza il database per uno snapshot:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/pre-freeze-script\n# Assicurarsi che questo script sia eseguibile (chmod +x)\n\n# 1. Dire a PostgreSQL di prepararsi per un backup\nsu - postgres -c \"psql -c \"SELECT pg_backup_start('vm_snapshot', true);\"\"\n\n# 2. Scaricare i buffer del file system su disco\nsync\n\n# 3. Congelare il file system (assumendo che i dati siano su \/var\/lib\/pgsql)\nfsfreeze -f \/var\/lib\/pgsql\n<\/code><\/pre>\npost-thaw-script<\/code> per riprendere le operazioni:<\/p>\n#!\/bin\/bash\n# \/usr\/sbin\/post-thaw-script\n\n# 1. Scongelare il file system\nfsfreeze -u \/var\/lib\/pgsql\n\n# 2. Dire a PostgreSQL che il backup \u00e8 completo\nsu - postgres -c \"psql -c \"SELECT pg_backup_stop();\"\"\n<\/code><\/pre>\n2. Utilizzare utility di backup native del database<\/h3>\n
pg_basebackup -h localhost -U replication_user -D \/mnt\/backups\/pg_backup -Ft -z -P\n<\/code><\/pre>\n
\nQuesti strumenti eseguono backup a caldo, non bloccanti, copiando i file di dati e tracciando simultaneamente le modifiche nel redo log.<\/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. Implementare il Point-in-Time Recovery (PITR) tramite l’archiviazione dei log<\/h3>\n
Strategie di backup aziendali con CloudSave<\/h2>\n
\n1. Comunica direttamente con il motore del database tramite API native (come VSS per Windows o streaming WAL nativo per Linux).
\n2. Orchestra lo scaricamento dei buffer di memoria su disco senza causare stordimenti della VM dirompenti.
\n3. Cattura in sicurezza i file di dati e gestisce automaticamente il troncamento dei log delle transazioni.
\n4. Esegue continuamente il backup dei log delle transazioni, consentendo un Point-in-Time Recovery (PITR) granulare con pochi clic.<\/p>\nConclusione<\/h2>\n