Nei precedenti post, ho spiegato come configurare e utilizzare Veeam Explorer for SAN Snapshots per creare snapshot di tipo san-based per le vostre VM e renderle visibili direttamente all’interno di Veeam Backup & Replication (VBR).

E’ giunto il momento del post conclusivo: come usare queste snapshots per i restore.

Una delle bellezze di questo strumento è la sua completa integrazione con i backup classici già presenti dalle versioni precedenti. Se fate caso alla console, utilizzerete le stesse procedure dei vostri backup abituali:

Dal punto di vista di VBR, non vi è nulla di diverso da prima, e questo post potrebbe finire qui 🙂

Non di meno, è interessante vedere cosa accade dietro le quinte quando invocate ad esempio un Instant VM recovery.

Quando avviano un restore, vi viene chiesto per prima cosa il punto di ripristino da cui iniziare. Nel caso di VESS, i restore point corrispondono alle snapshots disponibili:

Dato che Instant VM Recovery avvia la VM ripristinata direttamente su un server ESXi, la procedura chiede alcuni parametri specifici di vSphere:

Quando Instant VM recovery è finalmente avviato, ci sono molti punti di vista da cui possiamo osservare ciò che è successo. Per prima cosa, la console di Veeam:

Da questo log possiamo comprendere in dettaglio come funziona l’intero processo:

– Veeam individua la snapshot richiesta
– creare un volume smart clone (in breve, un clone della snapshot che può essere nuovamente pubblicato come una vera e propria LUN agli iscsi initiator)
– crea un nuovo nome per il target iscsi (iqn)
– invoca un rescan sul server ESXi in modo che possa trovare e montare la nuova LUN (ricordatevi che è un clone del datastore VMFS originario, quindi è già formattato con un filesystem che ESXi comprende, e che deve solo essere rifirmato)
– registra la VM contenuta nella nuova LUN in modo che possa essere avviata da ESXi

Potete ottenere altri dettagli dalla console di LeftHand:

Qui potete osservare (li ho evidenziati) la snapshot originale (in basso a sinistra), il volume smartclone (in alto a sinistra) e il suo indirizzo iqn (destra). La LUN possiede le stesse identiche carattristiche del suo padre: 120 Gb, i miei tre server ESXi correttamente indicati nella access list, ma nonostante tutto occupa solo 1 Gb di spazio, ovvero la dimensione della snapshot. Questa è una grande cosa di LeftHand: il volume smartclone possiede la stessa dimensione della snapshot da cui proviene, e non la dimensione della LUN padre. In questo modo si possono effettuare operazioni di clone numerose senza consumare eccessivamente lo spazio disco sullo storage.

Finalmente, possiamo osservare cosa accade dentro vSphere:

Le attività nei Recent Taks corrispondono a quanto descritto prima. Il risultato finale è avere la VM denominata fileserver_restore elencata nella lista del cluster, e come potete vedere il suo disco vmdk è contenuto nel datastore denomicato snap-2a378c60-vsa-snap-01, ovvero il volume smartclone.

Ma quanto è bello!

Quando avete finito il ripristino della VM (ma la stessa procedura vale anche per i file level restore o di oggetti exchange…) potete semplicemente arrestare la pubblicazione della Instant VM, e tutte le attività descritte prima verranno eseguite invertite per riportare il sistema allo stato precedente:

Nel frattempo, le snapshots schedulate sullo storage LeftHand stanno proseguendo in base alla loro schedulazione, in modo che  nessun nuovo dato viene perso se stiamo solo ripristinando alcuni files.

Questo post conclude la mia serie su Veeam VESS, spero vi siano piaciuti i post, e che adesso sappiate cosa è e come si usa questa stupenda funzione.