Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    ottobre 2017
    L M M G V S D
    « gen    
     1
    2345678
    9101112131415
    16171819202122
    23242526272829
    3031  
  • Tag Cloud

Il restore di singole mail in Exchange 2010/2013 usando Windows Server Backup

Scritto da Ivan Salvade' il 4 agosto 2014

Non è facilissimo eseguire il restore di singole mail o singole mailbox, senza usare un software di backup di terze parti, o Data Protection Manager di Microsoft.

Ipotizzando che un certo utente abbia eseguito un “hard-delete” di alcune mail, e quindi non sia più in grado di recuperarle “autonomamente”, dovrà intervenire un amministratore per il recupero delle mail da un backup precedente.

Se non si dispone di software di backup professionali, l’unica alternativa è utilizzare Windows Server Backup (2008 R2 o 2012) del server Exchange.  Purtroppo il suo limite principale è quello di saper restorare solo interi database, e non direttamente singole mailbox o singole mail.

Quindi la strategia generale da seguire è la seguente :

  1. Identificare il backup da utilizzare per il recupero delle mail
  2. Eseguire il restore completo del/dei database su posizione alternativa
  3. Creare il Recovery Database in Exchange
  4. Eseguire il controllo di “corretto stato” del database restorato con Eseutil
  5. Montare il database restorato nel Recovery Database
  6. Utilizzare il comando Restore-Mailbox per ripristinare le mail cancellate
  7. Smontare ed eliminare il Recovery Database

Ecco ora i dettagli delle singole fasi.

Fase 1

Dovremo utilizzare un backup che siamo certi contenga le mail da recuperare.  In molti casi andrà bene quello del giorno prima, in altri casi bisogna opportunamente scegliere backup più vecchi.   Identificare il supporto corretto, ed “agganciarlo” (se già non lo è) al server Exchange (per esempio, potrebbe essere un disco USB o un disco su NAS mappato tramite iSCSI).

Fase 2

Windows Server Backup (quello presente in Windows Server 2008 R2 o Windows Server 2012), esegue il backup di Exchange a livello applicativo e a livello di volume, utilizzando il servizio VSS (Volume Shadow-Copy Service).  Questo significa che il backup sarà perfettamente consistente, grazie alla collaborazione tra Windows Server Backup e l’Exchange VSS Writer.  Però, non è possibile indicare a Windows Server Backup di backuppare solo un certo database o certe mailbox : in fase di backup, andranno selezionati tutti i volumi (interi) dove risiedono i database (.edb) e i logs di Exchange.

Questo si riflette anche nella fase di restore : non è possibile indicare di restorare solo un singolo database, ma verranno restorati tutti i DB contenuti nel backup.   Per le aziende che utilizzano un solo DB, questo non è un problema, ma per quelle che utilizzano più database, questo può rappresentare una grossa perdita di tempo.

Aprire Windows Server backup, e lanciare la procedura di restore.  Selezionare poi la data precisa del backup prescelto, utilizzando il calendario proposto dalla procedura : in grassetto sono evidenziate tutte le date per le quali esiste un backup da restorare (Fig. 1) :

exrest1.JPG      Fig. 1

Quindi si indica come elemento di restore le “Applicazioni” (se non dovesse essere disponibile la selezione, sicuramente il backup non è stato eseguito a regola d’arte e non è disponibile il restore applicativo con consistenza garantita dei database).  Fig. 2 :

exrest2.JPG      Fig. 2

Alla schermata successiva il wizard si accorge della presenza dei database (consistenti) di Exchange, e con il tasto “Visualizza Dettagli” è possibile visualizzarli.  Non è possibile restorare uno solo dei database (questo è uno svantaggio di Windows Server Backup rispetto ai software professionali). Fig. 3 :

exrest3.JPG      Fig. 3

Si devono restorare i database in un percorso alternativo (Fig. 4).  Si consiglia di utilizzare altri dischi interni del server Exchange (oppure provenienti da mappature iSCSI su NAS/SAN), sui quali ci sia sufficiente spazio per ospitare il restore di tutti i database.  Nel percorso utilizzato, dovrà essere successivamente creato il Database di Recupero (vedi passaggi successivi).

