Copia Shadow del volume (VSS): meccanismo e pratica — perché si può fare il backup dei file in uso

«Ho provato a copiare un file aperto da un’altra applicazione e mi è stato detto che il processo non può accedere al file perché è in uso da un altro processo.» «Ci hanno chiesto di fare il backup della cartella dati senza fermare il sistema centrale.» «Perché il software di backup copia con tranquillità un file di database in uso?» — Che si sviluppino applicazioni aziendali o si gestiscano file server, sono domande in cui prima o poi si inciampa.

Al centro della risposta c’è il Servizio Copia Shadow del volume (VSS: Volume Shadow Copy Service). È integrato in Windows da più di vent’anni, e Windows Server Backup, il Ripristino configurazione di sistema e praticamente tutti i prodotti di backup commerciali poggiano su questa stessa base.¹

Questo articolo è rivolto agli sviluppatori di applicazioni aziendali a cui viene chiesta una funzione per «copiare un file in uso», e al personale IT che gestisce i backup di file server e PC di lavoro. Sulla base di fonti primarie aggiornate ad agosto 2026, mette in ordine i protagonisti di VSS e il suo funzionamento, la pratica quotidiana con vssadmin, e fino a dove uno sviluppatore dovrebbe coinvolgersi con VSS. Nella serie «Le profondità dell’I/O di Windows» abbiamo guardato dentro il Cache Manager e NTFS; questo articolo ne è il seguito e tratta lo strato di «snapshot» che si interpone proprio sopra il volume.

1. Prima il sodo

• VSS è un insieme di interfacce COM e un servizio di coordinamento che rende possibile il backup di un volume mentre un’applicazione continua a scriverci. È integrato in Windows da Windows XP in poi.²
• Ci sono tre ruoli più un coordinatore. Il servizio VSS media tra il richiedente che chiede una copia shadow (il software di backup), il writer che garantisce la coerenza dei dati dal lato applicazione (SQL Server, per esempio) e il provider che crea davvero lo snapshot.¹
• Il provider di sistema standard di Windows usa il copy-on-write. Invece di duplicare l’intero volume, sposta nell’area delle differenze solo i blocchi che vengono sovrascritti dopo lo snapshot — e solo il loro contenuto precedente alla scrittura. L’area delle differenze deve stare su un volume NTFS.¹
• Un punto di coerenza si crea con la sequenza «freeze dei writer (fino a 60 secondi) → creazione dello snapshot (entro 10 secondi) → thaw». Se si supera uno dei due limiti, la creazione viene interrotta e il richiedente riprova.¹
• Se un writer collabora o no cambia la qualità della copia. Uno snapshot preso senza la collaborazione di un writer equivale a «il disco nell’istante in cui è saltata la corrente» (crash consistent); con la collaborazione, i log sono già stati ruotati e le cache svuotate, e resta uno stato coerente che l’applicazione stessa garantisce recuperabile (application consistent).³¹
• vssadmin è lo strumento per controllare lo stato operativo. Con list shadows / list writers / list shadowstorage si vede lo stato attuale, e con resize shadowstorage si regola il limite dell’area delle differenze. Quando l’area delle differenze si esaurisce, le copie shadow più vecchie vengono eliminate in silenzio.⁴⁵¹
• Inserire un richiedente VSS nella propria applicazione è un’impresa sostanziale. È un’API nativa basata su COM, senza wrapper ufficiale per .NET. Nella maggior parte dei casi bastano retry, l’aggiustamento della modalità di condivisione o una breve interruzione; se VSS serve davvero, la risposta pratica è uno script DiskShadow (solo Windows Server).⁶⁷
• Una copia shadow non è di per sé un backup. Poiché la differenza copy-on-write dipende dai blocchi intatti del volume originale, non offre alcuna protezione contro un guasto che fa sparire l’intero volume originale, come un disco rotto o un furto. Non ci si può fare affidamento neanche contro il ransomware, perché le copie shadow stesse possono essere eliminate (sezione 7.3) o l’area delle differenze può esaurirsi per riscritture di massa (sezione 7.4). Ha senso solo se combinata con backup tenuti su un supporto separato.¹

