If you have backed up a virtual machine into a smart cache, and you happen to have the granular recovery extension installed, you can restore individual files from the VMDK very quickly. The end-to-end time to restore a file from a VMDK backup is not that different to restoring a file from a filesystem backup, actually. That is because instead of having to restore the whole VMDK file to a spooling location, the smart cache is essentially an already restored version, and it's just a matter of mounting it and browsing through it.
Starting in version 9, the granular recovery extension only works with VMware's web interface (the flash version). I spent a painful morning chasing up why the VMware Granular Recovery Extension comes up only in the "Available Plug-ins" section of the Vsphere Plug-in Manager with a status of "No client side download is needed for this plug-in". The answer is, it's like the VR Management plug-in: it only supports the web interface, not the vSphere client.
The smart cache device does no deduplication. VEAgent backups can't do in-line compression -- nor would it make sense here anyway -- so the amount of disk space required is exactly the same as the space required for the original VMDKs that you are backing up. Actually, it you want to keep a few days' worth, then you could well be looking at several times as much disk space required for your backups as for the originals. The client I'm doing this for has no Linux servers, otherwise I would have suggested putting the smart cache onto a BTRFS filesystem!
What this means is that you will probably pair the smart cache backup with an object copy job a few days later. Backup to the smart cache now, keep 2-3 copies in smart cache and then copy the oldest backup to a deduplication store where you can store it for a month or longer on disk, or possibly longer on tape.
Note that the default block size for the smart cache device is 1024Kb, which is larger than the defaults for (say) StoreOnce or most tape drives. This means that unless you change this (either by making the smart cache block size smaller, or the other device larger) that you won't be able to do any kind of object copy. Instead you will get errors like this:
[Major] No write device with suitable block size found.
If you don't have licenses for the VMware granular recovery extensions, then don't bother: just use a StoreOnce software device and save yourself a few TB of disk space.
Also, I would recommend bench-marking your VEAgent backups against a filesystem backup. You can create bootable disaster recovery images from filesystem backups (providing most of the advantages of a VMDK-level backup) and quite often the performance is comparable to (or sometimes better than) a VMware snapshot backup. Since filesystem backups can go to a StoreOnce store, it's much more space efficient than the combination of VEAgent + smart cache, and you can (obviously) restore individual files.
Greg Baker is an independent consultant who happens to do a lot of work on HP DataProtector. He is the author of the only published book on HP Data Protector (http://x.ifost.org.au/dp-book). He works with HP and HP partner companies to solve the hardest big-data problems (especially around backup). See more at IFOST's DataProtector pages at http://www.ifost.org.au/dataprotector
Post a Comment