exrest4.JPG      Fig. 4

Fase 3

Si deve ora creare il Recovery Database, utilizzando il percorso indicato nella procedura di restore.  Nel Recovery Database verrà montato il database restorato (contenente le mail da recuperare), e da questo verranno estratte le mail necessarie con re-inserimento nel database di produzione (merge).

Per creare il Recovery Database è necessario utilizzare una linea di comando Powershell :

New-MailboxDatabase  -Name “RecoveryDB”  -Server FQDN_server_exchange  -EDBFilePath “X:\RecoveryDB\percorso_originale_file_edb”  -LogFolderPath “X:\Recoverydb\percorso_originale_logs”  -Recovery

Quindi, ipotizzando che il database originale avesse database e logs nei seguenti percorsi :

  • Server : “EXC.Adatum.com”
  • DB : ”F:\DB1\db1.edb”
  • Logs : “G:\LOGS1″

il precedente comando diventa :

New-MailboxDatabase  -Name “RecoveryDB”  -Server VAN-EX1.adatum.com  -EDBFilePath “X:\RecoveryDB\F_\DB1\db1.edb”  -LogFolderPath “X:\RecoveryDB\G_\LOGS1”  -Recovery

Nella seguente Fig. 5, ecco un esempio di esecuzione del suddetto comando, ipotizzando di avere un database iniziale di nome “Accounting” su un Mailbox Server “VAN-EX1.adatum.com”, con database “Accounting.edb” posizionato in “D:\AccountingDB” e i logs relativi posizionati in “C:\AccountingLogs” :

ese1.JPG    Fig. 5  (clicca sulla foto per ingrandirla)

Nella Fig. 5 è chiaramente visibile il warning “This database must be brought into a clean shutdown state before it can be mounted”.  Lo stato di “Clean shutdown” è raggiungibile con la procedura della prossima Fase 4.

Fase 4

Il Database appena restorato potrebbe essere in uno stato “non corretto” (per esempio con alcuni logs non ancora applicati al database).  Questo stato “sporco” non consentirebbe il suo montaggio nel database di recupero.

Bisogna allora utilizzare l’utility “Eseutil” per controllare lo stato ed eventualmente riparare il database.

La sintassi Eseutil per il controllo del database è il seguente (posizionare il prompt dei comandi nel preciso percorso dove risiede il database) :

Eseutil /mh  nome_database.edb 

In Fig. 6 è riportata l’esecuzione del suddetto comando sul database “Accounting.edb” appena restorato, con l’indicazione di “Dirty Shutdown” (a causa del log 39 mancante, in questo esempio) :

ese2.JPG     Fig.6  (clicca sulla foto per ingrandirla)

La sintassi di Eseutil per la riparazione del database (Soft Recovery) in caso di “Dirty Shutdown” è il seguente (posizionare il prompt dei comandi nel preciso percorso dove risiede il database) :

Eseutil /R Exx /i /d /l:percorso_dove_risiedono_i_Logs (Exx può essere E00, E01, E02, E03….  prefisso dei logs del database interessato)

In Fig. 7 ecco l’esecuzione del suddetto comando, ipotizzando che i logs si trovino nel percorso “C:\AccountingLogs”, e quindi indicando tale percorso al comando con il parametro “/l”.  In caso di database e logs nello stesso percorso, tale parametro poteva essere omesso :

ese3.JPG     Fig. 7  (clicca sulla foto per ingrandirla)

In Fig. 8 è stato rieseguito il comando “Eseutil /mh” per confermare la correzione dello stato in “Clean Shutdown” :

ese4.JPG     Fig. 8  (clicca sulla foto per ingrandirla)

Fase 5

Si monta ora il database restorato nel Database di Recupero.  Il comando powershell per l’operazione è il seguente :

Mount-Database “RecoveryDB   (usare il nome del vostro database di recupero)

Nella console grafica di Exchange di Fig. 9, si nota ora il database di recupero correttamente montato :

ese5.JPG     Fig. 9

Fase 6

