Nei sistemi VMware oramai si sono affermati i backup di tipo image-based, ovvero quelli che prevedono il salvataggio dei blocchi dei file disco VMDK della virtual machine, piuttosto che salvare i files contenuti nel Guest OS attraverso agenti. Attraverso l’uso di CBT, dalla versione 4.0 in avanti è possibile identificare i blocchi modificati rispetto alla precedente esecuzione del backup, ed estrarre unicamente questi. Questo permette l’esecuzione di backup incrementali che occupano pochissimo spazio e riducono i tempi di esecuzione.

Il funzionamento di CBT e la sua interazione col file system del Guest OS pone tuttavia qualche problema nell’ottimizzazione di questi incrementali.
Vediamolo con un esempio: ipotizziamo una Virtual Machine Windows 2008 R2 che agisce come file server. Il disco VMDK è stato formattato in NTFS con un block size di default di 4KB, e contiene migliaia di file. Un utente modifica un file da 12 kb e le modifiche vengono salvate sul disco. Questo file è quindi composto da 3 clusters NTFS, ma a causa della frammentazione del file system, questi tre blocchi potrebbero essere salvati su tre blocchi VMFS differenti:

In questo caso quindi una semplice modifica di 12 KB a un file si traduce in una modifica di 3 MB sui blocchi VMFS del virtual disk. In questi casi, un software di backup classico con un agent a bordo rileverebbe la modifica del singolo file, mentre un backup image-based salverà tutti i 3 MB modificati.

Se da un lato queste problematiche sono insite nel funzionamento di CBT (che per contro offre una miriade di vantaggi…), è possibile ottimizzare questa situazione per limitare il numero di CBT modificati.

Le due attività che potete effettuare sono:

– defrag dei dischi dal sistema operativo guest. Questa operazione riorganizza tutti i clusters all’interno del disco e ottimizza quindi il riempimento dei blocchi CBT, andando ad utilizzarne il numero minimo possibile. Dato che moltissimi blocchi CBT verrebbero interessati da questa attività e marcati come modificati, è bene farlo unicamente prima di un full backup; prima di un incrementale vorrebbe dire avere un backup grande quasi quanto il full.

– sdelete: questo tool cancella i clusters non più utilizzati e li riempie di 0. Oltre ad essere un ottimo strumento per la cancellazione sicura dei files, è ottimo anche per svuotare i blocchi non contenenti più dati e ottimizzare lo spazio disco. E’ assolutamente da NON fare su dischi in Thin Provisioning, dove sdelete finirebbe per riempire tutto lo spazio inizialmente assegnato rendendo il disco thick e facendo quindi perdere i vantaggi del thin.

Schedulare uno script che effettui queste due operazioni prima di un full backup può portare a notevoli miglioramenti in termini di spazio disco occupato e velocità di realizzazione del backup stesso.