Quick Migration and VBR, Repos Boxes

[evander]

Hi - I have been working on a migration project from one cluster Vsphere v7 to VCF v9 using the Veeam quick migration tool which has largely worked very well.
The two clusters are completely separate, by design, with their own vCenter boxes and so vMotion is not an option.
The VBR box has both old and new vCenter's added under managed servers section.

The quick migration tool has allowed me to keep my backup chains intact which is great. I now need to migrate some Veeam boxes that are not backup source machines but rather target or infrastructure boxes such as proxies, repos and the virtual VBR v12 box itself.

The various Veeam repos are big, between a few TBs and upwards of a couple 45TB each.
My plan is to hopefully detach the host running ESXi v7, reinstall v9, add to new cluster and vCenter and then re-add the VM from the same local datastore (that was not touched during the ESXi install). I have successfully tested this with some test VMs and it seems to work well. But I am wondering if Veeam will have any issues with this plan. Because they are not part of a backup chain, will the Veeam Repo even care that it's now on a new cluster/vCenter as long as the network and DNS name hasent changed?

And then the same for the VBR box itself. Will it break if I do this same plan, because I assume I can't use quick migration to move the VBR box that is processing the quick migration task.

I also have some older hardened linux repos in the mix that are not virtual so will not need migrating but hopefully any changes I propose above won't affect them either.

Thanks,

[Mildur]

Hi Evander

A Veeam backup repository does not care whether it runs on VMware host 1, VMware host 2, a physical machine, or even another hypervisor such as Hyper-V. As long as it is connected to the backup server and the backup files are in the configured file system path, the backup server can work with those backup files. You only need to make sure that the backup files are not deleted or destroyed during the migration.

and the virtual VBR v12 box itself

I would consider a configuration restore to a new VM with VBR v13, instead of migrating the backup server VM. You can deploy a new Windows server, install VBR v13 and restore the configuration. Keep in mind, that both backup server need the same config database (postgresql or mssql) to be able to restore from v12 to v13 directly.

proxies

If you choose to update/migrate to v13, deploy new Veeam Infrastructure Appliances and use them as proxy server. Instead of migration your old Proxy Server over.

What concerns me a bit is that, if I understand correctly, you have all your backup repositories as virtual disks on local datastores of the ESXi hosts, correct? That is against our best practices. An attacker could easily delete the backup repository VM, and all your backups would be gone. But since you have physical Hardened Repositories, that should be ok for your environment.

Best,
Fabian

[evander]

Thanks for the quick reply Fabian.
I am very keen to move to Veeam v13 but dont want to risk doing both projects at the same time. As soon as I have completed this migration and its settled, I plan to do the v13 upgrade.

And yes, you are correct, my repos that are virtual are not ideal but they are on a separate standalone host(s) different from the production cluster but are also secondary backup copies. The primary backups sit on physical hardened repos. However, when I move to v13 I plan to move away from virtual repos altogether and archive these old repos. The old production hosts I am migrating away from will become the new Veeam repos hosts.

Thank you for confirming that moving the current virtual repos wont be affected by my plan, this is good news. For the sake of minimizing risk, can I do the same with my VBR box, simply add to new vCenter from current local datastore on newly upgraded host? My hosts are Dell PowerEdge with separate BOSS disks for ESXi install so if done right, the current capacity datastore is unaffected during install of ESX v9 and worked well during testing. I then browse and add VM from local datastore. This is my plan for all VMs that are not part of a backup chain, which includes test/dev boxes, non-critical boxes and all Veeam repos, VBR etc.