Ora è necessario identificare, nel database di recupero,  le mail da restorare ed eseguirne il ripristino nel database di produzione.   Anche qui, non esiste un wizard grafico che possa eseguire la procedura, ma siamo costretti a ricorrere a comandi di powershell.

Se si utilizza Exchange 2010 RTM, l’unico comando disponibile sarebbe : Restore-Mailbox

Da Exchange 2010 SP1 in poi, diventa disponibile anche il comando New-MailboxRestoreRequest .   Ufficialmente, sarebbe quest’ultimo il comando da utilizzare, mentre Restore-Mailbox assumerebbe lo stato “deprecato”.

In realtà, Restore-Mailbox è sempre funzionante, ed è dotato della possibilità di estrarre mail dal Recovery Database in base ad intervalli di tempo (per esempio, estrarre e recuperare tutte le mail tra il 10 aprile 2014 e il 10 maggio 2014) : questa operazione non è (stranamente!) nelle capacità del comando New-MailboxRestoreRequest.

Entrambi i comandi hanno comunque parecchi parametri che permettono di localizzare mail all’interno del database di recupero, in base a diverse condizioni impostabili (es. per tipo di elemento, per data, per cartella, per parole contenute nelle mail, ecc.). Consiglio di analizzare tali parametri consultando l’help in linea dei due comandi ai seguenti link :

http://technet.microsoft.com/it-it/library/bb125218(v=exchg.141).aspx

http://technet.microsoft.com/it-it/library/ff829875(v=exchg.141).aspx

Ecco allora un esempio di linea di comando per recuperare mail in base ad intervalli di tempo :

Restore-Mailbox   -Identity nome_mailbox_da_recuperare   -RecoveryDatabase nome_recovery_database   -StartDate 04/10/2014   -EndDate 05/10/2014

Prima di eseguire in produzione il comando precedente, se ne possono testare gli esiti utilizzando il parametro “-ValidateOnly“.  Ecco l’esecuzione in Fig. 10, dove ipotizzo di voler ripristinare le mail tra il 10 aprile e il 10 maggio di un’utenza esemplificativa (tale “Michiyo”) :

ese6.JPG     Fig. 10 (clicca sulla foto per ingrandire)

Se gli esiti della simulazione sono soddisfacenti, si può eseguire il comando in produzione.  L’esempio delle Figg. 11 e 12 esegue il ripristino delle mail dell’utenza Michiyo, comprese tra il 10 aprile e il 10 maggio 2014.  Ricordo che le mail restorate vengono “unite” a quelle già presenti in produzione, che quindi non vengono perse.  E’ attivo per default anche il controllo dei duplicati, in modo che le mail già esistenti in produzione non vengano ripristinate.

ese7.JPG     Fig. 11 (clicca sulla foto per ingrandire)

ese8.JPG     Fig. 12 (clicca sulla foto per ingrandire)

Fase 7

Una volta terminata l’operazione di restore, è possibile smontare ed eliminare il database di recupero.

Smontaggio ed eliminazione possono essere eseguiti con l’unico comando :

Remove-MailboxDatabase   -Identity “RecoveryDB”

Ricordare di eliminare a mano logs e DB dalle cartelle del database di recupero : questo non viene eseguito in automatico.

Buon restore!!!  :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2010, Exchange Server 2013 | Nessun commento »

Cluster Shared Volumes (CSV) : parte 6

Scritto da Ivan Salvade' il 13 giugno 2011

In questa sesta parte dell’articolo su CSV, analizzerò le tecniche per eseguire il backup delle macchine virtuali in un ambiente di Cluster CSV.  Le stesse tecniche sono comunque adatte anche al di fuori dell’ambiente di Cluster.  Ecco i link alle precedenti parti dell’articolo :

Le procedure di backup e restore in ambiente virtuale a volte differiscono dalle medesime procedure in ambiente non virtuale.

Rimanendo in ottica Microsoft, è possibile eseguire il backup di macchine virtuali utilizzando due prodotti : Windows Server Backup (incluso in Windows Server 2008 R2),  System Center Data Protection Manager 2010 (a pagamento).   Ognuno ha le proprie caratteristiche e limitazioni.   Bisogna subito dire che Windows Server Backup non supporta il backup di macchine virtuali in un ambiente di Cluster CSV : quindi l’unica soluzione Microsoft, a questo scopo, è utilizzare System Center Data Protection Manager 2010.

