Snapshot di VM e database relazionali: un backup che sembra funzionare… finché non serve davvero

Il problema di fondo: due livelli di consistenza che non parlano tra loro

Quando un tool di backup infrastrutturale scatta una snapshot di una virtual machine, cattura lo stato dei dischi in un preciso istante. Ma un database relazionale non è un insieme di file statici: è un sistema in movimento continuo, con dati in memoria non ancora scritti su disco, transazioni aperte, file di log separati dai datafile, strutture interne che devono essere allineate tra loro per avere senso.

La distinzione tecnica fondamentale è tra due tipi di snapshot:

Crash-consistent: la VM viene fotografata così com'è, come se la corrente fosse stata tolta improvvisamente. I dati in memoria (buffer pool) non ancora scritti su disco vanno persi. Al ripristino, il database si comporta come se avesse subito un crash e tenta una recovery automatica — con esito non garantito.

Application-consistent: prima dello scatto, il backup tool si coordina con il database engine, che viene istruito a fare il flush dei buffer in memoria, a sospendere le scritture e a portarsi in uno stato coerente. La snapshot cattura un database in uno stato noto e recuperabile.

La differenza non è accademica. Su un sistema ad alto carico transazionale, in un singolo istante possono risultare ancora “aperte” decine o centinaia di transazioni. Una snapshot crash-consistent le taglia a metà.

SQL Server su Windows: il meccanismo VSS esiste, ma richiede configurazione attiva e verificata

SQL Server integra nativamente il meccanismo VSS (Volume Shadow Copy Service) di Windows attraverso il servizio SqlServerWriter. Questo servizio coordina SQL Server con il framework VSS: prima dello scatto della snapshot, il writer istruisce il motore a portare il database in uno stato transazionalmente coerente, flushando i buffer e sospendendo le scritture.

I tool di backup infrastrutturale su Windows possono invocare questo writer — ma solo se la funzionalità di application-aware processing è esplicitamente abilitata nel job e se i prerequisiti tecnici sono soddisfatti:

• Il servizio SQL Writer deve girare sotto l'account Local System e deve avere il ruolo sysadmin su SQL Server, perché nel corso della sua attività congela brevemente tutti gli I/O dell'istanza.
• Se questi prerequisiti non sono rispettati, il writer non si registra correttamente nel subsistema VSS e il backup viene declassato silenziosamente al livello crash-consistent.

Il punto critico: nella maggior parte dei tool di backup infrastrutturale, quando il SqlServerWriter non è presente o non funziona correttamente, il backup viene eseguito in stato crash-consistent e il processing dei transaction log viene saltato completamente. Il job risulta comunque completato. Un amministratore che monitora solo lo stato del job non sa che il backup non include i log delle transazioni e non garantisce la consistenza del database.

È importante notare anche che il SQL Writer non è disponibile su Linux: la piattaforma non fornisce il framework VSS, quindi su VM Linux con SQL Server non esiste alcun meccanismo equivalente di application-aware processing via VSS. Qualsiasi snapshot di una VM Linux che ospita SQL Server è, per definizione architetturale, crash-consistent.

Oracle: il rischio è strutturale, non solo di configurazione

Oracle presenta una complessità aggiuntiva rispetto a SQL Server, e il rischio è più radicato nella natura stessa del motore.

Su Windows, Oracle fornisce un VSS Writer analogo. L'Oracle VSS Writer è un servizio Windows che coordina un'istanza Oracle Database con gli altri componenti VSS, che gira sotto un account con privilegi SYSDBA. Supporta sia shadow copy a livello di componente (file di database) che a livello di volume.

Tuttavia, ed è un dettaglio che la documentazione Oracle esplicita chiaramente, per database in NOARCHIVELOG mode aperti in lettura/scrittura, il writer restituisce un errore indicando che la snapshot non è possibile. Per database in ARCHIVELOG mode, il writer porta i datafile in hot backup mode e crea un nuovo snapshot control file; i redo log online non vengono inclusi nella snapshot.

Nella realtà on-premise dei nostri clienti che incontriamo, molti database Oracle di taglia media girano ancora in NOARCHIVELOG mode, spesso per scelta storica o per semplificare la gestione dello spazio. In questi casi, anche un tool configurato correttamente non può produrre una snapshot application-consistent di un database aperto.

Su Linux, come per SQL Server, il VSS non esiste. Un Oracle su VM Linux soggetto a snapshot infrastrutturale è crash-consistent per definizione, indipendentemente da come è configurato il tool di backup.

Il rischio più insidioso su Oracle è quello dei fractured blocks. Quando un'utilità di sistema operativo copia un datafile mentre il database writer (DBWR) sta aggiornando lo stesso file, è possibile che copi un blocco in stato di aggiornamento parziale — la prima metà aggiornata, la seconda con dati più vecchi. Questo tipo di corruzione logica è nota come "fractured block": un blocco non consistente con un SCN. Se questo backup viene ripristinato e il blocco richiede recovery, la recovery fallisce perché il blocco non è utilizzabile. Oracle

RMAN, lo strumento nativo Oracle, rileva e previene questo scenario. Le snapshot non hanno alcuna consapevolezza della struttura dei blocchi Oracle — operano a livello di storage block — e sono intrinsecamente diverse dai backup, costituite da puntatori invece che da blocchi. RMAN, al contrario, valida ogni blocco Oracle durante il backup e il ripristino tramite checksum fisico e verifica logica interna al blocco stesso. Oracle

La conseguenza operativa è rilevante: tutta la recovery da snapshot è manuale e richiede coordinamento tra DBA e Storage Administrator. Funzionalità come Oracle Recovery Advisor non possono essere utilizzate perché tutti i backup effettuati tramite snapshot avvengono fuori dal controllo di Oracle. Wordpress

Il problema del semaforo verde

Quello che la dashboard non mostra è il livello di consistenza che viene catturato. Il backup tool riporta se il job è completato. Il job ha girato, la snapshot è stata scattata, i dati sono stati scritti sul target. Verde. Quello che la dashboard non può mostrare è se il database era in stato consistente quando la snapshot è partita.

Questo è esattamente il pattern più pericoloso: sistemi monitorati, job regolari, nessun alert e una scoperta che avviene solo nel momento del ripristino, cioè quando è già tardi.

Un indicatore pratico spesso ignorato: se nei log del tool di backup non compare mai traccia esplicita dell'invocazione del VSS writer applicativo o di operazioni sui transaction log, è probabile che il backup sia crash-consistent indipendentemente da cosa dice il report finale.

Cosa usare invece

La snapshot infrastrutturale può avere un ruolo legittimo in una strategia di backup ma come layer aggiuntivo, non come sostituto del backup nativo del database. Il backup applicativo garantisce la consistenza transazionale e l'integrità dei blocchi; la snapshot infrastrutturale garantisce la velocità e la recovery dell'intera VM. Usati insieme, si completano. Usati in sostituzione l'uno dell'altro, creano rischi invisibili.

Fonti

• Microsoft Learn — SQL Server Backup Applications: Volume Shadow Copy Service and SQL Writer
• Oracle Docs 21c — Basic Concepts of Database Backup and Recovery with VSS
• Oracle Docs — RMAN Backup Concepts (fractured blocks) 
• Oracle.com — Snapshots Are NOT Backups 
• Rack2Cloud — App-Consistent Database Backup: Why Crash-Consistent Is Not Enough

di Cristiano Gasparotto, pubblicato il 31 marzo 2026