-
- Lurker
- Posts: 2
- Liked: never
- Joined: Sep 07, 2020 8:12 pm
- Full Name: Eslam EL Manakhly
- Contact:
Many to One Replication
Hello Folks,
I have a scenario of 10 branches running Hyper V cluster and want to replicate them to one DR site. Is there any kind of replication scenario which supports me in this use case? And what are the main factors which I should take into consideration of building this design and sizing?
I have a scenario of 10 branches running Hyper V cluster and want to replicate them to one DR site. Is there any kind of replication scenario which supports me in this use case? And what are the main factors which I should take into consideration of building this design and sizing?
-
- Chief Product Officer
- Posts: 31804
- Liked: 7298 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Many to One Replication
Hi, Eslam. This is one of the most typical scenarios and I can't think of any special considerations here really... the product is designed to do just that. Your DR sites has to be sized appropriately from compute perspective depending on how many source sites you expect can be down at the same time. Thanks!
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Sep 07, 2020 8:12 pm
- Full Name: Eslam EL Manakhly
- Contact:
Re: Many to One Replication
Hi, Gostev.
My main question is it applicable to replicate " Backup copy Job " from multiple VBR servers to one Veeam server as a "repository server" and be able SOBR from this server to an Object storage in the cloud.
My main question is it applicable to replicate " Backup copy Job " from multiple VBR servers to one Veeam server as a "repository server" and be able SOBR from this server to an Object storage in the cloud.
-
- Product Manager
- Posts: 9848
- Liked: 2606 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Many to One Replication
It‘s possible, if it’s not a linux hardened Repo.
But definitely not recommended to share components between multiple backup servers.
If you use this server as a windows or linux repository with local disks, you must keep all vbr servers on the same Version and Patch level. For example, you will not be able to use a VBR V11 and a VBR V11a with this centralized backup repo. Both VBR must be on V11a.
Second, all vbr servers are not aware of each other. One server could use all the resources (cpu/ram) of the backup repo.
Why not using SOBR offload directly from each vbr server to the cloud? I don‘t see the benefit of using a central location for that.
Or use a single centralized vbr server and on the remote sites, deploy proxies and backup repositories. Then you can use a single backup repository in your datacenter to receive the backups from all remote sites.
But definitely not recommended to share components between multiple backup servers.
If you use this server as a windows or linux repository with local disks, you must keep all vbr servers on the same Version and Patch level. For example, you will not be able to use a VBR V11 and a VBR V11a with this centralized backup repo. Both VBR must be on V11a.
Second, all vbr servers are not aware of each other. One server could use all the resources (cpu/ram) of the backup repo.
Why not using SOBR offload directly from each vbr server to the cloud? I don‘t see the benefit of using a central location for that.
Or use a single centralized vbr server and on the remote sites, deploy proxies and backup repositories. Then you can use a single backup repository in your datacenter to receive the backups from all remote sites.
Product Management Analyst @ Veeam Software
-
- Chief Product Officer
- Posts: 31804
- Liked: 7298 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Many to One Replication
Please note that "Replication" and "Backup Copy" jobs are two completely different features. And for DR specifically, it is more typical to use Replication jobs over restore time considerations.
You should make up your mind as to what is it you're trying to build in the first place. Which starts from determining with your business leaders what is the required RTO (Recovery Time Objective) in case of a production site loss: whether the DR site needs to be up and running at full speed in a matter of minutes, which requires replica VMs standing by. Only if there's no such requirements, you can consider going with backup copies instead.
You should make up your mind as to what is it you're trying to build in the first place. Which starts from determining with your business leaders what is the required RTO (Recovery Time Objective) in case of a production site loss: whether the DR site needs to be up and running at full speed in a matter of minutes, which requires replica VMs standing by. Only if there's no such requirements, you can consider going with backup copies instead.
Who is online
Users browsing this forum: No registered users and 28 guests