Hello. We have a main Corp site with 9 vms and 2 physicals currently backing up to a dedicated 2019 server with 256gb and 34tb of storage. All hyperv. Decently speed system that can handle a failover from production. This is a new install and the backups are working well at the moment. We have another server exactly speced at a remote site connected with a vpn over 50mb. We are going to setup some veeam Wan accelerators on both sides. But we are looking at best practice for replication options. We plan to have a b&r installed at the Dr site for disaster failover. The questions are:
1. Is it common to have both an onsite replication job to a target on site as well as a second replication job at the Dr site?
2. Should the replication job at the Dr site use the repo at the Dr site where backup copy jobs from the main site live? Or should it replicate from the main site directly?
3. Is it common to have both replication jobs to the Dr site as well as backup copy jobs to the Dr site?
4. It appears the replication source can not be a sobr. Is this the case? Curious if we wanted to add object storage into the repo and need a sobr what difficulties this would present.
5. Also since the Veeam b&r server is speced well could the replication jobs point to on the b&r server itself with hyperv installed for failover?
I know Veeam is very flexible and can likely do everything above. But we want to follow best practices and avoid too much unnecessary redundancy.
Thanks
-
- Service Provider
- Posts: 192
- Liked: 21 times
- Joined: Feb 12, 2019 2:31 pm
- Full Name: Dave Hayes
- Contact:
-
- Veteran
- Posts: 643
- Liked: 312 times
- Joined: Aug 04, 2019 2:57 pm
- Full Name: Harvey
- Contact:
Re: Site to site replication best practice
Heya Dave,
1. Sure, why not? If you have the storage/hosts/speed to transfer, no harm. Only catch might be if it's taking a bunch of time, your backup/replica window may shorten, but Replica from Backups will help there (see 2.)
2. Your call, but if it were me, I'd use Replica from backups here to avoid additional checkpoint time for the virtual machine and to leave the production VMs alone. But there's no specific best practice here; definitely use Replica Seeding since 50 Mbps line is probably too slow for the initial replica.
3. Yes, very.
4. Can you link where you see that? I don't see it: https://helpcenter.veeam.com/docs/backu ... ml?ver=110
5. it could, but I __strongly__ advise do not run VBR on the HyperV parent partition itself. It's against Microsoft best practices, and any time the VBR server needs a reboot (which might be common), you're going to have to plan a maintenance window for the HyperV VM also, and you'll constantly be at odds with random windows application issues that usually go away with a reboot since you can't as easily reboot your host. Stick VBR in a vm instead. (This is noted on the very first part of system requirements: https://helpcenter.veeam.com/docs/backu ... ml?ver=110. Any software on the parent partition in HyperV is already bad practice, and Veeam also is clear don't do this!)
So basically, seems it will work and I think you'll get decent redundancy. Just be sure to keep the parent partition of HyperV for HyperV alone -- should be nothing else there.
1. Sure, why not? If you have the storage/hosts/speed to transfer, no harm. Only catch might be if it's taking a bunch of time, your backup/replica window may shorten, but Replica from Backups will help there (see 2.)
2. Your call, but if it were me, I'd use Replica from backups here to avoid additional checkpoint time for the virtual machine and to leave the production VMs alone. But there's no specific best practice here; definitely use Replica Seeding since 50 Mbps line is probably too slow for the initial replica.
3. Yes, very.
4. Can you link where you see that? I don't see it: https://helpcenter.veeam.com/docs/backu ... ml?ver=110
5. it could, but I __strongly__ advise do not run VBR on the HyperV parent partition itself. It's against Microsoft best practices, and any time the VBR server needs a reboot (which might be common), you're going to have to plan a maintenance window for the HyperV VM also, and you'll constantly be at odds with random windows application issues that usually go away with a reboot since you can't as easily reboot your host. Stick VBR in a vm instead. (This is noted on the very first part of system requirements: https://helpcenter.veeam.com/docs/backu ... ml?ver=110. Any software on the parent partition in HyperV is already bad practice, and Veeam also is clear don't do this!)
So basically, seems it will work and I think you'll get decent redundancy. Just be sure to keep the parent partition of HyperV for HyperV alone -- should be nothing else there.
-
- Service Provider
- Posts: 192
- Liked: 21 times
- Joined: Feb 12, 2019 2:31 pm
- Full Name: Dave Hayes
- Contact:
Re: Site to site replication best practice
Thank you so much for the detailed response.!!
Regarding:
#1. I guess I was thinking that having a replicas as well as the backup repos on site at the Corp site might be over redundant. I guess I was thinking of a local failover situation where the production server failed and we needed to get up quickly and install of the instant restore we can just fire up the vms
#2) Great. That was what I was thinking as well. It seems like the best option. I can create the replicas at the Dr site from the backup copy jobs.. Right?
#3) Excellent.
#4) I think I was conflating this https://helpcenter.veeam.com/docs/backu ... ml?ver=110
Saying replication jobs to the sobr and not from. As long as I can do it we will get that repo into a sobr since we will likely be deploying some form of object storage in the future.
#5) Yes I did read that and I could easily move b&r and vbo into a vm. I did watch a video recommending it. It is just that this hyperv server is dedicated to Veeam and completely off domain. But I can move it to a vm. I suspect repoint the repo to the location via a share or pass thru? Basically this server has a refs formatted D drive for the repo.
Followup question. Veeam has usually run once per day. But this site has mission critical time sensitive data. Any downside (other than resources) to going every hour between 7am and 7pm? Losing a day's worth of data might be hard to swallow.
Again thanks for the detailed responses. I appreciate it
Dave
Regarding:
#1. I guess I was thinking that having a replicas as well as the backup repos on site at the Corp site might be over redundant. I guess I was thinking of a local failover situation where the production server failed and we needed to get up quickly and install of the instant restore we can just fire up the vms
#2) Great. That was what I was thinking as well. It seems like the best option. I can create the replicas at the Dr site from the backup copy jobs.. Right?
#3) Excellent.
#4) I think I was conflating this https://helpcenter.veeam.com/docs/backu ... ml?ver=110
Saying replication jobs to the sobr and not from. As long as I can do it we will get that repo into a sobr since we will likely be deploying some form of object storage in the future.
#5) Yes I did read that and I could easily move b&r and vbo into a vm. I did watch a video recommending it. It is just that this hyperv server is dedicated to Veeam and completely off domain. But I can move it to a vm. I suspect repoint the repo to the location via a share or pass thru? Basically this server has a refs formatted D drive for the repo.
Followup question. Veeam has usually run once per day. But this site has mission critical time sensitive data. Any downside (other than resources) to going every hour between 7am and 7pm? Losing a day's worth of data might be hard to swallow.
Again thanks for the detailed responses. I appreciate it
Dave
Who is online
Users browsing this forum: aleksey.bashkirtsev, Bing [Bot], Google [Bot] and 30 guests