2. Impostazione del problema — perché un file in uso non si può copiare normalmente?

Il punto di partenza è la modalità di condivisione dei file di Windows. Quando si apre un file in Windows (CreateFile), si dichiara, come modalità di condivisione (dwShareMode), che cosa si consente agli altri processi mentre lo si tiene aperto. Finché un processo tiene il file aperto in un modo che non permette la condivisione in lettura, qualsiasi processo che in seguito tenti di aprirlo in lettura fallisce con una violazione di condivisione (ERROR_SHARING_VIOLATION, errore 32).⁸ In .NET è la familiare IOException («Il processo non può accedere al file perché è in uso da un altro processo»).

Il punto importante è che non è un bug, ma il meccanismo corretto per proteggere i dati. Se un file in fase di scrittura viene letto a metà, chi legge ottiene uno stato a metà, incompiuto. Come trattato in dettaglio in «Fondamenti di mutua esclusione per integrazione basata su file - Best practice per lock file e claim atomici», il disegno della mutua esclusione è il fondamento dell’integrazione tra applicazioni.

Ma questo meccanismo corretto è in conflitto di fondo con il backup.

• Il muro della violazione di condivisione: un file che un database o un’applicazione aziendale tiene aperto può non essere neanche apribile come origine della copia.
• Il muro della coerenza: anche se si riesce ad aprirlo (perché la condivisione in lettura è consentita), copiare richiede tempo. Poiché l’applicazione continua a scrivere mentre la copia è in corso, la prima e la seconda metà del file possono riflettere istanti diversi, oppure più file (il file dati e il suo log, per dire) possono finire fuori passo tra loro. E come abbiamo visto nella puntata sul «Cache Manager», una scrittura atterra prima nella cache in memoria, quindi guardare solo il file su disco non garantisce di vedere il contenuto più recente.
• Il muro operativo: «allora basta fermare l’applicazione e copiare» è una risposta ragionevole in linea di principio, ma non è accettabile per un sistema aziendale o un file server che gira 24 ore su 24.

In altre parole, ciò che si vuole davvero è «una copia di un singolo istante coerente, senza fermare l’applicazione». È troppo per le singole applicazioni da risolvere da sole, quindi VSS è stato costruito come meccanismo a livello di sistema operativo per fornirlo. VSS è offerto come un framework di interfacce COM che rende possibile il backup di un volume anche mentre un’applicazione continua a scriverci.²

3. I protagonisti di VSS — richiedente, writer, provider

La struttura di VSS si articola in tre ruoli e nel servizio che media tra di loro.¹

L’eleganza di questa divisione del lavoro è che prodotti che non si conoscono tra loro possono comunque collaborare. Il software di backup (il richiedente) non sa nulla della struttura interna di SQL Server, ma il writer di SQL Server dichiara, come metadati, quali file (componenti) vanno copiati, e mette in ordine i propri dati immediatamente intorno al punto di coerenza — così il richiedente può prendere un backup coerente limitandosi a seguire quella indicazione.¹⁹ Quasi tutti i prodotti di backup di terze parti che girano su Windows sono un richiedente VSS.¹

Nella pratica IT, il momento in cui serve davvero ragionare su questi tre ruoli è il troubleshooting. Se un fallimento del backup è un problema del richiedente (lato software), di un writer specifico (lato applicazione) o del provider / area delle differenze (lato infrastruttura) cambia del tutto dove si deve guardare (sezioni 5 e 7).

4. Come funzionano gli snapshot — copy-on-write e il «punto di coerenza»

4.1. Copy-on-write — conservare «quell’istante» senza duplicare il volume

Sentendo la parola «snapshot» si immagina di duplicare l’intero volume, ma il metodo che usa davvero il provider di sistema standard di Windows è il copy-on-write. Nel momento in cui si prende lo snapshot, non si copia quasi nulla. In seguito, quando un blocco del volume originale sta per essere sovrascritto, il contenuto precedente alla scrittura di quel blocco viene spostato nell’area delle differenze (diff area, l’archiviazione delle copie shadow) prima che la sovrascrittura termini, e solo allora la scrittura viene lasciata passare.¹ Lo spostamento deve avvenire solo la prima volta che ciascun blocco viene sovrascritto; sovrascrivere un blocco già spostato non fa più crescere l’area delle differenze.

