Hi @AShaikh! Has a number of replication scenarios and typically works between sites as long as you are well connected. There is an additional option with Veeam of working with what’s they call a cloud connect partner, replicating to a managed IaaS environment that does not require VPN connectivity at all, just outbound Internet service with sufficient bandwidth.
You will want to check out the user guide for replication but there are different scenarios. See here - https://helpcenter.veeam.com/docs/backup/vsphere/replication_components.html?ver=120
Also Veeam also has CDP - Continuous Data Protection which can also replicate with near zero time lag. Something else to check out depending on your infrastructure.
https://helpcenter.veeam.com/docs/backup/vsphere/cdp_replication.html?ver=120
Welcome to the community @AShaikh, many options are already mentioned.
You have also the option to built your replicas from existing backups (if you don’t want to process the production VM more than once a day or if this fits for your RPO)
If you also want to built more on DR plans, test and report RTO/RPO you should have a look at the Veeam Recovery Orchestrator.
best, Markus
Other tip I will add … look at doing a pull replication e.g. Veeam server at DR site pulling info over the SD-WAN , rather than a push from Production side of SD-WAN. That way if production goes completely dark, you still have control over replicas
Other tip I will add … look at doing a pull replication e.g. Veeam server at DR site pulling info over the SD-WAN , rather than a push from Production side of SD-WAN. That way if production goes completely dark, you still have control over replicas
Does it mean setting up another veeam server at DR site and add all repository. Then pull data from production repository?
Also do I need deferent licence for DR server?
Other tip I will add … look at doing a pull replication e.g. Veeam server at DR site pulling info over the SD-WAN , rather than a push from Production side of SD-WAN. That way if production goes completely dark, you still have control over replicas
Does it mean setting up another veeam server at DR site and add all repository. Then pull data from production repository?
No the suggestion is to have the VBR server at the DR site to do everything. No extra server.
Other tip I will add … look at doing a pull replication e.g. Veeam server at DR site pulling info over the SD-WAN , rather than a push from Production side of SD-WAN. That way if production goes completely dark, you still have control over replicas
Does it mean setting up another veeam server at DR site and add all repository. Then pull data from production repository?
No the suggestion is to have the VBR server at the DR site to do everything. No extra server.
This will increase backup completion time, so this is not an option.
Other tip I will add … look at doing a pull replication e.g. Veeam server at DR site pulling info over the SD-WAN , rather than a push from Production side of SD-WAN. That way if production goes completely dark, you still have control over replicas
Does it mean setting up another veeam server at DR site and add all repository. Then pull data from production repository?
No the suggestion is to have the VBR server at the DR site to do everything. No extra server.
This will increase backup completion time, so this is not an option.
Then you can have a standby server at the DR site in case the main site goes down. Otherwise DR is harder without a VBR server.
I checked the Backup Copy job and there is no way to connect to DR VBR server as target.
I checked the Backup Copy job and there is no way to connect to DR VBR server as target.
If you are sending to a repository in the DR side you connect that to the VBR server once it comes up.
I can connect to repository to DR that’s not a problem. But when there is a disaster you dont have VBR at DR site to restore.
I can connect to repository to DR that’s not a problem. But when there is a disaster you dont have VBR at DR site to restore.
Exactly why the recommendation or standby server there.