DPM 2010 - Come funziona il backup su disco

Ciao a tutti, con questo articolo vorrei descrivere come Data Protection Manager 2007/2010 esegue il backup su disco dei server che intendiamo proteggere.

Come già tutti saprete, affinchè DPM sia in grado di comunicare con uno dei nostri server è necessario che su di esso venga installato il replication agent. Per capire come è possibile installare l’agente su un server è possibile rifarsi all’articolo: DPM 2010 – Installazione del Protection Agent. Per ora ci sarà comunque sufficente ricordare che il Replication Agent, insieme al file system filter driver (Volume filter driver in DPM 2007) ed ai relativi writers presenti sulla macchina, tiene traccia dei cambiamenti relativi ai dati che intendiamo proteggere, identifica i datasource presenti sulla macchine ed è coinvolto nel processo di recovery.

Appena preparato il nostro ambiente con l’installazione dei pre-requisiti e dei vari agenti, un esempio di architettura generale è il seguente:

Tralasciamo per il momento la configurazione di Disaster Recovery, che verrà trattata separatamente in uno dei successivi articoli.

Il metodo che Data Protection Manager usa per proteggere i dati varia con la tipologia di protezione che selezioniamo, indicata come Disk Based Recovery o Tape-Based Backup nel la figura sopra.

In questo artivolo tratteremo la protezione basata su disco.

Se, durante la creazione di un protection group, selezioniamo questo tipo di protezione:

DPM creerà una replica dei dati che intendiamo proteggere, che sarà memorizzata sullo storage pool o sull’eventuale custom volume.

Il momento in cui sarà creata l’Initial Replica dei nostri dati, possiamo deciderlo al termine della creazione del Protection Group:

Sostanzialmente abbiamo tre opzioni:

• Creare la copia immediatamente, sfruttando il collegamento di rete
• Schedulare la copia utilizzando il collegamento di rete
• Copiare manualmente i dati

L’ultima opzione è utile nel caso in cui il nostro datasource abbia dimensioni tali che potrebbero introdurre dei problemi di servizio, se la copia viene effettuata attraverso rete.

Ma dove viene memorizzata questa copia?

Partendo da un protection group, il metodo più semplice per capirlo, è cliccare sul replication path dai dettagli del protection group:

In generale comunque sotto il path \Microsoft DPM\DPM\Volumes\Replica troveremo (Suddivisi per tipologia di datasource protetti)  i mounting points ai volumi che contengono le repliche.

La cartella \Microsoft DPM\DPM\Volumes\DiffArea contiene invece i mounting points ai volumi che contengono i recovery points per i vari datasources.

Questo significa, che la protezione di un singolo datasource implica la creazione di almeno due volumi nello storage pool (Oppure l’utilizzo di due custom volumes), uno dedicato alla replica ed uno dedicato ai reovery points.

In DPM 2007, questo aspetto introduceva il limite massimo di 300 datasources proteggibili legato alla dimentione fissa in Windows del Logical Disk Manager database.

Superato tale limite, infatti, si rischiava di saturare il database LDM, che tiene traccia di tutti i volumi e le eventuali espansioni sulla macchina, con l’effetto collaterale di non riuscire a  creare nuovi volumi o ad espandere quelli esistenti.

Questo discorso è stato rivisto con l’introduzione in DPM 2010 della data colocation. Lo stesso limite è naturalmente ancora presente, essendo legato all’architettura di sistema, ma è possibile per specifici datasource abilitare la disk colocation feature. Questa funzionalità, che è possibile abilitare durante la creazione di un protection group, consente di utilizzare un solo replica e recovery point per più datasource della stessa tipologia che supportano questa funzionalità.

Attualmente, in DPM 2010 RTM, questi sono i datasources che supportano la disk colocation:

• SQL Server
• Hyper-V virtual machines
• Clients

Durante la creazione del protection group sarà dunque possibile specificare di utilizzare la disk colocation, in modo da poter utilizzare solo due volumi per la protezione di questi datasources, mitigando notevolmente la limitazione del database LDM (Che va comunque sia sempre tenuta in considerazione durante il planning del numero di server DPM da utilizzare).