Per leggere «il volume com’era in quell’istante», i blocchi che non sono cambiati si leggono dal volume originale, quelli che sono cambiati dall’area delle differenze, e i due si combinano. Poiché si copia solo la parte cambiata, la creazione è istantanea e lo spazio consumato è solo il differenziale. Il rovescio è che più un volume viene scritto, più in fretta si consuma l’area delle differenze (è l’anticipazione della sezione 7), e l’area delle differenze sta su un volume NTFS della stessa macchina dei dati di origine.¹ Ciò che sostiene questo meccanismo è il file componente del provider di sistema, swprv.dll, e il driver che intercetta l’I/O del volume, volsnap.sys.¹ Se vi interessa il «come» dell’intercettazione dello stack I/O, si veda anche «Driver di filtro e minifiltro».

Esistono anche altri metodi: la copia completa (full copy), che stacca uno specchio, e il redirect-on-write, che scrive le modifiche su un volume separato; i provider hardware usano il metodo che meglio si adatta allo storage array.¹

4.2. Il flusso di creazione di un punto di coerenza — 60 secondi di freeze, 10 secondi per creare

Se il copy-on-write riguarda come i dati vengono conservati, il vero valore di VSS sta in quale stato, di quale istante, viene conservato — cioè in come si crea il punto di coerenza. La creazione di una copia shadow procede così.¹

flowchart TB
    accTitle: Flusso di creazione di una copia shadow
    accDescr: Il flusso di creazione di una copia shadow. Si ferma solo per pochi secondi o decine di secondi; il backup vero e proprio viene eseguito sulla snapshot
    R["Il richiedente chiede la creazione<br/>enumera i writer e raccoglie i metadati"] --> M["Ogni writer dichiara i propri oggetti di backup<br/>(componenti) in XML"]
    M --> P["Ogni writer prepara i propri dati<br/>roll dei log, flush della cache, ecc.<br/>fino a uno stato coerente e recuperabile"]
    P --> F["Freeze dell'I/O di scrittura dei writer<br/>(la lettura resta possibile. Massimo 60 secondi)"]
    F --> FS["VSS esegue il flush dei buffer del file system<br/>e congela il file system"]
    FS --> C["Il provider crea la copia shadow<br/>(entro 10 secondi. L'I/O di scrittura resta congelato)"]
    C --> T["Rilascio del file system → thaw dei writer<br/>l'applicazione riprende a scrivere"]
    T --> B["Il richiedente esegue il backup dalla copia shadow<br/>prendendosi il tempo necessario"]

Figura 1: Il flusso di creazione di una copia shadow. Si ferma solo per pochi secondi o decine di secondi; il backup vero e proprio viene eseguito sulla snapshot

Ci sono tre punti da notare.

1. L’applicazione si ferma solo per l’istante necessario a creare il punto di coerenza. Il freeze è limitato a 60 secondi e la creazione (il commit) da parte del provider a 10 secondi; se si supera uno dei due, la creazione viene interrotta e il richiedente riprova.¹ Il backup vero e proprio, che può durare ore, gira sulla copia shadow di sola lettura già pronta, mentre l’applicazione continua a funzionare.
2. Durante il freeze le letture restano possibili. Si ferma solo l’I/O di scrittura.¹
3. Anche il file system viene congelato. Poiché VSS esegue il flush dei buffer del file system prima di congelarlo, le scritture che stavano in cache, e i metadati del file system, si riflettono nello snapshot in un ordine coerente.¹

4.3. Coerenza a crash e coerenza applicativa

Qui entra una distinzione importante che determina la qualità del backup.

Una copia shadow creata senza la collaborazione di un writer è in quello che la terminologia Microsoft chiama stato crash consistent. La definizione ufficiale è «uno stato del disco equivalente a quello che si troverebbe dopo un guasto catastrofico che spegne bruscamente il sistema», e il ripristino da lì è descritto come «equivalente a un riavvio dopo uno spegnimento improvviso».³ Come file system non è corrotto, ma dal punto di vista di un’applicazione è «l’istante in cui è stata staccata la corrente mentre stava scrivendo». Un database con un meccanismo di recovery basato sul log delle transazioni spesso può riprendersi da qui, ma prima deve girare l’elaborazione di recovery — è un presupposto, non un extra.

