Nel precedente articolo, ho configurato ExaGrid in abbinamento a Veeam per realizzare i backup dei server del mio ambiente di test. Questo “lab” è in realtà un sito di produzione di un cliente, che gentilmente mi ha concesso di usare ExaGrid sui suoi sistemi.
In questo modo, i dati potevano crescere e modificarsi durante i test, dandomi un’esperienza di “vita reale”.
Il Lab
Ricapitoliamo brevemente i server che verranno salvati con Veeam:
Come potete vedere, c’è un discreto quantitativo di dati, guest OS differenti, e differenti versioni di virtual hardware (e quindi differenti comportamenti di CBT).
Questo è lo schema di backup di Veeam:
Dalle 19.00 alle 23.00, tutti i server vengono sottoposti a backup, con incrementali durante la settimana e synthetic full il Sabato notte.
Prima esecuzione di Veaam
Un Sabato, abbiamo effettuato la prima esecuzione di Veeam Backup. Dato che nessun backup precedente era stato eseguito, questa attività ha creato un set di backup full.
Il job denominato “BKP-galileo” ha occupato la maggior parte dell’attività, durando più di 7 ore, oltretutto questo file server è una virtual machine con hardware V4, quindi niente CBT.
Domenica mattina, ExaGrid ha iniziato a deduplicare il set di backup, e anche se non vi era nessun precedente backup da comparare, l’appliance ha usato la compressione e ha guadagnato spazio ugualmente:
Mentre il set di backup era 709 GB, lo spazio effettivo è stato 447 Gb, con un fattore di Deduplica di 1,58:1.
Secondo Giorno
A partire dal secondo giorno, Veeam ha iniziato a fare backup incrementali sfruttando CBT, dove disponibile. La finestra di Backup si è ridotta drammaticamente, e la velocità di processamento dei dischi vmdk disks è stata buona:
Dopo che tutti i backup sono stati completati, Veeam ha salvato sulla Exagrid circa 17 GB di backup incrementali (identificabili come file VIB) provenienti da 9 differenti set di backup:
Sulla ExaGrid, questa nuova occupazione è stata ridotta:
Lo spazio RAW (la quantità che Veeam aveva ritenuto di occupare) è cresciuto da 708.82 a 727.30 Gb (+ 18.48 Gb), mentre lo spazio deduplicato è cresciuto da 447.60 a 456.06 (+ 8.46).
Anche il Deduplication Ratio è cresciuto 1.58 to 1.59.
Dopo due Settimane
Dopo due settimane complete, Veaam e ExaGrid hanno svolto egregiamente i loro compiti:
Da questo report, possiamo trarre alcune conclusioni:
- Lo spazio totale raw occupato da Veeam dopo solo due settimane è già cresciuto oltre lo spazio originario di 2 Tb dell’unità ExaGrid, quindi la deduplica ci ha fatto effettivamente risparmiare spazio
- Come mi è stato detto dal supporto ExaGrid, i backup incrementali non consentono di salvare molto spazio, come possiamo anche notare dal deduplication ratio che non incrementa durante la settimana, anzi peggiora in alcuni giorni. Questo perchè i backup incrementali salvano nuovi dati che ExaGrid non riesce a comparare con nessun vecchio dato già presente
- A ogni sinthetic full backup, il deduplication ratio compie un balzo in avanti sostanziale. Abbiamo usato la policy di retention di default di Veeam di 14 copie, quindi dobbiamo aspettarci valori di deduplica ancora maggiori esendo la retention stessa. Questo fa si che ExaGrid possa essere usata per avere una cronistoria di backup molto maggiore di un semplice NAS.
Questo è lo stato finale dell’ExaGrid dopo due settimane:
ExaGrid ha usato anche parte dello Landing Space per salvare i backup, ma semplicemente attendendo il giorno successivo, ExaGrid è stata capace di recuperare tutto il Landing Space e comprimere tutti i dati nel Retention Space ancora una volta:
Alla fine di questi test, posso dire che le appliance ExaGrid sono una vera innovazione nel mercato dei backup su disco. Hanno una serie di funzioni di altissimo livello combinate con una estrema semplicità di gestione.
Aggiungeteci il supporto a diversi software di backup, la scalabilità grid e la replica remota, e forse ho trovato veramente quella che ho già ribattezzato “all-around ultimate backup appliance”