Backup, DR e business continuity

Far andare BackupAssist 10 volte più veloce

04 Giugno 2014
Chi si occupa di backup avrà sentito nominare il termine Microsoft Volume Shadow Copy Service, in breve VSS.
E magari sa anche che VSS gira in background nel corso dell'esecuzione di un backup.
Molti tecnici si fermano qui, ma se si vogliono personalizzare i propri backup o si incontrano problemi con VSS vale la pena saperne di più.
 
Illustriamo più in dettaglio il Virtual Shadow Copy Service
 
Quale problema di backup risolve VSS?
I processi di backup, a seconda del tipo e della quantità di dati, possono richiedere molto tempo.
Questo è un problema poiché i dati coinvolti possono modificarsi nel frattempo, e a volte anche parecchio.
Ciò significa che il backup contiene dati riferiti a momenti di tempo differenti: in altre parole, non è coerente.
Se infatti un file che viene backuppato subisce delle modifiche durante il processo, cosa conterrà il backup?
Questa incongruenza provoca problemi di coerenza delle informazioni, specialmente nel caso di dati applicativi come database che cambiano continuamente.
 
VSS risolve il problema dell'incoerenza dei dati creando e mantenendo una copia (snapshot) di un determinato istante temporale del volume sottoposto a backup; a questo punto il job può eseguire la copia di questo snapshot.
VSS può creare snapshot con due livelli di coerenza:
  • coerenza a livello di crash: viene creata la copia snapshot del volume selezionato. Questa copia non contiene dati in corso di modifica o presenti in memoria, pertanto alcuni possono mancare o essere incoerenti.
  • Coerenza a livello di applicazione: l'applicazione sottoposta a backup controlla i propri file presenti nella copia snapshot per accertarsi che siano corretti. Per esempio, la copia snapshot comprende le informazioni residenti in memoria e le transazioni di database non ancora completate in modo da essere più precisa e coerente.
Come funziona VSS
 
Il servizio VSS si compone di tre sottosistemi che interagiscono per creare e mantenere le copie snapshot:
  • VSS requester (il programma di backup), che richiede la creazione della copia snapshot e, quando questa non è più necessaria, la rimozione;
  • VSS writer: permette a un'applicazione di accertarsi che i rispettivi file inclusi in una copia snapshot siano coerenti con l'applicazione stessa. I VSS writer sono integrati nelle applicazioni compatibili con VSS come per esempio Exchange e SQL Server;
  • VSS provider: crea e mantiene le copie snapshot. I sistemi operativi Microsoft sono dotati di un VSS provider denominato Microsoft VSS Provider.
Chiariti quali siano i sottosistemi usati da VSS, vediamo da vicino come funzionano insieme per creare una copia snapshot. Nello specifico, consideriamo una snapshot creata e mantenuta da un Microsoft VSS Provider.
Il Microsoft VSS Provider crea normalmente le copie snapshot sul medesimo volume dei dati di cui effettua la copia.
Se questi dati cambiano, una copia della loro precedente versione viene salvata in una destinazione denominata "shadow storage". In questo modo la copia snapshot può mantenere una versione dei dati originali risalenti a un determinato istante temporale occupando su disco lo spazio equivalente ai soli dati modificati nel frattempo.
Questo per quanto riguarda il mantenimento della copia snapshot; e per quanto riguarda il suo utilizzo da parte del job di backup?
Il job di backup chiede al servizio VSS di fornire i dati selezionati. A questo punto:
  • se i dati sono cambiati, la snapshot fornisce al job di backup una copia dei dati precedenti al momento del cambiamento prelevandoli dallo shadow storage;
  • se i dati non sono cambiati, la copia snapshot fornisce al job di backup i dati del volume attualmente in uso.
Il processo di copiare i dati di produzione prima che cambino provoca una piccola riduzione delle performance nella scrittura del volume coinvolto. Più a lungo rimane necessaria la copia snapshot, più grande essa diventa; più rapidamente cambiano i dati, più velocemente cresce la snapshot. Lo spazio a disposizione delle copie snapshot deve essere sufficiente per poter mantenere tutte le modifiche apportate ai dati fintanto che la snapshot esiste.
 
Analisi del processo passo passo
 
I diagrammi che seguono illustrano la comunicazione che avviene tra BackupAssist, i dati, la copia snapshot e i sottosistemi. Tutta questa comunicazione viene gestita da e attraverso il servizio VSS.
  1. Il VSS requester (BackupAssist) indica al servizio Microsoft VSS Provider quel di cui ha bisogno avviando la preparazione di una copia snapshot.
  2. Il Microsoft VSS Provider effettua allora la copia snapshot e la mantiene seguendo le modifiche che vengono apportate man mano ai dati originali.
  3. Affinché i backup siano coerenti dal punto di vista delle applicazioni, tutti i VSS writer assegnati segnalano alla copia snapshot ogni modifica apportata ai dati originali.
  4. La copia snapshot è completa e pronta all'uso, e il controllo ritorna a BackupAssist, il VSS requester.
Il job di backup può ora iniziare richiedendo i dati dal servizio VSS per creare il backup.
Una volta che un'applicazione VSS aware come Exchange Server sa che è stato completato il backup dei dati, il suo VSS writer effettua alcune operazioni di pulizia come la cancellazione dei log delle transazioni del database: in questo modo viene liberato spazio su disco e velocizzata l'applicazione stessa.
 
Il job di backup utilizza un percorso variabile che punta sia alla copia snapshot che al volume su cui risiede l'applicazione. Il servizio VSS determina se il file richiesto dal backup risiede nella copia snapshot o tra i dati di produzione. Il software di backup non conosce la provenienza (snapshot o produzione) dei dati di cui esegue il backup
 