Con la collaborazione di un writer, ciascun writer ruota il proprio log delle transazioni e svuota le cache immediatamente prima del punto di coerenza, portando i dati in uno stato coerente che l’applicazione stessa garantisce di poter recuperare correttamente.¹ Questa è la coerenza applicativa (application consistency), ed è l’intera ragione per cui esiste il meccanismo dei writer. Vale la pena notare che ciò che un writer garantisce è «uno stato coerente e recuperabile dal punto di vista dell’applicazione» — non conferma e completa in silenzio le transazioni in corso al posto vostro. Il lavoro non confermato viene annullato (rollback) al ripristino, allo stesso modo del recovery ordinario di un database. Un writer consegna questa garanzia di qualità senza fermare l’applicazione, usando soltanto un freeze di qualche decina di secondi.

Il motivo per cui il software di backup ha impostazioni come «usa VSS» o «garantisci la coerenza applicativa» è precisamente questa distinzione. Per un insieme di file ordinari su un file server, la coerenza a crash è raramente un problema; ma su un server che ospita un database o un archivio di posta, il fatto che il writer corrispondente sia in salute è, di per sé, la qualità del backup.

5. Operare VSS nel quotidiano — vssadmin e «Versioni precedenti»

Lo strumento che il personale IT usa in pratica per controllare lo stato di VSS è vssadmin (si esegue da un Prompt dei comandi con privilegi elevati). Il riferimento comandi attuale elenca list shadows / list writers / delete shadows / resize shadowstorage come disponibili sia su client sia su server.⁴ Il riferimento orientato a Windows Server elenca in più, tra gli altri, create shadow / list shadowstorage / list providers.⁵ Si noti che vssadmin può gestire solo le copie shadow create dal provider di sistema.¹

Se list writers mostra un writer in stato di errore, ciò che va sospettato non è VSS stesso ma l’applicazione che fornisce quel writer. Controllate lo stato del servizio dell’applicazione proprietaria e i log eventi Applicazione/Sistema (sezione 7).

Il parametro /maxsize di resize shadowstorage consente di specificare il limite con un’unità come KB/MB/GB; se lo si omette, non c’è alcun limite. Vale la pena notare che la documentazione Microsoft afferma esplicitamente che modificare il limite di archiviazione — in particolare ridurlo — può di per sé far perdere copie shadow.¹⁰ Non riducete alla leggera il limite su un volume di cui volete conservare più generazioni.

5.1. Il rapporto con «Versioni precedenti»

Abilitare Copie shadow delle cartelle condivise (Shadow Copies of Shared Folders) su un file server conserva periodicamente copie puntuali dei file sulla condivisione, consentendo agli utenti di ripristinare un file cancellato o sovrascritto da Versioni precedenti senza bisogno dell’aiuto di un amministratore.¹ È l’applicazione più familiare di VSS, e una che taglia in modo affidabile il carico dell’help desk.

C’è però un limite. Le copie shadow del provider di sistema arrivano al massimo a 512 per volume, di cui la funzione Copie shadow delle cartelle condivise ne tiene al massimo 64 per impostazione predefinita (modificabile tramite il valore di Registro MaxShadowCopies).¹ E come si spiega nelle sezioni successive, se l’area delle differenze scarseggia, le generazioni più vecchie vengono rimosse automaticamente. È più sicuro capire che «quante generazioni si tengono davvero» lo decide non il numero configurato, ma quanto si scrive e la dimensione dell’area delle differenze.

6. Il punto di vista dello sviluppatore — la vostra applicazione ha bisogno di VSS?

Da qui in poi è il punto di vista dello sviluppatore. Quando vi chiedono di «aggiungere una funzione di backup che copi i file anche mentre sono in uso», come dovreste avvicinarvi a VSS?

6.1. Scrivere un richiedente proprio è un’impresa sostanziale

