As I look forward to attending the upcoming VSphere 4 – What’s New course, I thought I’d share some thoughts on one of the main issues I hope Vsphere will improve upon, namely backups of VMs.
Often people like to stick to what they know, scared to venture into the unknown. Standard backup methods is one of them and it is now leading to the detriment of traditionalists questioning whether they have too many virtual machines on a single server. Scared because the amount of VMs on their single physical server will equate to longer backup times, the traditionalist workaround is to then limit the number of virtual machines placed on an ESX server, henceforth decreasing the overall objective of virtualization. To make matters worse you then find situations where companies have bought extra physical servers to compensate for the backup requirements of the virtual machines – ludicrous and bizarre as it sounds it is happening in a datacenter near you….
From my own limited dealings with colleagues, customers and fellow seminar-geeks which I’ve come across in my travels it’s still surprising to see how few can vouch for their VMware servers being backed up by VCB. Still content with backup software designed for physical servers, I even met one fellow who claimed he’d been to a site where the customer was running their backup software at the physical level inside the ESX server, something which haunted me with nightmare images similar to that of Freddy Kreuger being in charge of cabling Enterprise Storage Systems. The inevitability of having to do daily full backups is a given as any change in a VM results in a modification of the timestamp of its associated VMDK files. Thus there ends up being little difference between incremental or full backups.
Upon attending the ESX 3.5 course and attaining VCP status nearly two years ago, I was desperate to implement VCB and see how great the results would be. Installing a physical Windows server next to the ESX server and thus giving it access to the storage for the VMFS file systems, it was a straight forward process providing access to both block-based (Fibre Channel and iSCSI) and NFS-based data stores. The server would then act as a proxy server to back up the data stores without the I/O having to go through the ESX server. Fabulous I thought, until I realized I was one of the few who was actually calling for its implementation.
Step forward and we see that as technology progresses so do solutions and it was recently that I came across Continuous data protection (CDP) and near-CDP backup products which are being marketed as deduplication-like software. By installing them on the VM the ability to back up virtual machines as in the same vein as a physical server is now possible. But while this constitutes to an advantageous low CPU and I/O load I’ve yet to come across a software that will recover an entire machine, a problem if your VM is deleted.
Like every optimist I do see one promising possibility for future development - the storage systems themselves of which some are claiming to have VMware-aware near-CDP backup built in. Dell EqualLogic, FalconStor Software Inc. and NetApp are already trumpeting this ability. By having VMDKs stored directly on their storage, a tool designed for VMware allows you to tell the system when to run a back up of VMware. Similar to VCB, VMware performs a snapshot which then triggers the storage system to perform its snapshot of the VMware snapshot. By replicating that backup to another box you then end up with your backup, with minimal CPU load on the ESX server and I/O hits on the storage. NetApp has gone one step further with this and uses the VMware tools to do the snapshots and can even dedupe the VMware data including live data.
Surely it’s only a matter of time before the other vendors catch up and do likewise (I give it the usual 6 months.) So as I embark upon my course I look forward to seeing and learning what new strategies are available – I will keep you all posted.
