Naturally, when there is a new vCenter instance, all the Virtual Machine Managed Object Reference’s (MoRef) change, which makes Veeam Backup & Replication start a new backup/replication chain, since all VMs are treated as new ones. Not ideal by any means, but at least you wouldn’t have to recreate all your jobs.
Veeam has now made a tool available that can map old MoRef’s to new MoRef’s in your backup jobs, in order to keep your incremental chains intact even after replacing your vCenter.
Veeam has been “silently” working on their own global influencer program, and the inaugural list of Veeam Vanguards was published today. I am thrilled to be selected amongst the first 31 people awarded this title, it’s quite an exclusive list!
So what’s up with the name? Well, here is one of the definitions of vanguard I found:
a group of people leading the way in new developments or ideas.
Sounds rather fitting if you ask me, at least if that’s the rationale behind it. One other definition I found was the “the foremost part of an advancing army or naval force”, which does sound kind of scary. Anyhow, I’m glad to be considered and even more happy that I was selected among the first batch.
I recently set up a new Veeam Backup & Replication v8 demo lab, and my intial small job that consisted of two different Linux VMs and one Windows Server 2012 R2 Domain Controller was chugging along nicely. I had one minor from the start though, and that was that file indexing consistently failed for the Windows VM. No big deal, but I thought it was strange at the time. After all, the Linux VMs were indexed just fine.
Fast forward a few days, and all of a sudden Veeam B&R was unable to back up the Windows VM at all, failing with the following error:
18.01.2015 19:48:01 :: Processing Joey Error: Failed to check whether snapshot is in progress (network mode).
RPC function call failed. Function name: [IsSnapshotInProgress]. Target machine: [192.168.5.5].
RPC error:Access is denied.
Nothing had changed in my environment, no patches had been installed, no changes made to the backup job or the credentials used. I even tried deleting the job, this is a demo environment after all, and re-creating it, but with the same end result.
As the Access is denied message clearly states, this had to be related to permissions somehow, but I was using domain administrator credentials (again, this is a lab), so all the required permissions should be in place, and the credentials test in the backup job also checked out just fine. It has also worked fine for 5 or 6 days, so I was a bit baffled.
In the end, I tried changing from using User Principle Name (UPN) connotation of firstname.lastname@example.org in the credentials for the VM, to using Down-Level Logon Name aka domain\administrator and retried the job.
That did the trick, and it also fixed the indexing problems I’ve had since setting up the job in the first place.
So, if your Veeam Backup & Replication jobs fail with access denied messages, and/or can’t index the VM files, check your credentials. They may work, but they might just be entered in the wrong format.