L’API VSS, sia per i richiedenti sia per i writer, è fornita come interfacce COM e C++ (il nucleo di un richiedente è IVssBackupComponents).⁶ Non esiste un wrapper ufficiale per .NET, e bisogna implementare correttamente tutto: dalla raccolta dei metadati dei writer, alla gestione del set di snapshot, fino alla pulizia dopo un errore — quindi non è qualcosa che si può innestare alla leggera come una funzione di un’applicazione aziendale. Nei nostri preventivi di sviluppo su commissione, «costruire un richiedente VSS» viene trattato come una voce di lavoro a sé.

Ci sono due risposte realistiche. La prima, lasciarlo a un prodotto di backup già compatibile con VSS. La seconda, su Windows Server, pilotare DiskShadow da uno script. DiskShadow è il richiedente VSS incluso nel sistema operativo; oltre alla modalità interattiva ha una modalità script (diskshadow /s script.txt), e un unico script può coprire la creazione della copia shadow, l’esposizione come lettera di unità (expose), l’esecuzione di un batch che fa la copia (exec) e la pulizia successiva.⁷¹ Si può costruire il flusso «crea una copia shadow → estrai i file con la propria logica di copia → eliminala» senza scrivere una riga di COM. Tuttavia DiskShadow è solo per Windows Server e non è incluso nelle edizioni client del sistema operativo.¹ Se nel requisito rientrano anche i PC client, questo fatto da solo fa pendere la bilancia verso l’adozione di un prodotto di backup esistente.

6.2. Serve davvero VSS? — una tabella di decisione

Nella nostra esperienza, la grande maggioranza delle richieste «copia un file in uso» si risolve senza VSS. Capite esattamente a che livello di requisito siete prima di scegliere lo strumento.

6.3. La vostra applicazione dovrebbe registrare un writer?

Vale la pena chiarire anche la domanda inversa: la vostra applicazione aziendale dovrebbe fornire un writer VSS? Se ne scrivete uno, i dati della vostra applicazione vengono copiati con coerenza applicativa qualunque prodotto di backup usi il cliente. Esiste anche un meccanismo più leggero di un writer normale, l’express writer (IVssExpressWriter), ma tutto ciò che fa è registrare metadati che dichiarano quali file includere o escludere.⁶ Non riceve notifiche di freeze/thaw, quindi non può mettere in pausa le scritture dell’applicazione per allinearsi alla creazione dello snapshot. Un express writer è appropriato solo se è accoppiato a un disegno di salvataggio che non si corrompe anche se viene catturato a metà scrittura (cioè se la coerenza a crash basta); se serve davvero il coordinamento al punto di coerenza, serve un’implementazione completa di writer.

Detto questo, la regola pratica per decidere è semplice.

• Se i dati vivono in un database come SQL Server, non ve ne serve uno. Il writer del database stesso garantisce la coerenza.¹
• Per un salvataggio semplice su file, risolvete prima con il disegno della routine di salvataggio. Se scrivete per intero su un file temporaneo e poi lo sostituite con una rinomina atomica, uno snapshot crash-consistent non lascerà mai indietro un file salvato corrotto.
• Registrare un writer vale la pena considerarlo solo per applicazioni che mantengono un data store proprietario distribuito su più file e hanno bisogno di coerenza reciproca tra di essi al punto di coerenza. Può ben valere, prima di tutto, riconsiderare se tenere così tanti dati in un formato fatto in casa sia la scelta giusta.

7. Trappole — quattro cose che in esercizio mordono davvero

7.1. VSS non è di per sé un backup

Questa è la trappola più importante. Una copia shadow del provider di sistema è un differenziale che sta sul disco della stessa macchina dei dati originali. Se si perde l’area delle differenze, non resta nulla da cui ricostruire, quindi non offre alcuna protezione contro un guasto del disco, una macchina rubata o smarrita, o la cifratura di un intero volume. La documentazione di Microsoft traccia una linea chiara tra copie shadow e backup: «il contenuto copiato da una copia shadow su un supporto come un nastro è il backup, e la copia shadow stessa può essere eliminata una volta fatta quella copia».¹ Una copia shadow è un punto di coerenza e un modo rapido per tornare indietro da un errore — non è un sostituto di un backup tenuto su un supporto separato in una sede separata.

