VM moved to new vCenter

[eltonhsu]

Hi,
I've tried to look through the help pages and forum threads and couldn't find an answer to this, so I'm posting it here. If it's been answered before, please point me the direction.
I have backup jobs created for different VMs on a host when it was standalone but now joined in vCenter. What I've done after the joining was to remove and re-add each VMs in those jobs and save the jobs again.
When the backup jobs run, it appears to be all full backups instead of continuing with the usual incremental backups.

Am I missing something? Or is this normal? Full backup is forced after joining and leaving vCenter? Any possibility to avoid this?

Thanks!

[Vitaliy S.]

Hi Elton,

In your case full backup of the VM is expected, since this VM has changed its ID and now is treated as a new VM by both vCenter Server and therefore by Veeam B&R.

Thanks!

[eltonhsu]

Hi Vitaliy,
Thanks for the direction and quick reply!
So this means even if any existing backed up VM receives a new ID, mapping its previous backup will make VBR treat it as the same VM?
From what I can see, the mapping backups only shows "job" level, not "backup file" level. So, how can I be sure the mapping is done "correctly" at the point where the job is updated? I certainly would not prefer to find out in the morning that all jobs actually ran "full" when "incremental" was expected.

Thanks!

[Vitaliy S.]

So this means even if any existing backed up VM receives a new ID, mapping its previous backup will make VBR treat it as the same VM?

Not exactly, mapping should be used when you, for example, would like to continue your existing backup chain with a new job etc, however if the VM receives new ID, then it will be treated as a new object.

From what I can see, the mapping backups only shows "job" level, not "backup file" level. So, how can I be sure the mapping is done "correctly" at the point where the job is updated? I certainly would not prefer to find out in the morning that all jobs actually ran "full" when "incremental" was expected.

In your case full VM backup will be performed.

[iwik]

Not exactly, mapping should be used when you, for example, would like to continue your existing backup chain with a new job etc, however if the VM receives new ID, then it will be treated as a new object.

Oh this is very sad, that full backup need to be done. I don't have space for two full backups. Whole mapping is then useless. Is there some other solution? I'm migrating from windows vcenter to appliance...

[veremin]

Is there some other solution?

After migration to a new vCenter disable all existing jobs, open a ticket with our support team, and let them correct product db, using the tool discussed in this thread. Thanks.

[guitarfish]

I did a host software upgrade from VMware ESXi 5.5 to 6.0. This host has 5 VMs which are backed up by Veeam B&R 9. After the upgrade, the backup jobs produced the error “The remote certificate is invalid according to the validation procedure.” I edited the backup jobs, clicked through without making any changes, hit Finish. Then the jobs ran, however they did full backups, not incrementals.

When my Backup Copy jobs ran, they didn’t see any changes and nothing was copied. Presumably it viewed the full backup as a different VM. I recreated the Backup Copy jobs, mapping them to the same cloud repository/location as before. The jobs ran but again, full backups are being copied to the cloud, which is very slow. It will take a few days for all this copying to complete.

How does one upgrade an ESXi host while retaining the ability to continue incrementals in the backup chain? I have several more ESXi 5.5 hosts that I need to upgrade to 6.0, and this scenario is a painstaking mess.

[foggy]

Have you re-registered the host in VI during the upgrade procedure?

[guitarfish]

After the upgrade procedure I needed to use the "Reconnect" option in vCenter so it would see the host again. One thing I've noticed since my previous post is that 4 of the 5 VMs on this host did full backups, but one got away with an incremental, and also an incremental to the cloud repository.

[foggy]

So it was an in-place upgrade? It could be something else that could result in moref ID change for these VMs.

[guitarfish]

Yes, an in-place upgrade. I just read this entire thread. First, there seems to be some confusion about what "map backup" does. It doesn't negate the need for a full backup in many cases, although posts in this and other threads I've read sometimes claim it does.

That aside, being forced to run full backups locally for all jobs after a move or upgrade doesn't bother me so much. The real problem is having to copy all these full backups to the cloud. This process will take a week at least, and that includes copying during the workday, which really slows down internet speeds for everyone. I am really disappointed with this limitation.

[foggy]

Full VM data will be read after re-adding the VMs and mapping the job to existing backups. However, you can ask support for assistance in matching the old VM ID's to the new ones in Veeam B&R database to avoid it.