Il concetto di sincronizzazione o express full backup è differente a seconda del fatto che si stia parlando di backup di file system o di applicazioni. L’unico aspetto comune ad entrambe le tipologie di datasource è la retention, che rappresenta il periodo che noi intendiamo mantenere i dati che abbiamo salvato prima che vengano rimossi. Naturalmente, maggiore è il retantion range e maggiore sarà lo spazio che necessiteremo nel volume che contiene i recovery points. Vediamo ora di chiarire i concetti di recovery points e sincronizzazione per i file system e le applicazioni.

Protezione di file system datasource

Durante la creazione di un protection group per una share o un volume, dovremo seleziona la frequenza di sincronizzazione e la frequenza di creazione dei recovery points.

In questo esempio abbiamo una frequenza di sincronizzazione di 15min e tre recovery points al giorno: 8.00 AM, 12.00 PM e 6.00 PM.

Cosa rappresentano esattamente questi due parametri per questo tipo di datasource?            

La frequenza di sincronizzazione rappresente la frequenza con cui la replica viene aggiornata con le modifiche presenti sul server in prodizione.

Questo significa che a ciascuna sincronizzazione non corrisponderà un recovery point, ma semplicamente un refresh della copia che noi stiamo mantenendo sul server DPM.

La sincronizzazione ci offre dunque la possibilità di scegliere il massimo intervallo temporale di dati persi, se ad un’ora x:xx mi si rompe ad esempio il disco ed io voglio ripristinare i dati più recenti a disposizione.

Nello screenshot sopra, con una frequenza di sincronizzazione di 15 min, abbiamo la garanzia che ad una determinata ora x:xx, ripristinando i dati più recenti in mio possesso, perderò al massimo 15 min di lavoro dell’utente.

La frequenza di creazione dei recovery points, rappresenta la frequenza con cui io voglio creare un “salvataggio” dei mie dati che potrò ripristinare nel tempo.

Questo significa che se io alle 17.00 mi accorgo che è stato salvato erroneamente un file alle 9.15 del mattino e voglio fare il recovery della versione precedente, potrò affidarmi al recovery point più recente.

Se consideriamo ad esempio lo screenshot riportato sopra, il recovery point più recente che soddisfa la mia richiesta sarà quello delle 8.00 AM.

Per capire meglio questo concetto consideriamo il seguente esempio:

Protezione della cartella riportata sotto con frequenza di  sincronizzazione di 15 min e creazione dei recovery points tre volte al giorno 8.00 AM, 01.00 PM e 7.00 PM

Consideriamo la seguente sequenza:

• Alle 8.00 viene eseguita la creazione del recovery point per la cartella Documenti
• Alle 8:15 Sync e così via ogni 15 min
• Alle 8.50 l’utente mrossi modifica il file degli stipendi aggiornando l’aumento per l’area tecnica
• Alle 9.10 l’utente mrossi modifica il file degli stipendi adeguando le cifre con i relativi aumenti
• Alle 12.10, l’utente gverdi aggiorna il file dipendenti.xlsx inserendo 10 nuovi utenti
• Alle 12.10 l’utente gverdi aggiorna il file dipendenti.xlsx inserendo altri 10 utenti, ma ahimè sovrascrivendo i 10 utenti già presenti
• Alle 13.00 viene eseguita la creazione del recovery point per la cartella Documenti

Considerate i seguenti eventi:

• Alle 9.12 si rompe il disco. Viene ripristinata l’ultima copia disponibile, relativa alla replica con la sincronizzazione delle ore 9.00. L’utente mrossi deve insierire nuovamente la modifica effettuata alle 9.10.
• Alle 10.15 l’utente mrossi si accorge che tutt gli aumenti insieriti in gionrata sono errati. Può ripristinare l’ultimo recovery point disponibile, relativo alle 8.00.
• Alle 17.00, con calma l’utente gverdi si accorge dell’errore di sovrascrizizione degli utenti (Tra cui il general manager dell’azienda). A questo punto deve assolutamente recuperare il precovery point più vicino alla data di modifica, che sarà quello relarivo alle 8.00.

Riepilogando, dunque:

• La sincronizzazione fa solo un refresh della replica, non crea un punto nel tempo che noi possiamo ripristinare
• La creazione di un recovery point, mette a disposizione un punto nel tempo che è possibile ripristinare