“Host Level Backup” e “Guest Level Backup”

Esistono due generali strategie di backup delle macchine virtuali Hyper-V :

  • “Host level Backup” : è quello eseguito dall’host fisico Hyper-V, utilizzando il software/agent di backup installato sull’host fisico.  Durante il backup le macchine virtuali possono essere accese (Online Backup) o in stato di “spegnimento/stato salvato” (Offline Backup)
  • Guest level Backup” : è quello eseguito direttamente all’interno delle macchine virtuali, tramite un software e/o un agent di backup installato in ogni macchina virtuale.

Tipicamente, alle aziende con un’importante infrastruttura virtuale si consiglia sempre di eseguire entrambi questi tipi di backup, opportunamente configurati e schedulati.

L’Host Backup (soprattutto se di tipo Full) permette di proteggere tutti i dati necessari per rispristinare l’intero server, comprese le macchine virtuali e i loro snapshot (con l’eccezione delle reti virtuali, che dovranno sempre essere documentate a parte, e all’occorrenza ricreate).

Il Guest Backup garantisce un backup a livello file/applicazione all’interno della macchina virtuale. Questo ci permette di avere un controllo più granulare dei dati da backuppare. Per esempio, con un Host Backup posso restorare l’intero server fisico o, al massimo, un’intera macchina virtuale; con un Guest Backup posso restorare anche un singolo file all’interno della macchina virtuale, oppure eseguire il backup di intere applicazioni (es. Exchange o SQL), in modo da poter ripristinare in maniera granulare solo i dati relativi all’applicazione.

Uno svantaggio del Guest Backup è il probabile aumentato costo di licensing/gestione, soprattutto se utilizzo un software di backup Enterprise : dovrò installare l’agent di backup in molte macchine virtuali, mentre se eseguissi solo degli Host Backup, gli agent sarebbero necessari solo sugli host fisici.

Ci sono anche scenari in cui sono obbligato (pur non volendo) ad eseguire dei Guest Backup : per esempio se mi ritrovo nelle casistiche dei punti 8 e 9 della  sezione “Online Backup e Offline Backup”, più avanti in questo articolo.

Tipicamente, per la maggior parte delle aziende una combinazione di Host Backup e Guest Backup rappresenta la soluzione più appropriata, in quanto ci consente velocemente il ripristino completo in caso di grossi disastri (Host Backup) e il ripristino granulare dei dati in caso di disastri minimi o necessità day-by-day (Guest Backup).

L’importanza del  Volume Shadow-Copy Service (VSS)

Il modo più semplice per backuppare una macchina virtuale sarebbe spegnerla, e quindi copiare manualmente (o tramite il software di backup) i files che compongono la macchina virtuale e trasferirli sullo storage di backup (questo sarebbe un backup di tipo “Offline”).   Ma questo, tipicamente, non è accettabile in ambiente di produzione, dove spesso le macchine virtuali contengono applicazioni business-critical, e non possono essere spente.

La soluzione è backuppare la macchina virtuale mentre è “in linea” (backup di tipo “Online”), e questo è possibile con opportune tecniche, che ruotano attorno ad un componente essenziale, il “Microsoft Volume Shadow-Copy Service (VSS)”.

VSS è stato introdotto da Microsoft con la piattaforma Windows Server 2003, e permette di coordinare le azioni necessarie a creare una “fotografia” immediata e consistente dei dati (dove i “dati” possono essere files e cartelle, databases, intere applicazioni o intere macchine virtuali), da utilizzare poi per certi scopi, per esempio il Backup.

Hyper-V fornisce completo supporto VSS per eseguire un backup di macchine virtuali (Windows 2003 o 2008) senza causare tempi morti.  Però è necessario anche un opportuno software di backup.

N.B. : se la macchina virtuale non esegue Windows Server 2003 o 2008, verrà sempre posta in “stato salvato” durante il backup, e quindi ci sarà del downtime.

