Feature Request / Design Change

[swilsonbsb]

I'm another customer who is being bitten by the delay of support for new vSphere versions and I have a suggestion for a way to eliminate this issue (as well as some other issues at the same time).

In my time using Veeam, I have been hit a few times by situations that caused me to have to reset my backup history for my VMs because of the way Veeam tracks VMs. For example, if I am backing a VM up daily as part of a job that runs daily and I no longer want to back it up daily, but rather, weekly, I can delete that VM from the daily job and add it to the weekly job. This causes that VM to start over with a fresh full backup and with no history. The old history still exists under the old job of course but it complains about a missing VM every time it runs unless I delete the old backups. Another example is the work-around for unsupported vSphere versions where you use a direct host setup instead of a vCenter setup. Even editing the existing job to remove the vCenter reference and add the host instance causes a full backup and a new chain to start and then I have the same VM listed twice in the backup list.

I can surmise that the reasons for this are tied to the methods of creating internal IDs for VMs, but the VMDK files are identical, and the VM name is identical, and everything about the VM that *I* care about is identical. Only things at the management layer in vSphere or Veeam are different, so why can't it be possible for Veeam to figure this out and tie the old and new VM together regardless of how it was accessed?

(I think there may be some way to link backup data, but it's more of a symbolic link and support has avoided using that feature. If this is a link to an old location, versus moving something to a new location, then that isn't a good solution and is probably why they avoided it.)

If I was able to move a VM from one job to another without starting over, that would be great. I currently use per-VM files and I would think that option would be required to accomplish this and that's fine with me of course. Since each job saves VM files under a folder named for the job, some file moving would be required. Maybe a new UI wizard to move a VM from one job to another would be required. Or maybe I could just move the backup files myself to the new folder location and a rescan would pick up the extra files and link them in.

But where this applies to vSphere version is that if Veeam can identify existing backup data for a VM and tie it together with a new backup when all that has changed is the management layer, then changing from a vCenter based connection to a host based connection shouldn't cause everything to reset and start the backup chains over.

If that was the case, then we could all set up vCenter connections AND have host connections that could be used as a fallback if the vCenter connection fails. Just like the connection method fallback process. Veeam would try to back up a VM named X using the vCenter connection. If that fails, then look for fallback hosts and connect to each host looking for that VM until you find it.

With this logic in place, then if vCenter is upgraded and not supported yet, my backups would just fallback to host based connections automatically and whenever Veeam was updated they would move back to vCenter connections.

I realize this is NOT simple and that there are probably thousands of lines of code and some core underlying logic that prevents this from being a straight forward change... but the ability to identify a VM regardless of the connection method at least has these two benefits. Being able to move a VM to a new job without restarting the chain, and being to switch between vCenter and host connections without having to restart the chain (and being able to do these things automatically).