Change to new vCenter

[Marcus1414]

I've VBR v10 and configured to backup existing VMs inside vCenter 6.0. I need to upgrade the vCenter by installing a new vCenter 6.7 and move my ESXi hosts to this vCenter. The hostname and IP will be different.

I am thinking to perform the following and I have also tested in my lab environment but when I check the backup files, it seems that the job did a full backup instead of incremental even though I have map the backups.

• Add new vCenter 6.7 into VBR

• Edit backup job to remove existing VM and add the VM under new vCenter 6.7

• From Storage, I map the job to existing backup files

• Run the job manually

When navigating to Files, I can see the latest file created was VBK instead of VIB. May I know how should I reconfigure it so that it won't take full backup again?

[HannesK]

Hello,
for a completely new VCenter, the behavior you can see is correct. See explanation and workarounds here

For upgrade (which is most common), the MoRefID stays the same. So no full backup would be created in the "normal" case.

Best regards,
Hannes

[micoolpaul]

Also, just to add: it’s only your first backup that’ll be a full, then it will go back to your usual full/incremental schedule. Due to the new vCenter giving the VMs new IDs it believes they are different VMs, therefore needs to have a full backup first, it won’t be creating full backups forever more, but it needs a full backup before it can make incrementals

[jordanl17]

So, like many will be doing soon, I've installed a new Vcenter 7.0 server and moved a host to it. then learned this would require a full backup. kind of sucks, but I'm ok with that. BUT my only question is; do Copy jobs become full too? (please no!). we hardly have the bandwidth to handle it.
steps I followed; added new vcenter to Veeam, added existing esxi host to new vcenter, edited veeam job removed VMs, and readded VMs (from new vcenter). right clicked on job and clicked Start. it's running right now.

[micoolpaul]

Hi Jordan,

You should be performing an upgrade which although it deploys a new VCSA, it will pull everything from your old vCenter server, it will adopt its old IP Address and hostname, and most crucially, you won’t need to do another full backup.

If you create a new vCenter and create new full backups, the underlying IDs within its database will be different, so yes, copy jobs would be different. That’s why vCenter upgrading is the preferred path.

[stewsie]

Hi

I thought VMware have removed any support for backups that aren't using the native backup utility in the VCSA Admin console? From this thread it seems like Veeam can still be used to backup vCenter 7.x with no issues. Is this the case?

Thanks

[micoolpaul]

Hi Stewsie, that’s unrelated to this topic

But the key points to know:
It is supported by VMware to perform an image level backup of VCSA v7, but this functionality has now been deprecated by VMware. It will be removed in a future release.
To prepare for this, people are moving to the file-based backup approach.

The most important question around this is no doubt the “why”? And one major contributing reason is that VCSA is using PhotonOS with its own database which needs quiescence for transaction-consistent backups, plus added into the mix is that you’re commonly backing up your VCSA, by communicating to the VCSA itself, as I see it very frequently that the VCSA VM lives within the clusters it manages, so this can complicate things, similarly to Veeam backing up itself, it’s not ideal.

Then finally we have the restore scenarios to consider too:
https://docs.vmware.com/en/VMware-vSphe ... 248E1.html

Full deprecation details here: https://veducate.co.uk/vcenter-7-0-imag ... -versions/

And a great conversation by vNote42 on the Community Hub around this for further reading: https://community.veeam.com/blogs-and-p ... ce-7-0-792

[vmtech123]

I am not a VMware employee, but the image level backups of vCenter are "sortof"

They have you power down, (both sites if you have 2) and snapshot both at the same time. This keeps the databases consistent if you needed to rollback both at once.

However, is there a reason to install a NEW vCenter rather than upgrade? It basically does it all for you when you upgrade. Creates the new VM, and transfers the data. moves the IP's etc.

It sounds like the Veeam advice was good, but I'd put a call in to VMware for a sanity check if you want to install net new vCenter.

Myself, with VMware, SRM, and a bunch of hosts, I thought of doing this to change the subnets of everything without weird outages and an entire new environment. However, I know that I'll need to redo everything in Veeam after migrating the VM's and I don't think it's worth it to double my SAN storage for this.

The copy jobs will be full as it's essentially a new VM/job that needs to be replicated.

You may want to get all your backups started, then just start one replication job at a time and wait.

[jordanl17]

ok, thanks, yeah, 100% I should have upgraded vs install new. I absolutely would have if I had already known about Full backups required. since I've started down this path, I'll keep going. I'm day 1 of probably 2.5 days of the Copy Job. and these VMs count for about 40% of my data. I might use the unsupported workaround method (change the underlying IDs to match new IDs) for the 3 other hosts/VMs I have to move to new vcenter. or I might do a seed drive. actually between seed drive and changing IDs, what method would you use?
thanks!

Hi Jordan,

You should be performing an upgrade which although it deploys a new VCSA, it will pull everything from your old vCenter server, it will adopt its old IP Address and hostname, and most crucially, you won’t need to do another full backup.

If you create a new vCenter and create new full backups, the underlying IDs within its database will be different, so yes, copy jobs would be different. That’s why vCenter upgrading is the preferred path.

[vmtech123]

Right on. You know for next time

I like simple. Just let it re-copy rather than mess around with ID's.

1) You KNOW it's going to work
2) everything is fresh, any issues (not that there were any) would be gone.
3) You can take the time to fix your naming conventions on your copy jobs if you want.
4) You can modify the copy jobs, (add multiple jobs to one copy job etc.)
5) Use the throttle if you are saturating the pipe, if it takes 4 days, who cares. (unless your business is strict about that).

For the last point, it is what it is. It's not your fault and it was caused by the VMware software install. You won't get in trouble for that. To go one step further, if the incremental are going at your main site, they should get copied as well so you won't "lose" any days. the ONLY thing would be if a DR occurred like right now. but I'd say the odds are in your favor, and not much you can do about that.