Nella seguente figura sono rappresentati i componenti dell’infrastruttura VSS :

teoria-vss.jpg

I componenti principali sono :

  • Il VSS Requestor : per esempio il software di backup.  E’ il componente che ha il compito di richiedere l’intervento di VSS per la creazione della fotografia dei dati·
  • Il VSS Provider : tipicamente fornito da Microsoft, si coordina con i VSS Writers delle applicazioni per eseguire il “congelamento” dei dati
  • Il VSS Writer : tipicamente fornito dall’applicazione per la quale si vogliono eseguire le fotografie dei dati.  Per esempio, SQL Server, Exchange Server, il servizio AD DS, il servizio DHCP sono tutti dotati di un VSS Writer, che permette di ottenere fotografie consistenti dei propri dati.  Anche Hyper-V ha un proprio Writer, l’”Hyper-V VSS Writer”, che permette di creare copie puntuali e consistenti delle macchine virtuali, anche se sono accese.

Per avere dei backup integri e consistenti delle macchine virtuali mentre queste sono accese, è necessario che la macchina virtuale esegua un sistema operativo “VSS-compatibile” (per esempio Windows Server 2003 o successivi) e che il software di backup sappia correttamente interagire con il VSS Writer di Hyper-V.   In realtà esistono anche altri piccoli pre-requisiti, che elencherò più avanti in questo articolo.

“Online Backup” e “Offline Backup”

Nella figura precedente, è presente un host fisico dotato di opportuno software di backup, dell’Hyper-V VSS Writer e di opportuno storage su cui posizionare i backup.  Inoltre su di esso sono eseguite due macchine virtuali, una con un sistema operativo VSS-compatibile, l’altra con un sistema operativo non-VSS-compatibile (per es. Windows 2000, Linux, Unix).   Vediamo come funziona il backup online (o il tentativo di farlo :-) …  ) in un caso e nell’altro.

Backup della macchina virtuale con sistema operativo VSS-compatibile

  • Si controlla se la macchina virtuale ha gli Integration Services installati (su Windows Server 2008 e successivi sono installati per default)
  • Si controlla se l’Integration Service “Backup (Volume Snapshot)” è abilitato (di solito lo è per default)
  • Se i due precedenti requisiti sono soddisfatti, la richiesta di snapshot da parte del software di backup dell’host fisico viene proxata all’interno della macchina virtuale, dove l’infrastruttura VSS del sistema operativo virtuale gestisce il “congelamento” momentaneo delle applicazioni : in pratica, tutte le operazioni di scrittura sono inserite in una coda, la fotografia viene eseguita, e poi la coda viene svuotata.
  • Lo Snapshot così ottenuto viene passato all’host fisico, che ne esegue il backup.   In questo modo si riesce a creare un backup senza downtime della macchina virtuale : non sussiste la necessità di salvare la RAM della macchina virtuale su disco, come invece avverrà nel prosssimo esempio.   Questo è un effettivo “Online Backup”.

Backup della macchina virtuale con sistema operativo non-VSS-compatibile

  • Non essendo in partenza soddisfatto il requisito principale (cioè avere un sistema operativo virtuale VSS-compatibile), Hyper-V esegue un “salva stato” della macchina virtuale.  Questo significa che la sua esecuzione è messa in pausa, e il contenuto della memoria della macchina virtuale viene salvato su disco.   Una volta che VSS ha salvato la RAM, viene creato lo snapshot, e la macchina virtuale viene rimessa in esecuzione.
  • Lo Snapshot così ottenuto viene passato al software di backup dell’host fisico, che ne esegue il backup.   In questo modo ho un downtime della macchina virtuale, tipicamente tanto più lungo quanta maggiore è la quantità di RAM assegnata alla macchina virtuale.   Questo è un effettivo “Offline Backup”.

N.B. : viene eseguito un Offine Backup anche se il sistema operativo virtuale è VSS-compatibile, ma gli Integration Services non sono installati nelle macchine virtuali, oppure sono installati ma non è abilitato il “Backup Integration Service”.