Protezione di applicazioni

Come i cambiamenti nel server di produzione vengono trasferiti al server DPM, cambia in base al tipo di applicazione che stiamo proteggendo:

• Per gli Exchange servers, la sincronizzazione trasferisce una snapshot VSS incrementale creata utilizzando il writer di Exchange. Questo significa, che ogni sincronizzazione creerà un recovery point e aiquali sarà anche possibile aggiungere la creazione di Express full backups, dei quali vedremo l’utilità in seguito.
• SQL Server databases che sono log-shipped, in read-only mode, o che usano il simple recovery model non supportano i backup incrementali. I recovery points sono create esclusivamente in concomitanza di ciascun  express full backup. Escluse queste casistiche per tutti I SQL Server databases, la sincronizzazione trasferisce il backup del transaction log backup. Questo implica, anche in questo caso, che i recovery points sono create sia per ogni sincronizzazione che per gli express full backup. The transaction log is a serial record of all the transactions that have been performed against the database since the transaction log was last backed up.
• Windows SharePoint Services, Microsoft Virtual Server ed Hyper-V non supportano backup incrementali. I recovery points verranno create dunque per ciascun express full backup.

Possiamo in generale distinguere tra applicazioni transazionale, che supportano i backup incrementali, ed applicazioni non transazionali, che creeranno un recovery point esclusivamente per ciascun express full backup schedulato.

Detto questo, qual è la differenza tra una sincronizzazione e l’express full backup? E quali vantaggi introduce l’express full backup?

Per rispondere a queste due domande, chiariamo cosa viene eseguito durante le due operazioni:

• Sincronizzazione: Vengono trasferite dal server protetto tutte le modifiche eseguite rispetto all’ultima operazione di sincronizzazione o express full backup, che vengono salvate insieme alla replica.
• Express full backup: Viene salvato un punto nel tempo della replica più tutti gli incrementali, attraverso una copia shadow permanente che verrà memorizzata nel volume destinato a contenere i recovery points. Dopo questa operazione tutti gli incrementali, frutto delle varie sincronizzazioni fatte a partire dal precedente express full backup, vengono consolidati nell’attuale replica facendone un refresh.

La sincronizzazione richiede, dunque, meno tempo rispetto all’esecuzione di un express full backup. Tuttavia, il tempo richesto per il recovery aumenta all’aumentare delle sincronizzazioni perchè DPM per effettuare il recovery di un punto nel tempo x:xx, deve restorare l’express full backup più recente ed applicargli tutte le sincronizzazioni incrementali effettuate fino a quel momento.

Per chiarire meglio questo concetto, consideriamo il seguente esempio:

Backup di un server SQL con sincronizzazione ogni 15 min ed un express full backup ogni giorno a mezzanotte.

Consideriamo i seguenti scenario:

• Recovery del database alle 23.55 del giorno x. DPM effettuerà il restore dell’express full backup delle 0:00 del giorno x, più tutti gli incrementali creati ogni 15 minuti (L’ultimo alle 23:45 – circa 95 incrementali).
• Recovery del database alle 00:16 del giorno x+1. DPM effettuerà il recovery dell’express full backup delle 0:00 del giorno x+1, più l’unico incrementale (00:15) creato fino a quel momento.

Il vataggio che ci offrono gli express full backup è costituito da un recovery time inferiore.

Differenze importanti da ricordare

• Per la protezione di files, la sincronizzazione effettua esclusivamente un refresh della replica, senza salvare alcun recovery point. I recovery points verranno creati esclusivamente agli orari da noi specificati, durante la creazione del protection group.
• Per le applicazioni transazionali, ciascuna sincronizzazione corrisponde ad un recovery point nel tempo. La creazione degli express full backups ci aiuta a soddisfare quelli che sono i nostri obbiettivi per il recovery time.

Spero che questo articolo abbia chiarito qualche concetto di base sulla protzione su disco e che possa aiutarvi durante il planning delle Sincronizzazioni / Recovery Points / Express Full Backups.

Mattia Tocco
Support Escalation Engineer
Microsoft Enterprise Platform Support