VM moved to new vCenter

[christiankelly]

I’m currently running on vCenter 5.0 with a dozen ESXi 5 hosts in a cluster. Veeam is pointed at the vCenter and is backing up 100+ VMs using reverse incremental. Rather than upgrading to vCenter 5.5 my plan is to install a new vCenter server and reattach the ESXi hosts to it.

I would add the new vCenter server into Veeam, but is there any way that Veeam wouldn’t have to rebaseline all the servers and just pick up with CBT? I’m thinking because it’s a new vCenter server it may not be able to, but I’m hoping there’s a way.

I’m open to any suggestions.

Thanks,

[Vitaliy S.]

Hi Christian,

CBT cannot be picked up because this data is stored within the vCenter Server. Once you migrate all VMs to the new vCenter Server, you will have to map your new jobs to existing backup files. See this thread for further reading.

Thanks!

[christiankelly]

So the way I have my jobs setup is by folders. (6 jobs) So would I just change the current jobs to map the same folders (which contain multiple VMs) on the new server and remap? Or would I create new jobs?

Thanks,

[foggy]

You will need to either re-add objects into jobs or create new jobs and map them to existing backup files in the repository.

[xu9j4]

Unfortunately I have a problem with an existing physical vCenter server, there are some backups of it available but no local IT to assist with recovery etc.

As the historical performance data is of no importance in this situation, if I were to deploy a new vCenter instance (was going to use the vCenter Server appliance) is there going to be any knock on effect on the existing Veeam v7.0 R2 backups that are covering this cluster? Will the VM ids change and break the existing jobs etc? Veeam backup, proxies and repositories are all on separate hardware to the problem server that is running vCenter so that's not a problem.

I am keen to just get the backup running again as soon as possible, hopefully without having to start the backup chain(s) again.

Thanks

[foggy]

Mike, yes VM IDs will change, please see this thread for details on the effect this change has on your backup jobs. Thanks.

[cstemaly]

I'm building an entirely new vCenter server. My hosts are all the same (5.0 ESXi, btw).

Aside from removing and connecting to the new vCenter server in the Backup Infrastructure, and then going through each of my hosts to re-authenticate, is there anything else I should do to make sure the transition goes smoothly from the Veeam Backup and Replication standpoint? I'm on Veeam 7 patch 3.

[dellock6]

If you are going to move VMs to another vCenter server and re-join ESXi servers to the new vCenter, chances are your VMs will get new and different MorefIDs, so they will not be recognized by Veeam, but instead seen as new. You would probably have to remap VMs in every job if they are registered as single VMs, or re-run backups if you are using dynamic containers like datastores, folders or resource pools.

[peabitty]

We have been moving more customers to the VCSA rather than the Windows-based VCenter server. One of the issues we run into is the backups and replicas in Veeam need to run full jobs for each VM because their MoRef ID has changed. We manually add in the "new" vms to the jobs and then map the backups and replicas to existing VMs and backup files. I'd like to see a wizard or tool to migrate over the VMs to a new VCenter and map the old MoRef IDs to the new ones. That way a full backup and replica is not needed with the new VCenter server.

[Vitaliy S.]

Hello Matt,

When you use mapping feature full job pass is not performed, job transfers incremental changes only after scanning the entire image of the source and the target VMs.

Thanks for the feedback and your feature request!

[VladV]

From my experience, when migrating the VMs from one vCenter to the other, Veeam treats the VMs as being different. If, for example, you have a backup job named Backup1 with a VM named VM1 on vCenter1, when you migrate it to vCenter2 and map the job to the migrated VM then Veeam will make a full backup of it and the job will have two VMs named VM1 under the job named Backup1 in the Backups>Disk section. Your old backup will have the deleted vm retention policy and the migrated one will continue with the normal retention policy.

It is not possible (again, from my experience with a previous migration from an old vCenter 5.1 to a new vCenter on 5.5) to map the backup and continue the backup chain because even if they are the same VM, Veeam identifies them by their unique ID. Thus you will have a backup job containing the old VM (pre-migration) and the new VM (after migration).

[foggy]

Correct, as it is described above, it depends on the backup mode used.

[lando_uk]

Just resurrecting this topic.

Im also planning to move hosts from old 5.0 VCA (broken) to new 5.5 VCA. I understand the VM's will create all new entries in the jobs, this is ok with me and I'll tidy up after.

My question is, will the new VM's with their new IDs double my repository storage requirement or will the inline deduplication with the old ID's work fine and my jobs wont double is size? I dont have capacity to hold double everything for the duration of the retention policy.

Thanks.

[veremin]

Deduplication exists within one restore point, not entire job. That's being said, there is no deduplication between previously and newly created restore points.

There will be new full backups performed for VMs with new MorefIDs. If you want to avoid this, then, disable existing jobs, finish migration process and open a ticket with our support team; they should be able to help.

Thanks.

[Vitaliy S.]

What backup mode are you using? Reversed or Forward incremental? Also what is your repository, regular disks or a dedupe device?

[lando_uk]

