Virtualizzazione

Backup e ripristino di emergenza per la virtualizzazione server

Adam Fazio

 

Panoramica:

• Considerazioni sulla pianificazione del ripristino di emergenza
• Soluzioni a disponibilità elevata per il ripristino di emergenza
• Backup e ripristino con Windows Server BackupItem

Indice

Pianificazione del ripristino di emergenza 101
Ripristino di emergenza e virtualizzazione
Conversione da macchina fisica a virtuale
Snapshot della macchina virtuale
Backup di Hyper-V
Windows Server Backup
Backup delle macchine virtuali con WSB
Considerazioni
Ripristino delle macchine virtuali con WSB
Data Protection Manager
Backup tramite script
DiskShadow
Conclusioni

Di fronte all'evoluzione e all'accresciuto utilizzo della tecnologia di virtualizzazione, le aziende iniziano a riconoscere che i vantaggi che ne derivano vanno ben oltre quelli più conosciuti, vale a dire: costi di infrastruttura ridotti e maggiore agilità IT. La nuova frontiera utilizza la piattaforma di virtualizzazione come strumento per realizzare o migliorare le strategie di ripristino di emergenza.

Perché la preparazione al ripristino di emergenza rappresenta uno dei temi più discussi nel settore IT? Da alcuni studi risulta che le aziende perdono in media dagli 80.000 ai 90.000 USD per ogni ora di inattività e che solo pochissime aziende che subiscono un'ingente perdita di dati riescono poi a sopravvivere a lungo termine. Il presente articolo contiene un'introduzione al ripristino di emergenza tramite la piattaforma di virtualizzazione di Microsoft, una descrizione dettagliata delle opzioni di backup e ripristino e, infine, alcune considerazioni relative a Windows Server 2008 Hyper-V.

Pianificazione del ripristino di emergenza 101

Il ripristino di emergenza rappresenta il processo di ripristino dei servizi critici che viene eseguito dopo un'interruzione dell'alimentazione. Tale processo dovrebbe far parte del piano di continuità di ogni azienda, il quale definisce le modalità in cui l'azienda continua a funzionare durante o in seguito a situazioni di emergenza. Questi piani rappresentano l'elemento fondamentale di qualsiasi iniziativa di ripristino di emergenza.

Alcuni fornitori sostengono che la propria tecnologia di automazione del ripristino di emergenza riduce al minimo o addirittura elimina la necessità di un piano dettagliato e collaudato. Sebbene sia possibile affermare che un sistema di automazione può migliorare i tempi di ripristino e ridurre la necessità dell'intervento umano, va tuttavia ricordato che non è possibile attenuare le conseguenze di una situazione di emergenza facendo ricorso esclusivamente alla tecnologia. Le persone e i processi sono importanti quanto le tecnologie.

Infatti, è praticamente impossibile scegliere le tecnologie corrette senza prima conoscere tutti i vincoli e gli obiettivi insiti in un processo di pianificazione del ripristino di emergenza. Lo scopo del presente articolo non è definire un intero piano di ripristino di emergenza, bensì sottolineare gli elementi fondamentali nella scelta delle tecnologie e implementazioni corrette. Pertanto, verranno analizzati brevemente alcuni driver tecnologici critici all'interno di un piano di ripristino di emergenza.

Definizioni di servizio e impostazione delle priorità Come viene definito esattamente il servizio completo che si desidera proteggere e qual è la sua importanza per l'organizzazione? Figura 1 mostra alcuni esempi di servizi aziendali che potrebbero essere inseriti in qualsiasi piano di ripristino di emergenza.

Figura 1 Esempio di definizioni di servizio e impostazione delle priorità

Servizio	Componenti primari	Dipendenze	Uso aziendale	SLA
Sito Web pubblico	Bilanciamento del carico di rete, tre server Web, due server database	DNS, rete, firewall, directory, sistema di archiviazione SAN (Storage Area Network)	Acquisto dei prodotti e rilevamento degli ordini; eCommerce; portale di assistenza clienti; informazioni aziendali	99.99%
Sistema finanziario	Due server database, un server applicazioni	DNS, rete	Registrazione dei profitti aziendali, in ottemperanza alle leggi e alle normative vigenti	99.99%
Sistema di posta elettronica	Tre server di posta elettronica, un server Web	DNS, rete, firewall, directory	Comunicazioni aziendali; assistenza clienti	99.5%