7.2. Un errore di un writer è un problema dal lato applicazione

Quando il software di backup fallisce con un «errore VSS», partite identificando quale writer è fallito, con vssadmin list writers. Poiché un writer è, in sostanza, un componente che appartiene all’applicazione (o a un componente Windows)¹, il terreno principale per indagare la causa è lo stato del servizio di quell’applicazione e i suoi log eventi. Farsi trascinare dall’apparenza superficiale di «un errore del software di backup» e continuare a indagare solo il software di backup vi porta per la strada lunga. Lo schema generale per restringere il campo è lo stesso trattato in «Quando si eredita un sistema senza codice sorgente né documentazione — Una guida pratica per tenerlo in funzione»: restringere l’elenco dei sospetti a partire dai fatti che si possono osservare.

7.3. Il ransomware viene a prendere le vostre copie shadow

Questo è un fatto che vale la pena conoscere puramente come considerazione difensiva. È tentante sperare che, se si può tornare indietro con Versioni precedenti, si potrebbe recuperare anche dopo un attacco ransomware — ma è ampiamente noto che gran parte del ransomware elimina le copie shadow prima o dopo la cifratura, proprio per chiudere questa via di recupero. Eliminare le copie shadow si può fare con un comando del tutto legittimo purché si abbiano i diritti di amministratore, quindi non può fungere da ultima linea di difesa contro un attaccante che è già dentro. I pilastri di una contromisura, allora, sono: (1) trattare le copie shadow come «comode se ci sono» piuttosto che come «parte del piano di recovery»; (2) tenere un backup offline in una sede separata che un attaccante non possa raggiungere; e (3) non concedere mai i diritti di amministratore agli account usati per le operazioni quotidiane. Per la difesa sull’intero ciclo di vita del PC, compreso backup, cifratura e dismissione, si veda anche «Guida pratica a BitLocker — Cifratura delle unità a partire dalla gestione della chiave di ripristino» e «Cosa fare prima di dismettere un PC Windows — Checklist pratica di cancellazione dati, scollegamento account e backup».

7.4. Quando l’area delle differenze si esaurisce, le generazioni più vecchie spariscono in silenzio

Come visto nella sezione 4, il copy-on-write consuma l’area delle differenze solo quando ciascun blocco viene sovrascritto per la prima volta dopo che è stato preso lo snapshot. Sovrascrivere un blocco già spostato un numero qualsiasi di volte successive non aggiunge al consumo, quindi quanto si consuma non lo decide «quante scritture sono avvenute» ma «quanto è ampio l’intervallo di blocchi sovrascritti da quando è stato preso lo snapshot conservato». E una volta che l’area delle differenze raggiunge il limite, le copie shadow di quel volume vengono eliminate, partendo dalle più vecchie.¹ All’utente interattivo non viene data alcuna notifica, quindi spesso viene alla luce solo quando «dovrei poter tornare alla versione della settimana scorsa» risulta non essere più vero. Non è del tutto silenzioso, però: il log Sistema registra eventi dalla sorgente volsnap (ID evento 25 quando una copia viene eliminata perché non si è potuto liberare spazio per l’area delle differenze, 35/36 quando un’estensione fallisce o viene interrotta dopo aver raggiunto il limite, e così via). Oltre ai controlli periodici, includere questi eventi volsnap nel monitoraggio e negli alert permette di accorgersi in fretta di una perdita. Il motivo per cui operazioni di massa che «spazzolano l’intero volume» — aggiornamenti massivi di file, conversioni batch, deframmentazione — possono divorare l’area delle differenze in un colpo solo si riduce esattamente a questa proprietà: il consumo lo decide l’intervallo di blocchi sovrascritti. Controllate periodicamente se il numero di generazioni che state conservando soddisfa ancora il requisito aziendale («al massimo quanti giorni possono passare prima che qualcuno noti una cancellazione accidentale?») rispetto all’uso mostrato da vssadmin list shadowstorage, e allargate il limite se serve.⁵¹⁰

