Veeam B&R design validation - remote DR site

[dwhittaker]

Hi all,

I'm wondering if I can get any validation on the feasibility of the following design for a remote Veeam Backup and Replication v5 enabled disaster recovery site. Any suggestions or caveats I need to be aware of would be greatly appreciated.

Design criteria:
- Provide a geographically distant disaster recovery site for utilisation in the event of megadisaster (recently Tropical Cyclone Yasi finally proved my point that the locations of my client's 2 main offices - 400km apart but both in the same disaster zone - was not sufficient to utilise them as DR sites for each other). We actually utilised Veeam B&R v5 trial in the days before TC Yasi hit (both sites in danger at the same time, and both did get hit but at least no damage occured) to create a full backup of the client's infrastructure which was manually taken off-site to a user's home. The obvious problem with this being that if the office was to be blown away by the TC, the user's house likely would too, and the last thing on their mind at that point would be "have I got the backup NAS of the entirety of the company's data safe?"
- Provide security of business data (from loss) and capability to "go live" in the DR site if necessary.
- RPOs/RTOs can be measured in days if the DR solution is required to be invoked.

Challenges:
- Budget is (as always) never enough. In Australia, fat pipes are expensive, and data actually costs us (no unlimited quotas). As such, the backup transport connections for this scenario will need to be connected via their current MPLS private IP network which is an expensive proposition (but does give us the unlimited quota necessary). And because of budget, this means the only feasible pIP connection I can suggest for the tail at the remote datacentre is an ADSL2+ connection to provide the necessary download bandwidth when receiving the backups.
- Limited maximum bandwidth available. Tops out at 10Mbps upload from the client's site (impossible to get any faster connectivity due to location/regional).

Resources:
- Main site 10/10Mbps (down/up) MPLS pIP connection.
- DR site ADSL2+ 24/1Mbps (down/up - expecting to get around 11Mbps down on average, 8Mbps minimum)
- Onsite NAS
- DR site vsphere hosted environment. 1 Linux backup target VM with 1vCPU, 2GB RAM, and iSCSI connectivity to several TB of SATA-based storage from a custom built "NAS" device running Sun Solaris and ZFS.

So, with all that said, the current design is as follows:
- Veeam backup server at the production/main site. It will be a VM, and the vsphere environment for production is on NFS.
- Daily backups to a local NAS. Reverse incrementals in use here.
- Nightly or Semi-Weekly backups to the DR site. Forward incrementals utilised with synthetic fulls created "at a schedule to be determined by the reality of the situation".
- No plan to use replication (as opposed to backup) as the bandwidth issue comes into play.

Assume that my backups will easily fit into a 12 hour backup window given the WAN speeds (calcs suggest they will by a mile). I have the following specific questions:
1) Is there any part of what I have mentioned that would require I have a better UPLOAD speed (1Mbps) at the DR site? Make note I am not worrying about the restore side of things, restoration will either be local to the DR site or will have a copy of the backups downloaded to USB drive and shipped to client site if they are ever needed.
2) Is there any modification or caveats to either the backup job type (forward/reverse/synthetic) or location of the Veeam backup server I should be aware of? I have chosen the backup server location and the fact it will be a linux target at the DR site to take as much advantage of backup job compression/dedupe as possible and the ability to run synthetics locally at the DR site due to the Linux target allowing agent install.


Other than that, anything else I may have missed? Any nasty gotchas I haven't thought of? Any clarifications needed?

I appreciate any help provided here. I have been reading this forum for the past several months and know some of the design requirements of different scenarios but I'm sure I'm missing a lot of tips/tricks/unknowns.

Cheers in advance.

[Vitaliy S.]

Hi Daniel,

1) Is there any part of what I have mentioned that would require I have a better UPLOAD speed (1Mbps) at the DR site? Make note I am not worrying about the restore side of things, restoration will either be local to the DR site or will have a copy of the backups downloaded to USB drive and shipped to client site if they are ever needed.

