How do I recovery from a failed Veeam Server.

[cag]

I have been testing some common failure situations.
Test 1
Create a successful replica of a VM, with additional incrementals. Netowrk mode Passes 100%.
Remove the replica Job of the vm to simulate failure of the veeam backup server and re-install.

re-create the replica job exactly as the previous job.

The job fails claiming a duplicate name. Ok this I understand but where is the option to rebuild / restore previous state so I dont need to remove the previous replica and start from scratch again. The first replia's over a WAN takes 3 days. This is not good !

[Gostev]

Hi Conrad, with the current version you have to start from scratch. Be sure to protect Veeam configuration database to make sure you can restore failed Veeam server easily, without having to perform the initial replication over again. Thanks.

[cag]

Thats not good. Also its not possible to have a complete backup of all config info because you never know when a failure or corruption occurs.

EG: 10 servers are running a replication. fails after 5 replications. So 5 have completed a replication and 5 are pending. backup of the config files completes after the jobs are done.
Therefor the last 5 servers do not have valid config and therefor are forced to restart from scratch. If I restore the config to an earier point then the 5 replications that have completed become invalid becuase the config doesn't know about the 5 servers that completed previously. Seems like a design flaw.

The configuration should be stored with the replica and should be imported to any server so it can pickup from where it last left off.

Similar to VM's VDR application. Makes Veeam risky for DR sites. Who has the time to start from scratch over WAN links.

[Gostev]

It is a question of properly protecting the configuration database. How do you protect your SQL servers from a failure today? Do you have a process in place today allowing for point-in-time recovery of your SQL Server databases with no dataloss?

By the way, SQL Server has replication available natively that allows to sync changes immediately as they occur, so if you implement this, you will never end up in situation you describe.

[cag]

I guess my point its best to store this with the replication job / data. The more steps the more points of failure. Then I dont need the extra step. VMWARE VDR stores its backup info in the datastore with the backup. Veeam should do the same so I can rebuild not re-install and restore just to continue to operate.

This would allow veeam to be an appliance that performs a task. The backup / replication state should be in the datastore so the next job can pickup from where it left off. This would also allow multiple servers to work as a team to backup any servers to any destination.

[Gostev]

It's not that simple, this approach/architecture has other drawbacks. And is one of the reasons why VMware DR is arguably worst data protection solution available today as it comes to reliability. Nevertheless, the ability to import and reuse existing data to prevent full resync over WAN is of course needed, and we will have it down the road. Thanks.