Tutto ciò che serve sapere sui backup di Exchange* - Parte 1

Articolo originale pubblicato martedì 05 giugno 2012

*ma non si è mai osato chiedere

Se ritienete che le operazioni interne dei backup di dati di Exchange tramite Copia Shadow del volume (VSS) siano alquanto fuorvianti, sappiate che non siete i soli a pensarla così. Gli amministratori si chiedono cosa siano tutte le operazioni di “blocco” e “sblocco” incluse nei registri eventi, cosa sia effettivamente Exchange VSS Writer e cosa esegua nei database, nonché come faccia a creare uno snapshot di un database di 135 GB in meno di 60 secondi.

Se vi siete mai posti queste domande, ma le risposte vi hanno solo confuso ulteriormente, ecco una guida che chiarirà alcuni dei vostri dubbi. Comprendere il funzionamento di un backup VSS di Exchange è essenziale per capire i concetti base di VSS. Su TechNet e MSDN è disponibile della documentazione eccellente su questo argomento, così come nel blog del team Windows Server Core, “Ask the Core Team”. In questo post il mio esimio collega Randy Monteleone riepiloga i concetti base di VSS in modo molto efficace e fornisce anche collegamenti (riportati qui) ad alcuni articoli introduttivi di TechNet su VSS:

How To: VSS Tracing – Randy Monteleone
https://blogs.technet.com/b/askcore/archive/2012/04/29/how-to-vss-tracing.aspx

How Volume Shadow Copy Service Works
https://technet.microsoft.com/en-us/library/cc785914(WS.10).aspx

Volume Shadow Copy Service
https://technet.microsoft.com/en-us/library/ee923636.aspx

Se avete già familiarità almeno con i concetti base di VSS, passate alla parte 2 di questa serie, in cui esamineremo gli eventi che si verificano in un backup VSS di Exchange e il modo in cui Exchange li riporta nel registro eventi dell'applicazione.

Se avete bisogno di un'introduzione rapida o di un riepilogo dei concetti base di VSS e Exchange Writer, li ho riassunti in alcuni punti visivi di seguito per integrare i riferimenti che ho fornito sopra.

Snapshot

Tenete presente che le soluzioni VSS per Exchange e per tutte le applicazioni variano significativamente per le diverse configurazioni hardware e software. Esistono cloni e snapshot COW, soluzioni hardware e software, nonché un'ampia gamma di tecnologie basate sul sottosistema VSS principale. Allo scopo di comprendere i backup di Exchange illustreremo solo un tipo specifico di soluzione tra le innumerevoli possibili. Di seguito sono descritti gli snapshot COW (copy-on-write, copia in scrittura).

In un backup VSS di Exchange basato su uno snapshot COW si verifica la creazione degli snapshot dei dischi in cui sono ospitati i dati di Exchange. Indipendentemente da ciò di cui si esegue il backup, anche se si tratta di un singolo file di database e di pochi registri, VSS crea uno snapshot dell'intero disco in cui siano archiviati dati. Se i dati si trovano in più dischi, come nel caso in cui un database di Exchange si trova su un disco e i registri su un altro, VSS creerà gli snapshot di tutti i dischi interessati.

Per “snapshot” del volume si intende un'area di spazio all'interno di un'“archiviazione shadow”, che a sua volta è una piccola area del disco situata nella cartella System Volume Information.

Quando lo snapshot del disco è stato creato, eventuali modifiche apportate successivamente a qualsiasi blocco dati non potranno essere scritte finché una copia dei dati di tale blocco prima della modifica (nelle condizioni esistenti al momento della creazione dello snapshot) non viene scritta nell'area di differenziazione nell'archiviazione shadow. In questo modo i dati presenti nel disco al momento della creazione dello snapshot vengono conservati blocco per blocco nell'area di archiviazione shadow. I dati dello snapshot saranno quindi disponibili dal disco originale, se i blocchi di dati richiesti non sono stati modificati, che dall'area di differenziazione se sono stati modificati. Gli aspetti fondamentali di questo concetto sono illustrati di seguito:

Per il disco E è stato creato uno snapshot alle ore 13.00:

Un minuto dopo uno dei blocchi viene modificato, ma non prima che i dati venissero conservati nelle condizioni esistenti alle 13.00 nell'area di differenziazione:

Mentre il disco effettivo viene modificato, i dati nelle condizioni in cui erano alle 13.oo vengono scritti nell'archiviazione shadow, conservando un record del disco nelle condizioni esistenti in quel momento:

Il passaggio successivo:

Nella figura precedente un server di backup richiede i dati dallo snapshot dei blocchi 2 e 53. Il blocco 53 delle 13.00 è conservato nello snapshot, quindi viene copiato direttamente dall'archiviazione shadow. Il blocco 2 non è stato modificato dopo le 13.00 quindi viene copiato tramite il driver VSS VOLSNAP.SYS, che opera in modo analogo a un driver di filtro al di sotto del driver del file system NTFS.SYS. Operando nello stack IRP (la parte della memoria kernel che gestisce le operazioni di I/O del disco) al di sotto del file system, può leggere blocchi di dati senza che NTFS impedisca l'operazione se il file è in uso. VOLSNAP.SYS è anche responsabile della copia dei blocchi nell'archiviazione shadow se viene richiesta un'operazione di scrittura nei relativi dati, per questo il processo viene definito “copia in scrittura”. Ecco altre informazioni su VOLSNAP.SYS fornite da Tim McMichael:

Exchange / VSS / e le dimensioni dei blocchi differenziali…
https://blogs.technet.com/b/timmcmic/archive/2011/07/12/exchange-vss-and-differential-block-size.aspx

Ora che abbiamo definito i concetti base di uno snapshot COW, esaminiamo come funziona con Exchange, insieme ad altri concetti importanti:

Microsoft Exchange Writer

Abbiamo assodato che per qualsiasi disco in cui sono archiviati dati di Exchange viene creato uno snapshot da VSS. Ma in che modo un'applicazione di backup identifica tali dischi? Spesso un'amministrazione seleziona i database per il backup senza specificare in quali dischi i file di dati sono archiviati. Quindi a volte è necessario fornire indicazioni sulla posizione dei file di dati e, pertanto, di quali dischi VSS deve creare gli snapshot. Queste informazioni sono anche necessarie affinché un'applicazione di backup, anche nota come richiedente VSS, stabilisca quali file di dati specifici copiare dagli snapshot per conservarli su supporti di backup, allo scopo di copiare dal disco solo i dati necessari.

Il meccanismo che entra in gioco qui è Microsoft Exchange VSS Writer. Analogamente ai VSS writer di qualsiasi applicazione (ne esistono molti, basta eseguire VSSADMIN LIST WRITERS per vederli), il suo primo compito è di indicare all'applicazione di backup i dati da includere nel backup, in particolar ei file EDB, i registri e i file del punto di arresto per ogni database richiesto. Le informazioni su questi specifici file di dati di Exchange sono note come metadati di scrittura.

(Per la versione intera fate clic sull'anteprima)

Nella figura precedente sono mostrati i passaggi iniziali di un backup di Exchange. Exchange Writer indica al server di backup (il richiedente) che in una cartella del volume E: è presente un database e che i registri delle transazioni per tale database si trovano in una cartella D:. In base a queste informazioni, l'applicazione di backup richiede gli snapshot dei volumi D: e E: quando il processo avanza.

Exchange VSS Writer svolge un altro ruolo critico oltre a fornire metadati ai richiedenti VSS, ha anche il compito di arrestare le scritture nei database e nei registri sul disco, oppure di bloccarle, per il tempo necessario a creare gli snapshot previsti. La creazione di snapshot COW in genere richiede poco tempo, in quanto inizialmente comporta solo la designazione di un'area in un'archiviazione shadow in cui conservare i blocchi quando vengono modificati sul disco effettivo. Nonostante questa operazione sia relativamente rapida, può richiedere fino a un minuto, che è un periodo di tempo considerevole in cui i blocchi di dati possono cambiare sul disco tra l'inizio e la fine di questo processo di creazione dello snapshot. Se i blocchi di dati cambiano ma la versione originale non è stata conservata dal momento esatto in cui ha inizio la creazione dello snapshot tali blocchi possono diventare incoerenti con altri dati dello snapshot, in particolare nei registri, nei database e nei file del punto di arresto. Di conseguenza, Exchange Writer impedisce al servizio Archivio informazioni o al servizio di replica di Microsoft Exchange di scrivere il contenuto della RAM nei file di database bloccati. Nel caso del servizio Archivio informazioni, il file di registro delle transazioni corrente (Exx.log) viene chiuso prima che Exchange Writer consenta a VSS di creare lo snapshot. In questo modo niente cambia nei dati del file tra l'inizio e la fine del processo di creazione dello snapshot, dopo di che i database vengono sbloccati. Quando i database sono sbloccati alle operazioni I/O di scrittura presenti nella RAM viene consentito di nuovo l'accesso al disco.

Ecco altri informazioni sull'interazione di VSS writer di un'applicazione con VSS in relazione ai blocchi, agli sblocchi e al tempo necessario per completare la creazione dello snapshot:

Metodo CVssWriter::OnFreeze
https://msdn.microsoft.com/en-us/library/windows/desktop/aa381563(v=vs.85).aspx

L'ultima responsabilità fondamentale del writer di Exchange consiste nel comunicare al servizio Archivio informazioni (o al servizio di replica di Microsoft Exchange nel caso di un backup di copia passiva) che il backup è stato completato e, se applicabile, esegue attività successive al backup come troncare il registro, contrassegnare il database in modo da indicare che non è più in corso un backup e così via.

Nella seconda e terza parte di questa serie esamineremo in dettaglio come gli elementi descritti in precedenza interagiscono in un backup di Exchange, gli eventi del registro dell'applicazione che vengono generati e confronteremo il processo per un database montato rispetto a quello per una copia di database passiva.

Desidero ringraziare Michael Blanton, Tim McMichael, Randy Monteleone, Dave Vespa e Tom Kern per la collaborazione ai contenuti di questo post.

Jesse Tedoff

Questo è un post di blog localizzato. L'articolo originale è disponibile in Everything You Need to Know About Exchange Backups* - Part 1