In the lead-up to EMC VMware's closely followed VMworld conference, many infrastructure vendors are taking advantage of the spotlight to roll out their latest goods. One such announcement from Veeam caught my eye: It will show a new capability called Veeam Explorer for Snapshots that will be released with Veeam Backup and Replication 6.5, due by 2013.
Veeam Explorer for Snapshots extends the same image, file, and application-level restoration capabilities present in Veeam Backup and Replication to SAN-based snapshots. Effectively, this feature will let you use the same tools and interface you might already use to restore from virtual machine backups and replicas to also restore data from SAN-side snapshots. However, in its first appearance, this feature will be compatible with only Hewlett-Packard's LeftHand P4000 line of physical and virtual iSCSI SANs, though Veeam hopes to sign on more storage vendors as time goes on.
[ Also on InfoWorld: Read Matt Prigge's review: HP Virtual SAN Appliance teaches dumb storage new tricks | Sign up for InfoWorld's Data Explosion newsletter for news and updates on how to deal with growing volumes of data in the enterprise. ]
There are a couple of interesting aspects to this announcement. First off, the capabilities Veeam Explorer for Snapshots will offer are undeniably cool and will probably motivate more storage admins to make use of SAN-side snapshot tech. Although the feature doesn't exactly do anything you can't already manage manually on your own, it aims to make very easy what many find to be a complicated and time-consuming task -- a real asset when you're scrambling to pull off a critical restore. However, the announcement of HP as an initial SAN-side partner may also say something about the relentless consolidation that has swept over the storage market over the past few years.
Reducing the effort of SAN snapshots
When they are implemented well by a virtualized storage array, demand-allocated SAN-side snapshots can provide enormously useful restore capabilities. In most modern SAN implementations, SAN snapshots can be taken at will or on a scheduled basis, and they typically have a very minimal impact on storage performance -- unlike the snapshots of yesteryear, which often had enormous write performance penalties associated with them. These snapshots certainly have an associated capacity cost (usually related loosely to amount of write traffic the volume is experiencing), but this cost is offset by the incredibly valuable capability to almost instantaneously roll a volume back in time to when a snapshot was created.
SAN snapshots can be useful in a wide variety of situations. For example, imagine a database-driven application has experienced some form of data corruption that has rendered its database unusable. Without SAN snapshots, your best bet might be to restore a backup of the database, then hope the transaction logs will replay properly and you won't lose very much data. However, simply restoring that data might take hours, especially if it's a large database.
If your luck is really bad, you could find the restored database is still corrupt, then have to restore from an even older backup -- wasting still more time. Worst of all, in most cases, you'll be forced to disrupt your now-defunct production environment to make space for the restores -- potentially destroying any chance you may have to recover additional data.
If you have a comprehensive SAN snapshot schedule set up, you could instantly roll the database back to right before it encountered the corruption with a few mouse clicks and repeat that process as many times as you need to -- all without actually modifying the "known bad" state you've found yourself in. This gives you the ultimate in recovery time versus data corruption, as well as letting you perform whatever degree of forensics you desire on the corrupt dataset.