Using Veeam with SAN Snapshots

[xadamz23]

I have a few VMs that are very touchy when it comes to losing even a split second of network connectivity. So this becomes a problem when a VM is backed up and the VMware snapshot is removed. I have an idea to address these "touchy" VMs. I will create a san snaphot of the datastore, present that snapped datastore to a host, register the VMs, and back them up with Veeam.

However this wont work because everytime a VM is registered it is given a unique VM ID. And Veeam keeps track of the VMs in it's job based on ID vs. VM name. So that means everyday when I register the VMs from the snapped datastore they will be given new unique VM IDs. Then I would have to somehow update the VMs in the Veeam job, and EVEN after that I suspect that a full Veeam backup would occur instead of an incremental.

Is anyone backing up VMs in this fashion and if so how are you doing it?

[tsightler]

So I've played with this a little, but slightly modified. Instead of registering a VM, which indeed leads to the problem you describe, I created a few dummy VMs with the same name + suffix and then the script would mount the snapshot datastore, attached/detached the disks to these dummy VMs, back them up, detact the VMs, dismount datastore. It was basically a virtual version of a technique we had used for "hot backup" of Oracle databases for years.

The only major problem with this technique, other than being complicated, was no change block tracking, only "snap and scan".

[xadamz23]

That is an interesting solution. Like you said it is a bit complicated and no changed block tracking which is a bummer. On the bright side I don't have a lot of VMs that are so touchy that I would need to back them up this way. Thanks for providing this. I may end up using it.

[tsightler]

Another option which might be easier, you could always configure the backup job to backup a container object (folder or resource pool) and then register the VMs from the snapshot datastore to this container. That way it wouldn't matter if the VM-id's change, but this would lead to a bunch of duplicate VM names in the backup, which might be slightly confusing. Stll, it might be easier than scripting all of the disk attach/detach stuff.

I suppose you could also probably script something to modify the VM-ids directly in the Veeam database using the technique documented here but that's pretty unsupported from the Veeam perspective.

We ended up using the "more complex" solution because it seemed to have the least side effects (loss of CBT wasn't a huge deal for these handful of VMs that were fairly small) and, as stated previously, we already had a script that did a similar thing for another purpose. The script was complex, but not overly so, and reliable after a round or two of debugging.