8. Sintesi

• Il motivo per cui un file in uso non si può copiare normalmente è una questione di violazioni di condivisione e di coerenza, ed è il meccanismo corretto per proteggere i dati. VSS è la risposta a livello di sistema operativo a «voglio una copia coerente senza fermare l’applicazione».
• VSS è un framework in cui il servizio VSS media tra tre ruoli — richiedente (chiede), writer (garantisce la coerenza) e provider (crea) — consentendo a software di backup e applicazioni aziendali che non si conoscono tra loro di collaborare.
• Il provider di sistema usa il copy-on-write, e un punto di coerenza si crea tramite «freeze dei writer (fino a 60 secondi) → creazione (entro 10 secondi) → thaw». Senza la collaborazione di un writer si ottiene coerenza a crash; con essa, coerenza applicativa.
• Controllate lo stato operativo con vssadmin (list shadows / list writers / list shadowstorage). Per un errore di un writer sospettate il lato applicazione, e controllate periodicamente l’uso dell’area delle differenze.
• Gli sviluppatori dovrebbero prima usare la tabella di decisione per verificare se retry, modalità di condivisione, una finestra di interruzione o un disegno di integrazione possono risolvere il problema, e rivolgersi a VSS solo quando serve davvero. Uno script DiskShadow (solo Server) o un prodotto esistente è la risposta realistica, prima di costruire un’implementazione propria.
• Una copia shadow non è un backup. Non è altro che un differenziale che dipende dai blocchi intatti del volume originale; è impotente contro la perdita di quel volume originale, come in un guasto del disco, e non ci si può fare affidamento neanche contro il ransomware, dato che le copie shadow possono essere eliminate o l’area delle differenze esaurita. Abbinatela a un backup offline tenuto in una sede separata.

Articoli correlati

• Fondamenti di mutua esclusione per integrazione basata su file - Best practice per lock file e claim atomici
• Le profondità dell’I/O di Windows (parte 4) — Cache Manager: quando WriteFile arriva sul disco?
• Le profondità dell’I/O di Windows (parte 5) — Interni di NTFS: capire il file system attraverso l’MFT
• Quando si eredita un sistema senza codice sorgente né documentazione — Una guida pratica per tenerlo in funzione
• Guida pratica a BitLocker — Cifratura delle unità a partire dalla gestione della chiave di ripristino
• Cosa fare prima di dismettere un PC Windows — Checklist pratica di cancellazione dati, scollegamento account e backup

Aree di consulenza correlate

KomuraSoft LLC si occupa della progettazione e dello sviluppo di applicazioni aziendali con funzioni come «copia di file in uso» e backup, dell’indagine sulle cause di violazioni di condivisione intorno all’integrazione tra file e di fallimenti del backup (errori dei writer VSS), e di mettere in ordine la struttura operativa dei backup dei file server e della gestione delle generazioni. Siamo lieti di partire dalla domanda se VSS sia davvero il requisito giusto.

• Sviluppo di applicazioni Windows
• Analisi dei bug e delle cause
• Consulenza tecnica e revisione del progetto
• Contattaci

Riferimenti

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Se ci sono le copie shadow, il backup non serve più?

No, serve ancora. Le copie shadow create dal provider di sistema standard di Windows sono differenze generate con il metodo copy-on-write: non esiste da qualche altra parte «una replica completa di quell'istante», dipendono dai blocchi del volume originale che non sono ancora stati sovrascritti. Anche se si colloca l'area delle differenze (diff area) su un altro volume, resta il fatto che se si perde il volume originale non si può ripristinare nulla, quindi davanti a un guasto del disco o al furto o smarrimento del PC, che fanno sparire l'intero volume originale, la copia shadow non offre alcuna protezione. Lo stesso vale per il ransomware: la scrittura della cifratura sposta sì nell'area delle differenze i blocchi precedenti alla sovrascrittura, ma negli attacchi reali le copie shadow si perdono perché vengono eliminate direttamente o perché l'area delle differenze si esaurisce per la mole di riscritture, quindi non ci si può fare affidamento. La documentazione di Microsoft distingue nettamente i due concetti: il backup è ciò che si copia dalla copia shadow su un supporto come un nastro, e una volta fatta quella copia la copia shadow stessa si può eliminare. La copia shadow è «un punto di coerenza da cui prendere un backup» e «un modo rapido per tornare indietro da un errore minore», non un sostituto del backup su un altro supporto e in un'altra sede.

