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.
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.
Affidarsi agli snapshot standard dell’hypervisor per i backup dei database è una delle cause più 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.
Lo scontro architettonico: Hypervisor vs. Motori di Database
Per capire perché 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.
Come gli hypervisor eseguono gli snapshot
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. .vmdk o .vhdx) 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.
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.
Come i database transazionali gestiscono lo stato
I database transazionali sono progettati attorno alle proprietà ACID (Atomicità, Consistenza, Isolamento, Durabilità). Per ottenere prestazioni elevate mantenendo la conformità ACID, i database non scrivono ogni transazione direttamente sui file di dati primari su disco immediatamente. Invece, utilizzano un’architettura complessa a più livelli:
- Buffer Pool / Shared Buffers: I dati vengono letti e modificati all’interno della memoria di sistema.
- Write-Ahead Log (WAL) / Redo Logs: Le modifiche vengono scritte sequenzialmente in un file di log altamente ottimizzato su disco per garantire la durabilità.
- Checkpoints / Lazy Writers: Periodicamente, il database scarica le pagine modificate (dirty) dalla memoria ai file di dati effettivi su disco.
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.
La zona di pericolo: cosa succede durante uno snapshot di una VM
Quando si esegue uno snapshot standard di una VM di un server database, si sta catturando uno stato di crash-consistent (coerente in caso di crash).
Coerenza in caso di crash vs. Coerenza applicativa
Uno snapshot crash-consistent è l’equivalente di staccare il cavo di alimentazione dal server fisico. Lo stato del disco viene catturato, ma tutto ciò che era in memoria va perduto e tutto ciò che era in transito verso il controller di archiviazione viene bruscamente interrotto.
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 è estremamente pericoloso. Se il database si estende su più dischi virtuali (es. file di dati su Drive D: e WAL su Drive E:), 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ò riconciliare i numeri di sequenza al momento del ripristino, causando una corruzione fatale.
L’effetto “VM Stun” sui sistemi ad alta transazione
Il processo di creazione dello snapshot, e ancora più importante, il processo di consolidamento dello snapshot, causa un fenomeno noto come “VM Stun” (stordimento della VM).
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ò bloccare la VM per diversi secondi.
Durante uno stordimento della VM:
* Le connessioni di rete si interrompono, causando timeout dell’applicazione.
* I cluster ad alta disponibilità (come SQL Server Always On, PostgreSQL Patroni o MySQL Galera) perdono i controlli di heartbeat.
* Il cluster potrebbe presumere che il nodo bloccato sia morto, innescando un failover non necessario e dirompente (scenario split-brain).
Pagine frammentate (Torn Pages) e disallineamento I/O
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ù piccoli (es. 4KB o 512 byte).
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). Quando si tenta di ripristinare lo snapshot, il database leggerà la pagina, fallirà la convalida del checksum e contrassegnerà il database come corrotto.
Conseguenze nel mondo reale per specifici motori di database
Diversi motori di database reagiscono agli snapshot crash-consistent in vari modi, ma nessuno di essi li gestisce correttamente in un ambiente di produzione.
- PostgreSQL: PostgreSQL si affida pesantemente alla directory
pg_wal. Se uno snapshot cattura la directory dei dati ($PGDATA) e il WAL non sincronizzati, PostgreSQL non riuscirà ad avviarsi, restituendo un errorePANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB utilizza un doublewrite buffer per prevenire le pagine frammentate, il che offre una certa protezione contro gli stati crash-consistent. Tuttavia, se il file
ibdata1e il fileib_logfilevengono catturati non sincronizzati, il motore InnoDB andrà in crash al momento del ripristino. - Microsoft SQL Server: SQL Server è altamente sensibile al blocco dell’I/O. Senza una corretta integrazione VSS (Volume Shadow Copy Service), il ripristino di un SQL Server da uno snapshot standard della VM comporterà spesso database in stato “suspect” e catene di log interrotte, distruggendo le capacità di Point-in-Time Recovery (PITR).
Best practice per eseguire il backup in sicurezza dei database virtualizzati
Per proteggere i database transazionali, è necessario passare da backup crash-consistent a backup application-consistent (coerenti a livello applicativo). Ciò 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.
1. Sfruttare il Quiescing Application-Aware (VSS e fsfreeze)
Per Windows (SQL Server):
Assicurarsi 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.
Per Linux (PostgreSQL / MySQL):
Linux non ha un equivalente nativo di VSS. Per ottenere la coerenza applicativa, è necessario utilizzare script pre-freeze e post-thaw in combinazione con gli strumenti guest dell’hypervisor (es. VMware Tools).
Ecco un esempio di uno script pre-freeze-script VMware per PostgreSQL 15+ che prepara in sicurezza il database per uno snapshot:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Assicurarsi che questo script sia eseguibile (chmod +x)
# 1. Dire a PostgreSQL di prepararsi per un backup
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Scaricare i buffer del file system su disco
sync
# 3. Congelare il file system (assumendo che i dati siano su /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
E il corrispondente post-thaw-script per riprendere le operazioni:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Scongelare il file system
fsfreeze -u /var/lib/pgsql
# 2. Dire a PostgreSQL che il backup è completo
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Utilizzare utility di backup native del database
Sebbene gli snapshot application-consistent siano migliori di quelli standard, comportano comunque il rischio di VM stun. L’approccio più sicuro per i backup dei database è utilizzare utility di backup in streaming native che operano indipendentemente dall’hypervisor.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Questi strumenti eseguono backup a caldo, non bloccanti, copiando i file di dati e tracciando simultaneamente le modifiche nel redo log.
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. Implementare il Point-in-Time Recovery (PITR) tramite l’archiviazione dei log
Uno snapshot giornaliero o un backup completo protegge solo fino al minuto in cui è 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.
Per ottenere una vera resilienza aziendale, è 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ò consente ai DBA di ripristinare il database a un minuto specifico o persino a un ID transazione specifico prima di un disastro.
Strategie di backup aziendali con CloudSave
Gestire script pre-freeze personalizzati, cron job per dump nativi e log shipping su decine di server database è un incubo operativo per i team DevOps. È qui che una piattaforma di livello aziendale come CloudSave diventa fondamentale.
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.
Quando CloudSave avvia un backup:
1. Comunica direttamente con il motore del database tramite API native (come VSS per Windows o streaming WAL nativo per Linux).
2. Orchestra lo scaricamento dei buffer di memoria su disco senza causare stordimenti della VM dirompenti.
3. Cattura in sicurezza i file di dati e gestisce automaticamente il troncamento dei log delle transazioni.
4. Esegue continuamente il backup dei log delle transazioni, consentendo un Point-in-Time Recovery (PITR) granulare con pochi clic.
Delegando la complessità della coerenza applicativa a CloudSave, i DBA e gli amministratori di sistema possono garantire l’integrità dei dati senza sacrificare le prestazioni o la disponibilità dei loro cluster di produzione.
Conclusione
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.
Per proteggere i dati mission-critical, è 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, è possibile garantire che i database rimangano altamente disponibili, completamente recuperabili e totalmente sicuri.