Come già accennato, ci sono anche altri pre-requisiti per la perfetta riuscita di un Online Backup.  Per comodità, li riassumo qui :

  1. Il sistema operativo virtuale deve essere VSS-compatibile (Windows Server 2003 o successivi lato server, Windows Vista o successivi lato client; per Windows XP non è supportato l’Online Backup)
  2. Gli “Integration Services” di Hyper-V devono essere installati nelle macchine virtuali (lo sono di default da Windows Server 2008 in poi, vanno installati in Windows Server 2003)
  3. L’Integration Service “Backup (Volume Snapshot)” deve essere attivo (lo è di default, se gli Integration Services sono installati)
  4. Tutti i dischi usati dalla macchina virtuale (e quindi visibili nel sistema operativo virtuale) devono essere dischi di tipo “Basic” e devono essere formattati NTFS.  La presenza di dischi di tipo “Dynamic” o formattati FAT32 obbliga l’esecuzione di un Offline Backup
  5. Il “Volume Shadow Copy Service” (servizio “Copia Shadow del Volume”) non deve essere disabilitato nella console dei servizi, sia dell’host fisico che delle macchine virtuali.  Il tipo di startup “Manuale” è appropriato
  6. Tutti i volumi utilizzati dalla macchina virtuale devono avere il Volume Shadow Copy abilitato e configurato in modo che la posizione di creazione degli snapshot sia il volume stesso (usare il comando “VSSAdmin List ShadowStorage” per un controllo immediato della configurazione).  Per esempio :
    • volume C : Volume Shadow Copy abilitato, e la locazione di storage degli snapshot deve essere C:
    • volume F : Volume Shadow Copy abilitato, e la locazione di storage degli snapshot deve essere F:
    • per attivare Volume Shadow Copy su un certo volume (ad esempio sul Volume F: , con memorizzazione su F: stesso e spazio massimo occupabile di 1 GB), è possibile utilizzare il comando “VSSAdmin Add ShadowStorage /For=F: /On=F: /MaxSize=1000MB“  (”/For” indica il volume per cui si vuole attivare la Shadow Copy, “/On” indica il volume di memorizzazione della Shadow Copy)
  7. Se utilizzo “Windows Server Backup” per eseguire un Online Backup, bisogna aggiungere ad esso il supporto per il VSS Writer dell’Hyper-V, che non è per default registrato con Windows Server Backup.   La KB 958662 spiega la procedura (oppure consultare la sezione opportuna, più avanti in questo articolo)
  8. Le macchine virtuali devono far uso di dischi virtuali (VHD), che possono essere sia di tipo Fixed, che di tipo Dynamically Expanding.  I dischi fisici direttamente collegati alle macchine virtuali (Pass-Through Disks) NON possono invece essere backuppati dall’Hyper-V VSS Writer.  Quindi qualunque software di backup che si appoggia all’Hyper-V VSS Writer non potrà backuppare i Pass-Through Disks.  In questo caso, i dati sul Pass-Through Disk dovranno essere backuppati con una procedura di backup interna alla macchina viruale (Guest Backup).
  9. I dischi presentati via iSCSI al’interno delle macchine virtuali (utilizando quindi un iSCSI Initiator installato all’interno delle macchine virtuali) non saranno inclusi in un Online Backup eseguito dall’host fisico.  Anche in questo caso bisognerà backuppare tali dischi con un Guest Backup

N.B. : relativamente al precedente punto 9, segnalo che l’Online Backup è invece possibile se i dischi iSCSI sono presentati all’host Hyper-V, e utilizzati per posizionare i files VHD delle macchine virtuali.

Host Backup utilizzando Windows Server Backup di Windows Server 2008 R2

Windows Server Backup è gratuito e già integrato nel sistema operativo.  Può essere scelto come software di backup a livello host, ma bisogna tenere conto di alcune sue limitazioni.

