You have replicas of the VMs on Server 1 on Server 2, so you could fail over to the replicas and work with them during the server installation.

And what is the best way to initiate this fail over?
First do a fail over of a VM with Veeam Server (from Host no.1 to Host no.2) and then fail overs of the other VMs?

If so, what should I expect or pay special attention to?

Hi @CzkLTPR -

This could get a little tricky because of the Host rebuild. Reason is when you get your Host built and place VMs back on the Host (however you decide to do so), Veeam will see the VMs as ‘new’ because they will have received new MoRef IDs.

After your Host is rebuilt, you’ll need to rescan it in VBR. I did something a little similar within vSphere several mos ago, and had a hard time getting my jobs to run correctly...they’d error out. I essentially had to recreate my jobs because VBR wouldn’t recognize my Hosts, even though I used the same hostname & IP. Support wasn’t able to assist either, aside from recommending to rebuild my jobs ‍♂️

If your Host is seen ok, you should be able to do the following: I assume each VBR server not only backs up VMs on the side it’s on, but does Replication of VMs on the opposite side Host? At least, that’s how it should be set up. After your Host is rebuilt, for your Replication jobs, you can simply do ‘mapping’ to map the VMs to their respective replica on the target ‘datastore’. Your backup jobs may be a bit more tricky as there’s no mapping function. I think both your Replication and Backup jobs will run a Full after they start because of seeing the VMs as ‘new’.

Are your production VMs on the Host you’re going to rebuild on local storage or external storage (SAN, NAS, etc)? And, if on local, are they on separate local storage Volume than what your OS runs on? If your prod VMs are on the same local Volume, you’ll obviously wipe them with your Host rebuild and thus would need to have a recovery plan. This is where your Replication would come into place as Joe suggested above. Migrate your VBR server which is used to replicate the VMs on the rebuild Host to the ‘good’ Host (again, assuming you’re replicating with your ‘opposite’ VBR server), and perform a failover. You can follow the HV User Gude on how to do so. Doing so will keep those prod VMs up and running while you rebuild your Host. Once you get your new Host built, you can then perform a failback operation selecting to do so to a specified location. This will create a VM of the failed over VM on the recovered Host, essentially (at the end of the failback process) making it your main prod VM again. Again, follow the Guide for the process. You’ll then need to finalize failback to get back to where you started. All of this is if you don’t have the same issues I did when replacing my Hosts. 

Just have a recovery plan in place to recover any VMs you may wipe in the process of your Host rebuild.

Due to having VBR on both servers there is no way to do a Configuration Backup and restore on host 2.  You would need to as stated failover the replicas to host 2 and recreate any backup jobs on host 2 that might be on host 1.  Once host 1 is rebuilt you can failback.

Be sure to take a configuration backup of host 1 prior to the rebuild to ensure easy restore.

Do you mean VBR Server on two servers (Hosts)?
VBR Server is only on Host no.1, as a VM. Host no.2 is only added to the VBR Server.

Ah ok I misread the configuration my apologies.  So, you could migrate the VBR server to host 2 since it is a VM and as stated failover the replicas until you rebuild host 1 then reverse things.

Ah ok..I see now. You have VBR on Host 1 and have replicated it as a type of backup on Host 2? So, you use 1 VBR VM to do it all, and it’s on the Host you’re going to rebuild? That in itself is tricky. You can’t really failover to your VBR VM because the VBR server you’d initiate the process with will go down because it’s on the Host you need to rebuild. So what I recommend is do a final backup and replication of everything, then disable all your jobs. Power down the VBR VM then migrate it over to Host 2. Then, power it on & re-enable your jobs and perform a failover like I shared above.

At the very least, you can ping Veeam Support to verify the process you should take to accomplish what you’re wanting to do.

And how best to migrate the VBR Server itself in my case?
As a reminder, it is as a separate VM (on Hyper-V) on Host no.1

Would it therefore be better:
option 1)
using the option in Hyper-V to perform a standard export of VM with VBR Server from Host no.1, and then perform an import of this VM also using the option in Hyper-V into Host no. 2 ?

option 2)
First migrate the VBR Server to Host no.2 (by fresh installing it on Host no.2 and importing to it the Configuration Backup from the VBR Server from Host no.1) as stated in the instructions below:
Migrating Veeam Backup & Replication Server to Another Backup Server,
then uninstall Veeam Backup & Replication from the old backup server after migration.

I would migrate the VM to host 2 - option 1.  Saves you the hassle of installing and restoring the config backup.

Nah..just migrate it using Opt 1. No need to rebuild it.

Hi @CzkLTPR 

Due to the concern raised above by @coolsport00 in his vSphere env. Are your HyperV hosts part of a clusters or SCVMM. If yes, VBR can seamlessly accommodate VM migrations within the cluster or SCVMM, thereby eliminating the need for manual job reconfigurations. But when added as a standalone Hyper-V host, then the job reconfiguration becomes necessary! 

You can do fail over to Host 2, and then , do new replication to host 1 once you finish the reinstallation

In my experience, you can use Veeam failover functions to failover VMs from Host 1 to Host 2 but not the Veeam server.

For the Veeam server, you can shut down the Host 1 Veeam server after running the replica job (make sure it’s up-to-date) and start the replica Veeam server of Host 2 directly.

You can also use Hyper-V import or move functions but not Veeam failover to move the Veeam server.

Option3, get a physical host, export backup config, import it on a new physical Veeam server