Voglio che la mia applicazione aziendale copi file in uso: dovrei usare VSS?

Il primo passo realistico è cercare una via che non richieda VSS. Il richiedente VSS va scritto contro l'API nativa basata su COM (come IVssBackupComponents) e, non esistendo un wrapper ufficiale per .NET, incorporarlo in un'applicazione propria è un'impresa sostanziale. Se il requisito è solo «poter leggere, prima o poi, un file che un altro processo sta scrivendo», bastano i retry; se è «l'altra applicazione consente la condivisione in lettura», basta aprire con la stessa modalità di condivisione. Se l'applicazione si può fermare per un attimo, copiare in una pausa naturale del lavoro è l'opzione più semplice e più sicura. VSS entra in gioco solo quando il requisito è «duplicare in uno stato coerente l'intero insieme di dati di un'applicazione che non si può fermare» — e anche allora, prima di un'implementazione propria, conviene valutare un prodotto di backup già compatibile con VSS o uno script DiskShadow.

vssadmin list writers mostra un writer in stato di errore. Che cosa devo fare?

L'approccio di base è indagare il problema dal lato dell'applicazione che possiede quel writer. vssadmin list writers elenca i writer registrati insieme al loro stato, quindi si parte identificando quale è fallito. Poiché i writer sono forniti da applicazioni come SQL Server o da componenti di Windows (il Registro, per esempio), la causa sta quasi sempre nello stato del servizio dell'applicazione proprietaria, o negli errori registrati nei log Applicazione/Sistema, più che in VSS stesso. Riavviate il servizio pertinente e circoscrivete le condizioni di riproduzione; se non si risolve, consultate le informazioni di supporto di quell'applicazione. Questa è anche la prima mossa di triage corretta quando il software di backup fallisce con un errore VSS.

Una copia shadow è scomparsa senza che me ne accorgessi. Perché?

La causa più comune è l'esaurimento dello spazio nell'area delle differenze (l'archiviazione delle copie shadow). Con il copy-on-write, il contenuto di ogni blocco viene spostato nell'area delle differenze la prima volta che viene sovrascritto dopo lo snapshot, quindi più ampio è l'intervallo di blocchi riscritti, più area si consuma. Raggiunto il limite assegnato, Windows elimina le copie shadow più vecchie, in ordine, per liberare spazio. Accade in silenzio, senza notifica all'utente interattivo, e di solito lo si scopre quando si pensa di poter tornare alla versione della settimana scorsa da Versioni precedenti e non c'è più (il log Sistema registra comunque eventi come l'ID 25 dalla sorgente volsnap, quindi tenerli d'occhio permette di accorgersene). Controllate l'uso e il limite con vssadmin list shadowstorage e, se serve, alzate il limite con vssadmin resize shadowstorage. Tenete presente, però, che modificare il limite — in particolare ridurlo — può di per sé far perdere copie shadow.

Che rapporto c'è tra «Versioni precedenti» di Esplora file e VSS?

«Versioni precedenti» è uno dei punti di ingresso per recuperare versioni passate di un file da una copia shadow creata da VSS. Su un file server, abilitando «Copie shadow delle cartelle condivise» (Shadow Copies of Shared Folders) le copie shadow vengono prese secondo una pianificazione, e gli utenti possono fare clic con il pulsante destro su un file in una cartella condivisa e ripristinarlo da soli da Versioni precedenti. Il vantaggio è poter annullare una cancellazione o una sovrascrittura accidentale senza l'aiuto di un amministratore. Ma sotto sotto sono copie shadow: c'è un limite a quante generazioni si possono conservare, e se l'area delle differenze scarseggia spariscono prima le più vecchie. Come si spiega nel corpo dell'articolo, «abbiamo Versioni precedenti» non significa «non ci servono i backup».

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.