Remapping Backup & Replication Jobs after VCSA redeploy

[ysm]

Hi folks,
Not sure if anybody has similar experience in this.
Background
We have two sites, 1 VCSA 6.5e on each site. We have 1 Veeam 9.5u2 server on each site. We have backup job running on 1 site and replication job running on the other. Things are working fine. However, recently we have some odd alert from VCSA and during the diagnosis of the alert, the VMware support told us that our VCSAs were not configured correctly as we are using the default linux hostname, i.e. both VCSAs are having the same name: localhost.localdomain. We are using IP based to connect to them so we did not realize any issue. According to VMware, it might cause issues with the web client after upgrade.
Their resolution for us, is to redeploy both VCSAs as the hostname could not be changed after deployment!
While they are helpful in providing info on the redeployment, it daunt on me that there will be issues with existing Veeam replication and backup jobs once I redeploy the VCSAs.

Question:
As per their advice, I am supposed to backup the database of the vcsa and deploy a new vcsa, restore the db to it and add the datacenter and hosts accordingly.
However, that would mean the new VCSA will be having a new IP, and hostname and probably different SSO as well. The big question now, is that, how do I remap my backup and replication jobs to the two VCSAs after that, so as to ensure I can still use the backup chains. I would imagine that I need to reconfigure the following on the two Veeam servers:
1. the source and destination of the jobs
2. the required credentials for each vcsas
3. map the replicas for each replication job ---> this part will prob be ok, i guess
4. map the vms for each backup job and the backup chain ---> this part I am not sure if it would work

Do feel free to give your thoughts on this. Thanks!

[foggy]

Provided VM IDs will be preserved (in case you preserve the entire VCSA database), you should be fine with suggested steps and mapping the jobs to existing backups/replicas.

[ysm]

hi foggy, thanks for the input. I am thinking of using the backup procedure as outline in https://kb.vmware.com/s/article/2091961, however, we are on VMware 6.5 and as per https://blogs.vmware.com/vsphere/2016/0 ... art-1.html, seems like restoring DB alone for VMware 6 and above alone is not going to cut it.
I guess this is probably the wrong place to ask about VMware. I will probably post it to VMware support.

[foggy]

I will appreciate if you come back to update the thread with their recommendations. Thanks!

[ysm]

Hi foggy, well we have just gone through two rounds of redeploy and the following methods work:
1. Off HA setting in old vcsa (this is to avoid vcsa trying to configure HA while connecting hosts after redeploy)
2. Backup old vcsa database using the kb article 2091961, transfer the backup file to an accessible location
3. Disconnect hosts from old vcsa, shutdown vcsa.
4. Redeploy, for our case, we use new IP
5. sFTP the backup db file to new vcsa (sFTP can be a bit tricky, I still do not know exactly why, but I used a mixture of winscp and filezilla)
6. restore db using restore script from the same kb article. (do note one of the services that need to be stopped has changed name in 6.5, refer the note at the bottom of the KB article, and for me, service-control --stop [service] works for me instead of the service -stop [service])
7. There is a catch here, after restore, you will notice that Update Manager in the webclient is pointing to the old vcsa, which for first time round, we need to call VMware for support.
8. They shared with me the methods but I am not sure if it is appropriate for me to share it here, if anybody needs it and could not get vmware support, perhaps can PM me. Basically involves running a few commands in shell.
9. Reconnect your hosts, reconfigure HA
10. Remap Veeam backup jobs. For vcsa being the source, will require seeding to match the vm replicas, for backup jobs, mapping backup to the right chain will do the trick
Hope the steps will be helpful to those who will be in my situation in future.
Good luck!

[rschols]

Thank you ysm! Based on your post I did a similar migration.

We used an IP address as hostname/system-id during original deployment of vCenter Server Appliance and this made upgrading to vCenter 6.5 unnecessarily difficult. Instead of working around it and maybe running into trouble again in the future (update to 6.7?) we decided to bite the bullet and redeploy vCenter:
1. Disable all Veeam jobs and wait for existing jobs to complete.
2. Backup old vcsa database using kb 2091961. Easiest way for SCP is to run scp from the commandline on the vcsa appliance and upload to another linux machine
3. Shut down old vcsa
4. Deploy new vcsa of exactly the same version number with same IP, using same deployment type (in our case, integrated PSC)
5. Import old vcsa database using kb 2091961.
6. vCenter now comes up with all ESXi hosts as disconnected. Connect them one by one and give root credentials to do so.
7. In Veeam, navigate to the vCenter server object, right click and edit properties, retype the password and click save.

All Veeam jobs still work as before, incrementals continue as expected, and backup copy jobs, including copy jobs with WAN accellerators, continue as if nothing changed.

[ysm]

hi rschols,
Good to know it works for you too. Don't forget to double check the update manager is pointing to the new server after the database restore.