Skip to main content

Good day all,

Hostnames and IPs are ficticious, just to protect my environment

Case:

N.B. Primary veeam server was off during the config restoration. Both servers can resolve hostnames to IP, full communication between sites/on WAN, same domain as well.

I used (Site1) primary veeam server “veeamserver1” backed up .bco file and restored it to (site 2) secondary veeam server. “veeamserver2” After restoration on veeamserver2, RED X came up on both hosts and repositories.

On veeamserver 2, I did a rescan on on hosts and i got error(all hosts) for below:

-Error - "Serverhost1] Disks and volumes discovery failed Error: Access is denied.  RPC function call failed. Function name: FGetSvcVersion]. Target machine: a192.168.40.30:6160].

-Host discovery failed

 

For the local repositories rescan i got error below:

 -Error    Processing backup repositories Error: Selected server Veeamserver2.JPOL.LOCAL is unavailable.

-Warning    Failed to synchronize Site1Repo Details: Selected server Veeamserver2.JPOL.LOCAL is unavailable.

-Error    Failed to synchronize backup repositories

For my azure repo:

 -Warning    Failed to synchronize Azurerepo Details: Backup repository Azurerepo is missing tazureBlob://azurerepo/veeamfiles/Veeam12] directory that contained 14 backups

 -Warning    Backup repositories synchronization completed with warnings

I really thought this would be easy lol, especially while having the primary veeam server off. The last test I did, i had it on while doing the restore of config to server 2, believing that what was the issue i.e. both servers on competing for resources. I even turned off windows firewall on veeamserver2, so what is the issue here?

 

I need to do a test cloud restore to the veeamserver 2 (simulating if site 1 veeamserver goes down).

 

Any help would be appreciated.

                               

Did you do restore or migrate?  You will need to do migration since the server name is different than the primary one.  Restore assumes the same server.


Did you do restore or migrate?  You will need to do migration since the server name is different than the primary one.  Restore assumes the same server.

Hi chris, I did a “Restore” at the option window.


Did you do restore or migrate?  You will need to do migration since the server name is different than the primary one.  Restore assumes the same server.

Hi chris, I did a “Restore” at the option window.

If you are going to do this on a new server do the migrate option.


Did you do restore or migrate?  You will need to do migration since the server name is different than the primary one.  Restore assumes the same server.

Hi chris, I did a “Restore” at the option window.

If you are going to do this on a new server do the migrate option.

I fixed it, i just re-entered the credentials for hosts, local backup repos and the key for the azure backup

 

all is well now, gonna do a test resore from an offsite backup and update you.

 

I will do migrate next time. So are you tell me me Chris that doing a migrate option will not produce same error, no need for credentials reentering?


Did you do restore or migrate?  You will need to do migration since the server name is different than the primary one.  Restore assumes the same server.

Hi chris, I did a “Restore” at the option window.

If you are going to do this on a new server do the migrate option.

I fixed it, i just re-entered the credentials for hosts, local backup repos and the key for the azure backup

 

all is well now, gonna do a test resore from an offsite backup and update you.

 

I will do migrate next time. So are you tell me me Chris that doing a migrate option will not produce same error, no need for credentials reentering?

Yes the credentials and things should work with the Migrate option as things get reset for the new server.  You can try that next time but I have not had issues with it other than having to enable jobs again as they are typically disabled.


Did you do restore or migrate?  You will need to do migration since the server name is different than the primary one.  Restore assumes the same server.

Hi chris, I did a “Restore” at the option window.

If you are going to do this on a new server do the migrate option.

I fixed it, i just re-entered the credentials for hosts, local backup repos and the key for the azure backup

 

all is well now, gonna do a test resore from an offsite backup and update you.

 

I will do migrate next time. So are you tell me me Chris that doing a migrate option will not produce same error, no need for credentials reentering?

Yes the credentials and things should work with the Migrate option as things get reset for the new server.  You can try that next time but I have not had issues with it other than having to enable jobs again as they are typically disabled.

Thanks @Chris.Childerhose 


Comment