If you're not worried about any restore operation from the DR site (FLR, VM files, Instant Recovery etc.) then 1 Mbps might be enough to transmit only VM changes. However be prepared that your full run might take some time depending on the amount of VMs you want to backup to the DR site.

2) Is there any modification or caveats to either the backup job type (forward/reverse/synthetic) or location of the Veeam backup server I should be aware of? I have chosen the backup server location and the fact it will be a linux target at the DR site to take as much advantage of backup job compression/dedupe as possible and the ability to run synthetics locally at the DR site due to the Linux target allowing agent install.

Given the specifics of your connection/setup forward incremental backup mode should be a single best choice to use while backing up to the DR site. The only modification I would recommend is to check whether 1 vCPU is enough for our agent to run on the DR site while building a synthetic full backup. If you see that the CPU Usage has maxed out, then definitely add more vCPUs for that Linux box.

Other than that, anything else I may have missed? Any nasty gotchas I haven't thought of? Any clarifications needed?

I have to admit that you've done a great job while reading all the setup recommendations and best practices from our forums, so you should be good to go with your setup.

On a side note, you may also want to take a look at HyperIP free offering of their WAN acceleration tool, might be useful.

[dwhittaker]

Hi Vitaliy,

Thankyou for the feedback.

If you're not worried about any restore operation from the DR site (FLR, VM files, Instant Recovery etc.) then 1 Mbps might be enough to transmit only VM changes. However be prepared that your full run might take some time depending on the amount of VMs you want to backup to the DR site.

I just wish to clarify this statement to ensure we're on the same page. The DR site (the target) will have the ADSL2 connection. The backups from the source will upload at a maximum of 10Mbps and be downloaded at the target DR site at the download speed of the ADSL2 connection (expecting 8 to 11Mbps). This ADSL2 connection has a 1Mbps upload limit which I assume would be utilised mainly only for acks and normal TCP response traffic. Is there anything that Veeam would be reporting back FROM the DR target site TO the source site during a backup job that would necessitate a larger upload bandwidth from the DR target site's connection?

Also, so that you have some figures for guidance my expectation from the previous emergency trial situation utilising Veeam for TC Yasi is that the sum total of daily incrementals will be around 15GB. Given 8 Mbps consistent throughput it should take less than 6hrs to transfer this. That gives me another 6hrs for other overheads in the backup time such as the fact that a backup doesn't stream the data uniformly over time - unchanged andwhitespace data needs to be processed (which takes time) but does not need to be shunted down the wire nor is factored into the final size of the incrementals.

The only modification I would recommend is to check whether 1 vCPU is enough for our agent to run on the DR site while building a synthetic full backup. If you see that the CPU Usage has maxed out, then definitely add more vCPUs for that Linux box.

This is something I have thought about and basically I was going to "see how it goes". I have the ability to provision whatever resources I wish so I'm starting at minimum and working my way up as deemed necessary.

On a side note, you may also want to take a look at HyperIP free offering of their WAN acceleration tool, might be useful.

Oooh, now this looks nice. Love a good freebie. Do you (or anyone) know if HyperIP's 2Mbps bundle will accelerate 2Mbps of the traffic but still allow the other 8Mbps to flow through unaccelerated? I assume so.

[Vitaliy S.]

Daniel,

Is there anything that Veeam would be reporting back FROM the DR target site TO the source site during a backup job that would necessitate a larger upload bandwidth from the DR target site's connection?

Not really, you should be good with this configuration (Linux box acting as a destination target for the backup jobs on the DR site). Otherwise If you decide to remove it later, you would need to place your backup server on the DR site.

Oooh, now this looks nice. Love a good freebie. Do you (or anyone) know if HyperIP's 2Mbps bundle will accelerate 2Mbps of the traffic but still allow the other 8Mbps to flow through unaccelerated? I assume so.

You'd better address this question to Steve Thompson (Netex rep.), as I'm not that much familiar with Hyper IP tool.

Thanks.