Ecco tutte le sue caratteristiche e, sottolineate, le sue limitazioni :

  • E’ in grado di utilizzare i VSS Writers inbox di Windows Server 2008 R2, ed è quindi in grado di eseguire sia un file-level backup che un block-level backup (per esempio l’immagine di un intero disco)
  • E’ in grado di supportare protezione e recupero a livello applicativo, se le applicazioni forniscono un proprio VSS Writer che si registri con Windows Server Backup (es. Exchange Server o Hyper-V stesso)
  • Non supporta i nastri come storage su cui posizionare i backup
  • Non può essere usato per backuppare e restorare macchine virtuali singole : può solo proteggere l’host fisico intero
  • Non può essere utilizzato per backuppare macchine virtuali posizionate sui volumi CSV di un cluster
  • Non è per default registrato con l’Hyper-V VSS Writer.  Per farlo occorre eseguire i seguenti passaggi sull’Host fisico :
    1. Installare la feature “Windows Server Backup” da Server Manager
    2. Aprire Regedit e posizionarsi in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    3. Creare una nuova sottochiave di nome “WindowsServerBackup
    4. Posizionarsi su “WindowsServerBackup” e creare una nuova sottochiave di nome “Application Support
    5. Posizionarsi su “Application Support” e creare una nuova sottochiave di nome “{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}“   (N.B. : le parentesi graffe fanno parte del nome)
    6. Posizionarsi su {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} e creare un nuovo valore stringa di nome “Application Identifier“.   Assegnare alla stringa il valore “Hyper-V
  • In fase di configurazione del backup, per avere un restore corretto di tutte le macchine virtuali e dell’intera applicazione Hyper-V, è necessario selezionare gli interi volumi che contengono files relativi alle macchine virtuali o all’Hyper-V stesso.  Per esempio, se ho una situazione di questo tipo :
    • C:  volume di installazione di Hyper-V
    • D:  volume dove ho posizionato i files VHD delle immagini virtuali
    • E:  volume dove ho posizionato eventuali snapshot delle immagini virtuali
    • F:  volume dove ho posizionato i files di configurazione delle immagini virtuali

devo impostare il backup degli interi volumi C,D,E,F.   Non è consentito selezionare solo le cartelle che contengono i files inerenti le macchine virtuali, ma sempre gli interi volumi, perchè il servizio VSS lavora per intero volume.

Host Backup utilizzando System Center Data Protection Manager 2010

Garantisce sicuramente maggiori possibilità di configurazione di un Host Backup, e risolve praticamente tutte le limitazioni di Windows Server Backup.   Ha un certo costo, necessita di un certo licensing, ed è però una soluzione Enterprise per aziende che hanno bisogno di un software di backup/protezione di una certa qualità.

Ecco le sue caratteristiche sommarie :

  • Permette protezione e recupero dei dati, memorizzandoli sia su dischi che su nastri (questi ultimi non supportati in Windows Server Backup)
  • Esegue Replica, Sincronizzazione, Creazione di Punti di Recupero
  • Si appoggia completamente all’infrastruttura VSS
  • Si può installare solo su Windows Server 2008/2008 R2 a 64 bit,  Standard o Enterprise Edition
  • Necessita dei componenti Powershell 2.0, .NET Framework 3.5 SP1, Windows Installer 4.5, Windows Single Instance Store, oltre ad un’istanza su un SQL Server 2008 SP1 32 o 64 bit, Standard o Enterprise Edition
  • Supporta il restore granulare anche delle singole macchine virtuali (a differenza di Windows Server Backup)
  • Necessita di un agent (Protection Agent) installato su ogni server Hyper-V su cui si vuole attivare la protezione
  • E’ in grado di attivare la protezione degli host Hyper-V anche sotto Failover Cluster
  • E’ in grado di backuppare le macchine virtuali memorizzate in uno storage CSV di un cluster (a differenza di Windows Server Backup)

In un successivo articolo della serie mostrerò le procedure step-by-step per impostare il backup delle macchine virtuali con Windows Server Backup e con Data Protection Manager 2010 (per il supporto CSV).

Nella settima parte di questo articolo, dimostrerò step-by-step le procedure di implementazione di un Failover Cluster Windows Server 2008 R2, con attivazione dell’infrastruttura CSV.

  • Share/Bookmark

Pubblicato in Clustering, Hyper-V, Virtualizzazione, Windows Server 2008 R2 | Nessun commento »

 
Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
Ok