Come BackupAssist System Protection usa VSS
 
Ogni report di backup fornisce tutto quel che occorre conoscere circa il report stesso, permettendo di trascorrere meno tempo a cercare risposte e più tempo a gestire i sistemi. I report di backup comprendono tra le altre cose tempi di inizio e di fine, destinazione del backup, numero di file coinvolti e dimensioni del backup.

Un altro utilizzo delle copie snapshot coerenti

Al suo primo avvio, System Protection crea il backup di un'immagine completa. Se i dati selezionati e la loro destinazione non cambiano, il backup successivo è di tipo incrementale. Per fare questo vengono verificati i dati da copiare e quelli già presenti nella destinazione, così da evidenziare le differenze. Il backup viene eseguito sui soli dati modificati.
Determinare quali dati sono cambiati consuma molto tempo, ma BackupAssist è in grado di farlo rapidamente ricorrendo alle copie snapshot. Una copia snapshot sa quali dati sono cambiati dal momento che sono esattamente quelli che essa mantiene. Così, anziché cancellare la snapshot subito dopo un backup, System Protection la conserva per utilizzarla al backup successivo in modo da identificare i dati cambiati. Questo processo è chiamato lettura incrementale.
 

 
Per mantenere una copia snapshot persistente per la lettura incrementale bisogna selezionare all'interno di BackupAssist Setting tab > Windows Settings > Enable incremental Windows Image backups.
Quando la lettura incrementale è abilitata, un backup incrementale da venti minuti può essere completato in soli due minuti.
Questa tecnica funziona solamente se né la destinazione né la selezione dei dati cambiano. Per questa ragione consigliamo di utilizzare lo stesso supporto media per almeno una settimana, così da poter ottenere un guadagno di prestazioni.
System Protection non può utilizzare la lettura incrementale per velocizzare i backup incrementali se la fonte dei dati è un drive formattato ReFS.
 
La copia snapshot storica

La limitazione dei backup di immagini è che ciascun backup sovrascrive i dati che sono cambiati nel frattempo, così che l'utente possa ripristinare i dati solamente dal backup precedente. L'unico modo per creare un punto di ripristino per ciascun backup sarebbe quello di creare il backup di un'immagine completa ogni volta che viene eseguito il job, con un conseguente spreco di tempo e di spazio su disco.
Questa limitazione può essere superata creando una "copia snapshot storica" persistente sulla destinazione di backup. Una copia snapshot storica viene creata prima dell'avvio del job di backup; essa non è altro che una snapshot dello stesso backup. Quando il job ne sovrascrive incrementalmente i dati, la copia snapshot storica conserva una copia dei dati che sono cambiati.
Questo significa che all'esecuzione di un ripristino è possibile utilizzare o il backup dell'immagine o una qualunque di queste copie snapshot storiche per ottenere un punto di ripristino risalente a un determinato istante temporale in cui è stato eseguito un job di backup.
È importante sapere che le copie snapshot storiche risiedono sul medesimo disco del backup. Lo spazio su disco utilizzato da queste snapshot per memorizzare i dati viene chiamato "volume shadow copy storage". Quando la quantità di spazio su disco allocata per lo shadow copy storage raggiunge il suo limite, i dati più vecchi vengono cancellati per far posto ai nuovi dati.
Per questa ragione occorre:
  1. Usare questa destinazione solamente per i backup.
  2. Definire lo spazio su disco allocato per la shadow copy a una dimensione che ne permetta la crescita all'aggiunta di nuovi dati.
Le copie snapshot storiche possono essere supportate solamente dalle destinazioni che vengono viste come dispositivi locali dal computer sottoposto a backup.
Queste destinazioni comprendono hard disk locali, target iSCSI, hard disk esterni (collegati direttamente) e Data Container di BackupAssist.
 
(tratto da BackupAssist Blog)

Autore
Claudio Panerai
Gli ultimi prodotti che vi ho portato, nel 2020: Vade Secure Il primo sistema antispam/antihishing/antimalware basato sull'intelligenza artificiale e appositamente progettato per Office 365. Naturalmente a misura di MSP. ID Agent Piaffaforma che consente agli MSP di monitorare le credenziali (proprie e dei clienti) che sono in vendita nel dark web.
Nato a Ivrea nel 1969, è sposato e padre di due figlie. Laureato in Scienze dell’Informazione nel 1993, ha dapprima svolto numerose consulenze e corsi di formazione per varie società per poi diventare responsabile IT per la filiale italiana del più grande editore mondiale di informatica, IDG Communications. Dal 2004 lavora in Achab dapprima come Responsabile del Supporto Tecnico per poi assumere dal 2008 la carica di Direttore Tecnico. Giornalista iscritto all’albo dei pubblicisti, dal 1992 pubblica regolarmente articoli su riviste di informatica e siti web di primo piano. E' stimato da colleghi e clienti per la schiettezza e onestà intellettuale. Passioni: viaggi, lettura, cinema, Formula 1, sviluppo personale, investimenti immobiliari, forex trading. Claudio è anche su LinkedIn e Facebook.
Commenti (0)

Lascia un commento

Il tuo indirizzo e-mail non verrà pubblicato, lo utilizzeremo solamente per inviarti la notifica della pubblicazione del tuo commento. Ti informiamo che tutti i commenti sono soggetti a moderazione da parte del nostro staff.

Tieniti aggiornato

Inserisci il tuo indirizzo e-mail per restare aggiornato su tutte le nostre iniziative