How does it work?
The way Veeam does backups does not change with this introduction. Veeam still does image-level backups of complete Virtual Machines. This is flexible because it is Guest OS and application agnostic, portable and really simple, because it does not use any application integration using agents. This, of course, is also a major downer: it doesn’t integrate well with rare or home-grown apps. Neither does it backup data twice (once for image-level, once for agent based backups).
Doing image-level backups uses snapshots of live systems. This doesn’t do anything good in the reliability department. Applications aren’t flushed to disk and filesystems aren’t unmounted. There’s really no way of knowing if the backup has succeeded. Veeam asks you “Unless you test every backup, you don’t know… but how can you possibly test every backup?” To add even more complexity into the mix: testing multi-tier applications. How can you verify that a certain service restores correctly? You’d need a mix of different VM’s, all running a part of the service. Testing such a restore is expensive, time-consuming, labor-intensive and frankly, not a reliable method.
So Veeam’s come up with a way to verify the image-level backup you’ve just made. Simply said, it can present the backup (which is deduped and compressed to a file on disk) as a (read-only) NFS datastore to an ESX cluster. The presented backup is seen as a standard VM and can be run in an isolated network bubble. All the pre-requisites (like the network bubble, NFS-server, etc) are automatically handled by Veeam Backup, so user interaction is minimized.
The backup file isn’t changed at all. Changed blocks/data is stored in a temp delta VMDK on a regular datastore. Using custom scripts, the service or application can be verified as working. Because the verify does not actually copy data from backup file to datastore, it is fast. 150GB-Exchange-in-2-minutes-fast.
Recovering data does not need to be performed by the administrator. If an application is restored, a user can access it using a custom URL generated by Veeam. The user logs in using his own credentials and restores his own e-mail or file. The administrator deletes the environment afterwards. Do you see the use-case for patch-testing and creating a shadow-environment for development or auditing.
It makes a cool solution for actually using your DR-site for the verify process. Just replicate the backups to the second site and do the verification there. As Lode Vermeien puts it: “So I can do cross-site backup and verify at my DR site? If so, bye bye SRM.. (for 90% of my customers, who can’t afford SRM in the first place)”. It does in fact differ hugely from SRM, as SureBackup does not require array-based replication.
- Your backupserver becomes a storage server. Verifying multiple virtual machines concurrently puts the backupserver (which doubles as a NFS storage server) under higher load, which might justify bigger hardware for this purpose. By the way, the NFS server is a Veeam-specific implementation, it does not utilize the Windows NFS server feature, but it still does require a server OS.
- Multi-VLAN configurations. Without access to the physical router, how can an isolated multi-tier, multi-VLAN configuration connect to the other VMs?
- If you’re currently verifying a configuration, will a ‘backup everything’ schedule back up these temporary VM’s as well?
- Will it play nicely with VMware HA and DRS?
Join my on the Veeam Forums for a discussion on these points!