What backup mode are you using? Reversed or Forward incremental? Also what is your repository, regular disks or a dedupe device?

Incremental with synthetic fulls, plus transforms into rollbacks.

Repository is regular disks, NL-SAS, RAID6.

finish migration process and open a ticket with our support team; they should be able to help.

So are you saying if I do the host migration, support will be able to sort of the mess with the MorefIDs?

Trouble is, support aren't exactly quick to respond, could I pre-arrange the webex in advance so they are ready to sort it out at a specified time?

[foggy]

Incremental with synthetic fulls, plus transforms into rollbacks.

In this case first increment after the ID change will have size comparable to the full (as there's no deduplication between different restore points).

Trouble is, support aren't exactly quick to respond, could I pre-arrange the webex in advance so they are ready to sort it out at a specified time?

I assume this is possible, you can check with them directly.

[lando_uk]

In this case first increment after the ID change will have size comparable to the full (as there's no deduplication between different restore points).

So our jobs are set to a synthetic full on a friday night. As an example, on job1, our current vbk is 3.3TB, the first increment after the ID change will also be 3.3TB, so will the synthetic full transfer that happens grab the old 3.3TB vbr and then combine the new 3.3TB vib to ultimately create a 6.6TB VBR for that weekend? Or will it merge the old 3.3TB vbr with the new ID vib without increasing the size (dedupe) ?

[Vitaliy S.]

You will not have a 6.6 TB file, as VM data should be deduped within this synthetically created restore point.

[lando_uk]

You will not have a 6.6 TB file, as VM data should be deduped within this synthetically created restore point.

Can I quote you on that? will you buy me a new storage server if you're wrong? Also, thinking about it more, would one of the last rollback now be 3.3TB until its retention policy is met? So I'll have a 3.3TB VBK and a 3.3TB VRB?

I have 4 jobs on this vcenter. So for free space for the fulls to transform, I'd need the equivalent of 4 x VBK that already exist, which is about 8TB. And I presume this friday job could be so slow transforming, it might leak into the middle of next week?

[Vitaliy S.]

I can ask our QC team to perform this experiment if you'd like Actually I have already done that, will update this topic with the results tomorrow.

[lando_uk]

I can ask our QC team to perform this experiment if you'd like Actually I have already done that, will update this topic with the results tomorrow.

Thats great, thanks.

[Vitaliy S.]

Ok, it worked as it is supposed to work, VM data was deduped in the VBK file.

[lando_uk]

Thanks

Will this have any effect on the copy jobs, we have offsite jobs and an exchange weekly archive.

[veremin]

Not, it should not, as the blocks already exist in the target location. Thanks.

[tinto1970]

hi all,

i am evaluating the chance to do a "vcenter consolidation" in my datacenter, in brief managing more ESXi clusters with one vCenter instead of two.

Current situation:

- vCenterOld, 9 hosts in 3 clusters, one Veeam B&R instance called BAK1 connected and taking backups of vCenterOld's VMs
- vCenterA, 4 hosts in 1 cluster, one Veeam B&R instance called BAKA1 connected and taking backups of vCenterA's VMs

desidered situation_

- vCenterA, 13 hosts in 4 clusters, two Veeam B&R (BAK1, BAKA1) connected and taking bakups of same VMs they ware backing up before

If i've read and understood previous posts, after moving the ESXis to vCenterA i should do this no Veeam instance BAK1: for every job i have to delete all the VMs and readd them (the name will be the same).

After doing this, i should not loose the ability to restore previously backed up VMs, and continue backing up them. My doubt is: will the readded VMs have a full backup on first job's run?
I'm worried about disk space problem...

thank you in advance, i hope to have been not too hard to understand...

[veremin]

will the readded VMs have a full backup on first job's run?

Yes, they will, since they will get new MorefIDs and will be considered as new VMs. Thanks.

[bsoosay]

I currently have all my ESX Hosts managed by vCenter 5.1

We have recently built vCenter 5.5 and are moving all the production and development clusters over to the new vCenter server.

How will this affect the jobs in Veeam? I can add the new vCenter 5.5 server to the backup infrastructure on my Veeam server. But what about the individual jobs that are being backed up by datastores?

Do I need to re-add each data store again from the new v-Center 5.5?

[foggy]

Yes, you will have to re-add datastores to the jobs after registering them under new vCenter. Please see above for more details on consequences of this operation.

[lando_uk]

I currently have all my ESX Hosts managed by vCenter 5.1

We have recently built vCenter 5.5 and are moving all the production and development clusters over to the new vCenter server.

How will this affect the jobs in Veeam? I can add the new vCenter 5.5 server to the backup infrastructure on my Veeam server. But what about the individual jobs that are being backed up by datastores?

Do I need to re-add each data store again from the new v-Center 5.5?

When we did the same thing, I created the same folders inside the new vcenter. Then added both old and new folders into the jobs before we moved the hosts.
eg. Job1 had "Management Servers" old and "Management Servers" new. - Just make sure you take note of what VM's are in the old folders before you remove the hosts and then put the VM's back into the same folders on the new vcenter.