Backing up vCenter DB with Veeam B&R 6.5

It´s a well known problem that with Veeam Backup & Recovery Replication 6.5, and earlier, backing up the SQL server that hosts the vCenter DB poses a problem. KB1051 VSS for vCenter outlines the issue well, and provides a workaround.

If you experience this problem, you will see entries like this in your Veeam B&R backup logs:

Veeam vCenterDB Backup Error
Veeam vCenterDB Backup Error

The workaround provided by Veeam is to create host VM-Host Affinity Rules, effectively pinning a VM to a given host, and then perform the VM backup through the host rather than through the vCenter.

While this might be a way to work around the failed backup scenario, it effectively limits some of the flexibility you have in a virtualized environment. I want to have my VMs roaming around my datacenter utilizing DRS, and by pinning the VM to a given host that flexibility is reduced for the VMs in question.

I can appreciate why this issue appears, and why the workaround works, but frankly there has to be a better way of doing this. Hopefully this issue will be sorted in the next v7 version of Veeam B&R, as there certainly are ways for Veeam to work around the issue and make this a more seamless experience for the backup administrator.


Why not create a new option in the backup job, where you define that this particular job should run through a host, instead of the vCenter?

If selected, Veeam B&R would query the vCenter for which host the given VM resides on, then connect to the host itself and perform the backup through that?

That way we could work without having to set VM-host Affinity Rules, yet still keep vCenter out of the loop when the actual backup is performed.

Doing such a query is pretty easy,  below is an example using PowerCLI:

[cc lang=”powershell” width=”95%” theme=”blackboard” nowrap=”0″]
Get-VMHost -VM dbserv | fl -Property Name
Name : esx02


This simple query returns the host that the given VM resides on at the given time, why not do something like this inside of Veeam B&R to make sure that vCenter DB backups work, without having to resort to VM-Host Affinity Rules?

Preserve your Veeam B&R Backups Jobs when Moving vCenter

This week I´m working at a client site, upgrading their entire existing vSphere 4.1 infrastructure to vSphere 5.1. The customer engagement also includes upgrading Veeam Backup and Replication 6.0 to 6.5, and usually an isolated upgrade of Veeam B&R is a no-brainer next, next, next, done install.

To complicate things in this particular environment, I also had to migrate the vCenter SQL DB from a local MS SQL Server 2005 Express instance to a full-fledged MS SQL Server 2008 R2 instance.

Of course, it was also decided to move the vCenter installation from a physical server, to a VM in the same operation.

To be able to have an exit path, until the vSphere 4.1 hosts management agents, were reconfigured, a new vCenter VM was created with a new IP-adress and server name.

After the migration from vCenter 4.1 to 5.1, and from physical to virtual was completed, the existing Veeam B&R server was upgraded to the latest 6.5 release.

Now, this is where things started to get a bit interesting with regards to the existing Veeam B&R backup jobs.  As far as it was concerned, the new vCenter was unknown and the old one was no longer anywhere to be found on the network.

If you add the new vCenter to the Veeam B&R server, you will need to either redefine all the existing backup jobs by adding the same VM from the new vCenter to the existing job, and keep the old one around until your retention period has passed (and have it fail on the existing VM object until it´s removed) or you will have to recreate all the jobs pointing to the new vCenter instance and start new “first time backups” for all the VMs.

For some reason you simply can not rename/redefine your vCenter connection inside of the Veeam B&R GUI.

Thankfully there is an easy way to work around this issue, without having to mess about with the Veeam B&R database: Create a DNS alias!

That´s right, the solution was that simple. I created a DNS CNAME  alias pointing the old vCenter network name to the new vCenter network name. After doing that, I had to re-enter the credentials for the vCenter connection in Veeam B&R to force a reconnect, and all of a sudden all existing backups jobs where present again and working as intended.

The reason this works, is that when you change the vCenter name and/or IP address (or even move it to a new server) it does not change the VM identification number (vmid) or Managed Object Reference (MoRef), in essence the VMs stay the same and Veeam B&R can continue managing them as before.

Now, can we please get an option to update the registered vCenter name in Veeam Backup & Replication v7.0?


Check out Veeam vCenter Migration Utility for a small utility to help you move Veeam B&R jobs after replacing your vCenter.

vCenter Operations Manager and vCenter Deployment Dependency

In order to be able to deploy vCenter Operations Manager, the ESXi host it is deployed to needs to be managed by a vCenter. At first glance, that seems like a fair and pretty straight forward requirement, right? But, is it?

While I can see the need for a vCenter in the environment that vCenter Operations Manager is supposed to monitor, I don´t understand why the host you want to deploy the vApp on has to be managed by a vCenter instance as well?

I encountered this exact scenario at a client site today; What do you do if you want to deploy vCenter Operations Manager on a standalone ESXi host, and have it monitor a production vSphere environment, which has a running vCenter installation?

The vCenter Operations Manager 5 Deployment and Configuration Guide  clearly states that in order to deploy and run the vCenter Operations vApp vCenter Server 4.0 U2 or later is required:

vCenter Server and ESX Requirements:
The vCenter Operations Manager vApp requires the following vSphere environment.
vCenter Operations Manager is compatible with:

  • System that serves as the target of data collection: VMware vCenter Server 4.0 U2 or later
  • System running the vApp: VMware vCenter Server 4.0 U2 or later
  • Host running the vApp: ESX/ESXi 4.0 or higher

And in the Deploy the vCenter Operations Manager vApp section of the same document:

  • Do not deploy vCenter Operations from an ESX host. Deploy only from vCenter Server.

The reason why the client wanted to deploy vCenter Operations on a standalone, unmanaged host, was pretty simple; They are experiencing some rather serious performance issues, and wanted to use vCenter Operations Manager to help identify the bottlenecks and document them, but did not want vCenter Operations Manager itself to influence the performance of the production cluster(s).

I was able to “work around” the issue by temporarily setting up a vCSA, in trial mode, register the ESXi host, deploy the vCenter Operations Manager vApp to the new vCSA, configure it and then subsequently shut it down again. In fact, there is even an option in the configuration to not monitor the vCenter instance it´s deployed on, so someone else must have had some mildly similar thoughts at one point.

While this will work, its not ideal having to go through loops like this to deploy a management solution. I´ll happily admit that this is a fringe case, and not the most common deployment scenario, but I would still like to see VMware do something about the vCenter requirement for the host the vApp is deployed on.

Requiring vCenter for the hosts and cluster it´s monitoring is fine, and expected, but why does the host it´s deployed on require it?