Una volta definiti i servizi, è possibile iniziare ad identificare i sistemi e le dipendenze da destinare ai vari tipi di strategie di ripristino di emergenza. Dopo un attento esame dell'intera serie di servizi e dipendenze, potrebbe essere necessario prendere in considerazione diversi livelli di funzionalità di ripristino di emergenza. Infatti, un'unica soluzione di ripristino di emergenza per tutti i servizi mission-critical potrebbe risultare troppo costosa e complessa.

Contratti di servizio (SLA) Con SLA si intende un accordo o un contratto tra il provider di servizi (IT) e il cliente (l'azienda); tale documento definisce i valori soglia della disponibilità per un determinato servizio. Tali valori possono essere più o meno alti; ad esempio: "Il sistema di posta elettronica sarà disponibile per il 99,95% del tempo durante le normali ore lavorative e per il 98% del tempo durante le restanti ore del giorno, ad eccezione degli intervalli di manutenzione programmati, valori misurati mensilmente". In genere, gli SLA sono suddivisi in livelli ai quali è possibile assegnare servizi IT, misurati in base ad un periodo di tempo predefinito.

Contratti operativi (OLA) Gli OLA indicano, fondamentalmente, gli accordi stipulati tra diversi gruppi IT che collaborano all'attuazione di uno SLA e includono i tempi di elaborazione e di risposta per la distribuzione dei servizi. Si supponga di avere un sito Web mission-critical con un valore di soglia SLA pari al 99,99%, ma il database da cui dipende per il suo contenuto ha un valore soglia della disponibilità pari soltanto al 95%. Un OLA consente di individuare tali discrepanze e guida i team IT verso il raggiungimento di un obiettivo comune.

Recovery Point Objective (RPO) e Recovery Time Objective (RTO) Un RTO indica il periodo di tempo massimo in cui un servizio può non essere disponibile prima che si verifichi un'interruzione nella continuità; un RPO definisce il livello massimo della perdita di dati che l'azienda può sostenere. Se un servizio ha un SLA pari al 99% mensile, ne consegue che il suo RTO equivale a 7 ore e 18 minuti. Se si somma questo valore ad un RPO, ad esempio, di 24 ore è possibile definire con precisione tecniche di backup e pianificazioni.

Criteri di conservazione dei dati I criteri di conservazione dei dati di un'organizzazione specificano in maniera precisa la durata e la posizione di conservazione dei backup. In genere, sono regolamentati da requisiti legali e normativi.

Categorizzazione dei dati Occorre valutare anche la natura dei dati. Suddividendo i dati in categorie, risulta subito evidente che non tutti i dati richiedono lo stesso livello di considerazione del ripristino di emergenza. Ad esempio, un unico database potrebbe prevedere requisiti di disponibilità diversi rispetto a un'Active Directory con più controller di dominio, contenenti ciascuno una copia della directory. Allo stesso modo, i dati dei file server potrebbero prevedere procedure di ripristino molto diverse da quelle dei dati CRM.

Scenari di emergenza È importante definire tutti gli scenari che si desidera pianificare poiché ciascuno di essi comporta caratteristiche differenti, vale a dire procedure di ripristino, impatto sull'azienda e costi. È utile prendere in considerazione tutti gli scenari possibili e poi decidere su quali intervenire al momento della pianificazione di un ripristino di emergenza per il proprio ambiente:

• Perdita di un intero sito
• Perdita di un unico centro dati
• Perdita di un sistema (errore sistema operativo o hardware)
• Perdita di dati (eliminazione o danneggiamento dei dati)
• Perdita di una dipendenza critica

Ovviamente, il recupero dalla perdita di un intero sito e quello di un solo sistema rappresentano situazioni ben diverse. È possibile anche che si desideri definire le soglie di ripristino in base ai propri SLA. Si immagini, ad esempio, che un intero sito non sia in linea a causa di una lunga interruzione della rete ISP. Se l'SLA per il servizio interessato prevede un tempo di 8 ore per il ripristino del servizio e 48 ore per il ripristino dei dati, si può decidere di eseguire alcune procedure di failover di servizio nel proprio sito di backup, senza tuttavia eseguire il processo di recupero dei dati poiché ciò anticiperebbe, in maniera piuttosto rapida, l'esecuzione del failback sul sito di produzione.

Wow! Tutta questa fatica e ancora non è stata analizzata la tecnologia! È bene non sottovalutare l'importanza critica della pianificazione. L'implementazione di un ripristino di emergenza senza alcun piano documentato è pura utopia.

Ripristino di emergenza e virtualizzazione

Ora che tutti gli elementi fondamentali per la pianificazione di un ripristino di emergenza sono stati analizzati, è necessario scoprire il ruolo della virtualizzazione. Molte aziende calcolano in minuti l'arco di tempo impiegato per il ripristino del servizio con server virtualizzati rispetto ai giorni o alle settimane necessari ai server fisici. Poiché oggi l'intero sistema operativo server è costituito semplicemente da una serie di file estratti dall'hardware fisico sottostante, si aprono nuovi orizzonti in termini di recuperabilità.

Secondo una teoria oggigiorno molto diffusa, grazie alle soluzioni di disponibilità elevata è possibile raggiungere alcuni o tutti gli obiettivi di ripristino di emergenza. L'idea alla base di tale convinzione è che in questo modo, in presenza di nodi cluster in posizioni fisiche separate con dati sincronizzati tra i siti, in caso di errore il nodo passivo è in grado di riprendere le operazioni consentendo il ripristino quasi in tempo reale.

Questo è vero, ma se si ripensa agli scenari di emergenza analizzati in precedenza è evidente che questa soluzione non è sempre attuabile. Per essere pronti ad affrontare tutti gli scenari possibili è necessaria una combinazione di tecnologie che solitamente prevede l'esecuzione di backup regolari. La disponibilità elevata non protegge da tutte le eventuali interruzioni di alimentazione e non elimina del tutto la necessità di una strategia di esecuzione di backup.

La disponibilità elevata con Hyper-V richiede l'attenta pianificazione del livello di archiviazione, fattore critico per l'esecuzione del recupero. Ad esempio, in un cluster Hyper-V con 2 nodi e archiviazione condivisa il sottosistema di archiviazione e i dati rappresentano un singolo punto di errore anche se i nodi cluster sono situati in datacenter separati.

Tuttavia, occorre ricordare che lo stesso cluster Hyper-V a 2 nodi con archiviazione non condivisa è in grado di far fronte alla perdita di dati o archiviazione su uno o sugli altri nodi. Ciò rende necessario l'utilizzo di tecnologie di replica al fine di mantenere l'archiviazione sincronizzata e implica inoltre una maggiore complessità (vedere la Figura 2).

Figura 2 Cluster Hyper-V multisito (fare clic sull'immagine per ingrandirla)

Esistono sviluppi molto interessanti nell'ambito della replica e della sincronizzazione dei dati, ma Microsoft, al momento, non se ne occupa. Nella pagina relativa al clustering multisito di Windows Server 2008 (microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx) vale la pena dare un'occhiata ai partner indicati. Un'altra importante risorsa è il catalogo di Windows Server (vedere windowsservercatalog.com), che elenca i fornitori di soluzioni di archiviazione con tecnologie di replica certificate per Windows Server 2008.

Come si può osservare, esistono numerose configurazioni di archiviazione e disponibilità elevata da valutare. Anche in questo caso, è chiaro il motivo per cui occorre definire i propri requisiti aziendali e far sì che siano questi a determinare i requisiti tecnici piuttosto che il contrario.

Conversione da macchina fisica a virtuale

La virtualizzazione offre un'agilità di ripristino certamente unica, ma cosa dire dei sistemi fisici non adatti alla virtualizzazione? System Center Virtual Machine Manager (SCVMM) è in grado di eseguire conversioni da macchina fisica a virtuale (P2V) di server che eseguono Windows. Tale conversione determina la creazione di una macchina virtuale Hyper-V avviabile che rappresenta una copia esatta del server fisico di origine. Ora è possibile replicare questa macchina virtuale con le stesse modalità delle sue controparti virtualizzate all'interno di un'università o a livello nazionale e conseguire tempi di ripristino simili.

Questo approccio è diverso rispetto al tradizionale sistema di ripristino bare metal in quanto la posizione di ripristino non necessita più dello stesso numero o tipo di sistemi fisici come nel caso della posizione di produzione. È dunque possibile sottoscrivere in eccesso il proprio hardware di ripristino e scalarlo come necessario in base all'impatto della situazione di emergenza.

Sebbene SCVMM non contenga un'utilità di pianificazione per conversioni P2V, poiché la GUI viene eseguita interamente su Windows PowerShell, è possibile eseguirne facilmente lo script utilizzando il nuovo cmdlet P2V. Infatti, tutte le procedure guidate di SCVMM mostrano il codice utilizzato per eseguire un lavoro e quindi è possibile copiare il codice di un test P2V nel proprio ambiente e modificarlo per utilizzarlo automaticamente in futuro. La Figura 3 mostra alcuni codici di esempio; è possibile eseguire la procedura guidata P2V di SCVMM nel proprio ambiente per creare uno script Windows PowerShell univoco e personalizzabile.

Figura 3 Codice creato tramite la procedura guidata P2V di SCVMM

$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>" 
-Credential $Credential -RunAsynchronously 

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F" 
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External" 
-MachineConfig $MachineConfig 

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig 

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path 
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig 
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM 
-UseHardwareAssistedVirtualization $false -StopAction SaveVM 

Snapshot della macchina virtuale

Sebbene dal punto di vista tecnico non si tratti di un backup, uno snapshot della macchina virtuale indica un punto temporale a cui ritornare utilizzando dischi differenze e una copia del file di configurazione della macchina virtuale. Una situazione in cui si verifica l'eliminazione accidentale dei dati all'interno della macchina virtuale, può essere considerata una funzionalità del ripristino di emergenza in quanto è possibile eseguire il rollback della macchina virtuale per recuperare lo snapshot e risolvere il problema. (In seguito, viene offerta una breve analisi degli snapshot del servizio Copia Shadow del volume o VSS).

Backup di Hyper-V

Backup basati su host Uno dei vantaggi più straordinari offerti dalla virtualizzazione server è la prospettiva di non dover più eseguire il backup individuale dei sistemi virtualizzati. Poiché questi sistemi sono costituiti semplicemente da file presenti in un file system dell'host, basta eseguire il backup dei file, giusto? Non esattamente. Poiché stiamo parlando di live computer composti da dati in memoria, dati su disco, configurazioni di sistema e file aperti, occorre prendere in considerazione quanto segue. Come è possibile garantire la coerenza dei dati di backup alla luce di tutti questi elementi?

Un miglioramento significativo della storia del backup in Windows Server si è ottenuto con Windows Server 2003 e con l'avvento di VSS che fornisce una serie standard di API estendibili che i writer VSS (hook in applicazioni e servizi che aiutano a fornire copie shadow coerenti) utilizzano per creare backup di file aperti e di applicazioni. Con l'aiuto del servizio VSS, di fornitori e writer, l'applicazione di backup può creare molto velocemente una copia riferita a un momento temporale specifico di un volume che l'applicazione riconosce e può quindi elaborare adeguatamente.

Hyper-V dispone del proprio writer VSS che consente ai produttori di software di creare straordinarie soluzioni di backup. Il writer consente alle applicazioni di backup di eseguire backup VSS basati su host delle macchine virtuali in esecuzione. Se i componenti di integrazione Hyper-V e il servizio VSS (disponibile in Windows XP SP1 e Windows Server 2003 e versioni successive) sono installati su un sistema operativo eseguito all'interno della macchina virtuale, il backup basato su host ha luogo come se venisse eseguito all'interno del guest; il backup viene eseguito con la macchina virtuale in esecuzione e i dati risultano coerenti (vedere la Figura 4).

Figura 4 Backup VSS (fare clic sull'immagine per ingrandirla)

Tuttavia, se il sistema operativo guest non supporta i componenti di integrazione né VSS, per l'esecuzione del processo di backup è necessario che la macchina guest sia posta in stato salvato e che si ottenga uno snapshot VSS basato su host dei file di dati della macchina virtuale. Tale snapshot può essere utilizzato per il ripristino temporizzato. Gli snapshot VSS in stato salvato saranno esposti ad un determinato tempo di inattività della macchina virtuale (che può variare dai 5 ai 10 minuti), mentre tutte le procedure di backup su nastro vengono eseguite in rapporto alla copia VSS dei dati.

Backup basati su guest In un ambiente fisico il backup dei server e delle applicazioni deve essere eseguito singolarmente. Backup di questo genere possono continuare in un datacenter virtualizzato. In tale contesto, eseguendo il backup di una macchina virtuale occorre tener presente sempre le stesse considerazioni ossia i requisiti della capacità di rete per backup basati sulla rete e l'impatto delle prestazioni sul sistema durante la finestra di backup. Per quanto riguarda i backup basati su guest, è possibile scegliere di utilizzare una NIC fisica dedicata nell'host associata a una rete virtuale utilizzata da tutti i guest.

Windows Server Backup

Windows Server 2008 contiene Windows Server Backup (WSB) con supporto VSS che può essere utilizzato per eseguire backup Hyper-V basati su host e su guest delle proprie macchine virtuali. Poiché del tutto in grado di utilizzare VSS, tale soluzione può eseguire backup basati su host delle macchine virtuali in esecuzione, di gran lunga l'opzione migliore.

Nel caso in cui si disponga di macchine virtuali prive di componenti di integrazione installati, VSS non viene utilizzato. In tal caso, si può scegliere tra un paio di opzioni. È possibile continuare ad utilizzare WSB per eseguire il backup di una macchina virtuale in cui i componenti di integrazione non sono stati installati. Ciò implica il salvataggio dello stato della macchina virtuale e il successivo prelievo, da parte del backup, dei dischi virtuali e dei file di configurazione della macchina virtuale.

Tuttavia, questa soluzione non è consigliabile nel caso di un'applicazione Exchange poiché essa non è in grado di riconoscere l'esecuzione di un backup e i registri delle applicazioni non vengono troncati. Inoltre, la macchina virtuale è soggetta a tempi di inattività che variano a seconda del tempo impiegato per il backup.

In alternativa, è possibile eseguire un backup dall'interno della macchina virtuale, proprio come se si trattasse di una macchina fisica, utilizzando NTBackup o WSB a seconda del sistema operativo installato nella macchina. Di seguito sono riportate le modalità di utilizzo di WSB per i guest supportati che dispongono di componenti di integrazione installati.

Backup delle macchine virtuali con WSB

Hyper-V non registra automaticamente il proprio writer VSS per l'utilizzo con WSB. Occorre aggiungere manualmente il valore e la chiave del Registro di sistema illustrati nella Figura 5 prima che WSB possa supportare un backup Hyper-V. È possibile aggiungerli nella riga di comando come indicato di seguito:

reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v

Figura 5 Chiave e valore per la registrazione del writer VSS di Hyper-V

Percorso	Valore o chiave del Registro di sistema	Tipo
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}	Chiave	n\a
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier	Valore	REG_SZ (Hyper-V, ad esempio)

Tale procedura non richiede il riavvio della macchina, poiché WSBricerca tale valore/chiave in fase di runtime del backup. Il seguente comando mostra se la voce è stata impostata:

reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s

Ecco come installare WSB. Fare clic su Start | Server Manager. Nel riquadro sinistro fare clic su Funzionalità, quindi su Aggiungi funzionalità nel riquadro destro. Nella pagina Seleziona funzionalità, aprire la finestra Funzionalità di Windows Server Backup e spuntare le caselle di controllo Windows Server Backup e Strumenti di riga di comando. Per configurare il backup, effettuare la seguente procedura:

1. Fare clic su Start | Strumenti di amministrazione | Windows Server Backup.
2. In caso di backup di un host remoto, scegliere Connetti ad un altro computer e digitare l'host Hyper-V.
3. Scegliere Backup unico o Pianificazione backup.
4. Selezionare la configurazione del backup — Server completo o Personalizzato. Se si sceglie l'opzione Personalizzato, accertarsi di disporre di tutti i volumi che contengono dati relativi alla macchina virtuale sottoposta a backup, compresi i dati di configurazione della macchina virtuale, i dischi virtuali e gli snapshot.
5. Scegliere la posizione di memorizzazione del backup.
6. Scegliere Backup completo del servizio Copia Shadow del volume o Copia di backup del servizio Copia Shadow del volume. In caso di backup basati su host in cui non si eseguono altri backup con le macchine virtuali, scegliere Backup completo del servizio Copia Shadow del volume.
7. Una volta confermati i dettagli, selezionare Backup.

Considerazioni

• È necessario eseguire il backup di tutti i volumi relativi ad una macchina virtuale, compresi i dischi rigidi virtuali (VHD), i file di configurazione della macchina virtuale e gli snapshot.
• Se si sta creando una Pianificazione backup, occorre utilizzare un volume locale dedicato che verrà formattato e utilizzato esclusivamente da WSB. Al contrario, se si sceglie l'opzione Backup unico, è possibile memorizzare il backup su un volume locale non dedicato, su un dispositivo rimovibile o su una condivisione di rete.
• Se nella macchina virtuale sottoposta a backup non sono stati installati i componenti di integrazione, WSB salverà lo stato della macchina virtuale in esecuzione al fine di garantire la coerenza dei dati di backup.
• Al termine dell'operazione, il set di backup è portatile e può essere utilizzato con qualsiasi host Hyper-V.

Ripristino delle macchine virtuali con WSB

Sebbene WSB sia in grado di ripristinare file singoli, questa funzionalità non prevede l'utilizzo di VSS e potrebbe determinare quindi un ripristino non coerente se la macchina virtuale era in esecuzione durante il backup. Per eseguire il ripristino della macchina virtuale in esecuzione occorre ripristinare l'intero volume.

A questo scopo, è necessario selezionare Start | Strumenti di amministrazione | Windows Server Backup e, nel riquadro Azioni, selezionare Ripristino. Selezionare il server da cui recuperare i dati (quello dove si trovano i dati di backup WSB), quindi scegliere la data a partire dalla quale recuperare i dati. Ora è possibile scegliere il tipo di ripristino.

A questo punto occorre prendere una decisione. Se si ha bisogno dell'intera macchina virtuale, compresi configurazione, snapshot e dischi virtuali (nel caso, ad esempio, di un guasto totale all'host), selezionare Ripristino dell'applicazione, quindi Hyper-V, come mostrato nella Figura 6. In questo caso non è disponibile l'opzione per il ripristino dei singoli file. Sarà necessario ripristinare l'intero contenuto di quel set di backup. Si noti che in questo modo non verranno sovrascritti i dati relativi alla configurazione esistente di Hyper-V e della macchina virtuale che sono stati modificati dal backup.

Figura 6 Ripristino di un backup Hyper-V (fare clic sull'immagine per ingrandirla)

Se si ha bisogno solo del VHD e i dati di configurazione e gli snapshot della macchina virtuale sono integri, è possibile selezionare File e cartelle e selezionare il singolo file VHD necessario. Si noti che questo processo non utilizza il writer VSS; la macchina virtuale dovrebbe essere stata sottoposta a backup tenendo conto di questo fatto, avendo salvato in primo luogo il suo stato.

In caso di perdita totale di sistema e dati e qualora sia necessario ripristinare l'host Hyper-V, compreso il sistema operativo di Windows Server 2008 e tutte le relative macchine virtuali in esecuzione, occorre attivare Ambiente ripristino Windows, quindi eseguire il ripristino. Questa operazione può essere effettuata tramite il disco di installazione di Windows Server 2008 o una partizione del disco preconfigurata.

Data Protection Manager

Sono stati analizzati i passaggi necessari all'esecuzione del backup e del ripristino tramite la soluzione WSB, affidabile, gratuita e incorporata, con alcune considerazioni su host e guest Hyper-V; tuttavia, WSB non rappresenta una soluzione per la protezione dati di livello aziendale. Ecco dunque la soluzione Data Protection Manager (DPM) 2007 SP1. La sua uscita è prevista per la fine del 2008 e DPM SP1 supporterà Hyper-V e alcune straordinarie funzionalità:

• Un'unica console di gestione per tutti gli host e i guest Hyper-V.
• Protezione dei dati continua che distanzia gli snapshot VSS ad intervalli fino a 15 minuti evidenziando solamente i bit modificati nel processo.
• Abilitazione per i cluster Hyper-V che consente al backup di seguire la macchina virtuale ma mano che questa si sposta tra i nodi cluster.

•Server DPM per la replica di server DPM.

• Supporto per disco e nastro (da disco a disco, da disco a nastro o da disco o disco a nastro).
• Funzionalità di backup e di ripristino per l'intera gamma di dati compresi host e guest Hyper-V; backup VSS senza agente di guest in esecuzione; supporto del ripristino di singole macchine virtuali; dati cluster di failover e migliori funzionalità specifiche delle applicazioni per SQL Server, Exchange, SharePoint, Hyper-V e Virtual Server.
• Script eseguiti precedentemente e successivamente al backup.

Se al momento si utilizza una soluzione di backup di terzi si consiglia di controllare la disponibilità di aggiornamenti per l'applicazione; la maggior parte dei fornitori si sta impegnando al massimo per lanciare sul mercato soluzioni Hyper-V basate su host.

Backup tramite script

WSB contiene un'interfaccia della riga di comando, WBadmin.exe, nonché una serie di cmdlet Windows PowerShell da utilizzare nell'esecuzione di script. Quando si utilizzano questi ultimi, valgono le stesse regole di backup illustrate precedentemente, oltre alla necessità di registrare manualmente il writer VSS Hyper-V nel registro.

La Figura 7 mostra alcuni comandi WBAdmin. Per la documentazione WBAdmin completa vedere go.microsoft.com/fwlink/?LinkId=124380. Come si può notare, WBAdmin non contiene alcuna funzione per la configurazione dei criteri di backup, ma è disponibile uno snap-in Windows PowerShell per la gestione di queste impostazioni. È possibile verificare se questo snap-in è registrato con il seguente comando:

Get-PSSnapin -Registered

Figura 7 Comandi WBAdmin

Comandi WBAdmin	Descrizione
ENABLE BACKUP	Attivare o modifica un backup quotidiano pianificato.
DISABLE BACKUP	Disattiva l'esecuzione di backup quotidiani pianificati.
START BACKUP	Esegue un backup.
STOP JOB	Interrompe l'esecuzione del backup o del ripristino.
GET VERSIONS	Elenca i dettagli dei backup recuperabili da una specifica posizione.
GET ITEMS	Elenca gli elementi contenuti nel backup.
START RECOVERY	Esegue un ripristino.
GET STATUS	Riferisce lo stato del lavoro in esecuzione.
GET DISKS	Elenca i dischetti attualmente in linea.
START SYSTEMSTATERECOVERY	Esegue un ripristino dello stato del sistema.
START SYSTEMSTATEBACKUP	Esegue un backup dello stato del sistema.
DELETE SYSTEMSTATEBACKUP	Cancella il/i backup dello stato del sistema.

È possibile utilizzare quanto segue per caricare lo snap-in Windows.ServerBackup:

Add-PSSnapin windows.serverBackup 

Una volta caricato, è possibile accedere ai cmdlet di Windows PowerShell per WSB come illustrato nella Figura 8. Per una descrizione dettagliata di ciascun cmdlet eseguire questo comando:

Get-Command -PSSnapin windows.serverBackup | select name | get-help –full

Figura 8 Cmdlet di Windows Server Backup

Cmdlet	Descrizione
Add-WBBackupTarget	Aggiunge una destinazione di backup ai criteri di backup.
Add-WBVolume	Aggiunge un volume ai criteri di backup.
Get-WBBackupTarget	Ottiene destinazioni di backup da un criterio.
Get-WBDisk	Ottiene tutti i dischi.
Get-WBPolicy	Ottiene i criteri di backup correnti.
Get-WBSchedule	Ottiene la pianificazione dei backup prevista dai criteri.
Get-WBSummary	Ottiene la cronologia e il riepilogo dei backup.
Get-WBVolume	Ottiene tutti i volumi.
New-WBBackupTarget	Crea una nuova destinazione di backup.
New-WBPolicy	Crea un nuovo criterio vuoto.
Remove-WBBackupTarget	Rimuove una destinazione di backup dai criteri.
Remove-WBPolicy	Elimina i criteri di backup.
Remove-WBVolume	Rimuove un volume dai criteri.
Set-WBPolicy	Salva l'oggetto WBPolicy per creare un backup pianificato.
Set-WBSchedule	Imposta la pianificazione secondo criteri di backup.

Esiste un'altra utilità incorporata in Windows Server 2008 che può utilizzare il writer VSS Hyper-V e che conferisce alle opzioni di scripting una maggiore flessibilità. DiskShadow.exe consente di creare una copia shadow e di installarla come un'unità; ciò permette agli amministratori di eseguire un backup più selettivo rispetto a quello possibile con WSB. È importante ricordare che DiskShadow non accetta l'input della pipeline di Windows PowerShell; richiede, invece, che i comandi vengano impartiti mediante uno script. Il risultato potrebbe essere simile a quanto indicato di seguito:

Delete Shadows Volume C:
Set Context Persistent
Begin Backup 
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow 
Create
End Backup
Expose %MyShadow% X: 
Exit

Questo script cancella dapprima qualsiasi copia shadow esistente nell'unità C: e, successivamente, garantisce che la copia shadow verrà mantenuta dopo l'esecuzione di DiskShadow, infine, crea un blocco transazionale. Se uno dei passaggi non riesce, l'intero processo fallisce. In questo blocco, DiskShadow verifica che il writer per Hyper-V sia caricato e aggiunge l'unità C: all'elenco di unità da sottoporre a backup.

L'unità C: riceve un GUID per l'identificazione e questo GUID viene memorizzato in una variabile di ambiente denominata "MyShadow". Una volta completata questa operazione, viene creata la copia shadow.

Il backup è esposto come unità X: utilizzando la variabile di ambiente. con i dati su X: è possibile effettuare diverse operazioni, poi è possibile eseguire nuovamente DiskShadow utilizzando il comando Unexpose X: per rimuovere l'unità.

Si noti che il ripristino delle macchine virtuali Hyper-V sottoposte a backup con DiskShadow è al momento un processo manuale (la macchina virtuale deve essere creata di nuovo, gli snapshot non vengono conservati e così via). Sebbene ciò presenti alcuni ovvi svantaggi, i dati sono protetti.

Il ripristino di emergenza può essere un processo difficile e apparentemente interminabile. Tuttavia, la virtualizzazione server apre la strada a nuove possibilità, grazie alle tecnologie e al risultante punto di ingresso a basso costo. Microsoft fornisce non solo la virtualizzazione ma un intero ecosistema. La piattaforma di virtualizzazione server e la famiglia System Center offrono soluzioni più olistiche alle problematiche sempre più complesse che le organizzazioni si trovano ad affrontare, compreso il ripristino di emergenza.

Colgo l'occasione per ringraziare James O'Neill per il prezioso contributo apportato a questo articolo.

Adam Fazio ha iniziato a lavorare per Microsoft Consulting Services più di 2 anni fa e ora si occupa della divisione Public Sector negli Stati Uniti. Lavora nel settore IT da più di 10 anni e ha partecipato a diversi progetti di infrastrutture e datacenter per Fortune 100s fino agli start-ups di Internet. Attualmente, è il responsabile delle escalation tecniche per il programma globale relativo alla distribuzione rapida della virtualizzazione di Microsoft.