[geofftx]

Has VBR 9 learned to tolerate removing and re-adding a VM from vCenter without losing the backup chain?

In previous versions Veeam relied on MoRefs to identify a VM, and every time you remove and re-add a VM in vCenter the MoRef changes, breaking the backup chain. (Veeam sees it a s new VM.) I see there's now a "Unique Key" field in the bObjects table - any chance this is persisting a VM across vCenter inventory removes/adds and replacing the MoRef as a unique identifier?

Short version - I need a way to preserve backup chains after removing and re-adding a VM in vCenter. I've done it in prior versions by manually updating the DB with the new MoRefs after the re-add, but I've never been comfortable doing it this way.

Geoff

[EugeneK]

Hi Geoff,

I don't believe this behavior changed anyhow, still relies on MoRef ID.

[foggy]

I've done it in prior versions by manually updating the DB with the new MoRefs after the re-add, but I've never been comfortable doing it this way.

Geoff, now you can ask support for assistance in VM ID matching.

[geofftx]

Thanks Foggy, I'll open a ticket and get their help this time.

[brichardson1991_obk]

Hi all,

We've changed one of our vcentres from appliance to windows, same name and ip etc

When going through all the jobs i made sure the jobs correlated to the old job.

When doing a replication should it be doing a full calculation of digests for each hard disk?

[foggy]

Ben, this solely depends on whether VM IDs have changed during vCenter migration (specifically, whether VMs and their replicas were registered in vCenter anew).

[brichardson1991_obk]

Hi Alexander,

The vCenter was setup from scratch, however the VM's and replica's are still in the same places as before and on the same hosts/datastores etc.

[foggy]

On registration in new vCenter VM IDs change resulting in a full VM data read during the next job run (provided VMs were added via vCenter). You can ask support for assistance in matching IDs in Veeam B&R database, though.

[brichardson1991_obk]

I've opened a ticket under : 01802200

[leeg123]

I was planning on upgrading / moving some VMs around between different hosts. In the past, when we did so, i discovered that once the VM is moved into a different host, the internal ID would change, and Veeam would create a new backup (full) for each VM that was moved. Reading though the forum, it seems that veeam has a utility that i can "borrow" that will allow me to edit the backup job, and remap the job to the sane VM / with its new ID, keeping veeam from creating a new backup for that particular VM
Is this something that i can download, or will i need to open an support ticket and request?

thank you

lee

[foggy]

Yes, you need to open a case to get assistance with this. Thanks.

[mingji]

Same situation here, replaced vCenter, VM IDs have changed too. Case # 01815621
Need help T_T

[veremin]

Stop all existing jobs and wait until support team apply the migration utility. Thanks.

[foggy]

Support has issued a dedicated KB with instructions on using the vCenter migration utility, so everybody looking for VM ID matching can do it by themselves (of course, contacting support in case additional assistance is required is not forbidden).

[tntteam]

Hi there,

I'm here to provide feedback and I wish I seen this link to migration utility earlier !!

So we were on windows vcenter 5.1 and migrated to vcsa 6.0 u2
In veeam, here is the steps I followed :

- add new vcenter in infrastructure
- update jobs per jobs : 1) remmember which folders are saved, 2) remove them, 3) re add them using the new vcenter, 4) do the same for exclusion list
- remove old vcenter from inventory

Here you go, it worked, except I lost cbt (or whatever is giving incremental information ) so I ended with an incremental backup (but size of this incremental = size of full) of all our VMs the same night (and ran out of disk space) and backup ended way after backup window.
All in all, this went ok except the lost incremental data, but at least no broken backup chain. Maybe the utility can fix that.

[Morat]

Hi folks,
as per title really, I've just upgraded frm VMWare 5.5 to 6.0 and I'd like to point my existing backup and copy jobs at the new vCSA.
I've read up, but I've only found information for Veeam <8.0
Has there been any change in Veeam or will I have to recreate my backup jobs? (I'm a little low on storage for that to be easy right now).
Thanks!

[foggy]

In case it is a completely new vCenter installation, VM IDs will change and, nothing new with v9, you will need to either perform ID matching or cope with full backups. Please see above for details.

[Carko]

Does the refenced ID Migration tool work in the same way if the VMs were previously added directly via hosts, but now we want to re-add them to Veeam via the vCenter?