Help Designing An Off-Site Solution

[soupergrover]

Hi all,

I am looking for a way to optimize our off-site replication times. We are a relatively small setup. We have two VMWare servers in our main office that run 11VMs between them all on local storage. We have another VMWare server at or data center. Each site has a Netgear ReadyNAS 3200 where replicas are stored. We have a 3Mb internet connection at the main office and there is a VPN between it and the data center. We are running Veeam 6.5 on a physical server in the main office. Each NAS is attached to a VMware server on it's LAN as a datastore. The ONLY purpose of the data center is as a recovery site.

Our current nightly backup happens like this: Veeam Replica job from local storage to NAS. Then, a sync job runs between the NASes using a very uncustomizable rsync method. This whole process starts at 8:30 PM and ends the next day somewhere between 11AM and 1PM.

My main issue isn't with Veeam. It takes less than 2 hours to rep all the VMs. It's the off-site sync I'm trying to optimize. Depending on what is going on for the week, I have to come in and kill the sync job so people can use the internet connection remotely. When I do this, some of the servers don't make it off-site. I have no control on which servers go off-site - the rsync job just picks the folders it wants to sync somehow. And, if I have to kill the job before some of the servers are finished, the changes that have to get sync'd just keep getting bigger and bigger and bigger until it needs an entire weekend to finally catch up.

I wanted to maybe try off-site rep jobs using Veeam. I still need local replicas, so I thought I could fire off another rep job to the data center once the local replicas are done. If I do this I think one of the benefits I will get is being able to control the order the servers are rep'd. If the Tier 2/3 servers don't make it off-site for a week, it's not as critical. If I go the Veeam route how can I best optimize my existing infrastructure? Should I rep to local storage at the data center, or rep to the NAS since it's a data store? Or does it even matter since the bottleneck here is the internet connection? Would it help if i ran a Veeam server at the data center? I know **OF** Veeam proxies but am not sure how best to utilize them since we only run one Veeam server. Or, the bigger question, would I even really gain much (time wise) in redoing my setup?

Thanks in advance for your advice.

[Gostev]

Hi, I'd recommend that you backup locally, then use Backup Copy job to copy the backups to off-site backup repository. For best performance, when setting up off-site backup repository, be sure to specify proxying server that is local to that site. Thanks!

[soupergrover]

Thanks for your response, Gostev. We like the replica idea b/c of how quickly we can spin everything back up. I suppose I could try to identify hte ones we could live with taking longer to come online and turn those into backup jobs b/c in theory they would have to send less changes off-site. But, your copy idea did get me to looking into the other job types. Given that the VMs we sync are already powered off, which one would work best for us - another replica job, a vm copy or a file copy?

Also on the proxy idea, I read it is best practice to have a physical box there to do it with. Right now, the VMWare server at the data center has one VM running on it (a DC) and it does nothing but "be ready". Would running a Veeam proxy on that VM be OK?

[Gostev]

You can spin up VM from backup instantly as well, using Instant VM Recovery.
To copy backups, you should be using Backup Copy job.
Proxy in a VM is actually preferred in most cases.

[soupergrover]

What would be the benefit of Instant VM recovery as opposed to spinning up a replicated VM? Would there be some additional steps to make the Instantly Recovered VM the new production VM?

[Vitaliy S.]

Hi Dave, please take a look at our sticky F.A.Q. for more info about Instant VM Recovery > Instant VM Recovery. Thanks!

[soupergrover]

Thanks, Gostev and Vitaley, for your very helpful posts. I will have to play around with these ideas a bit and will likely come back with more questions

[soupergrover]

OK, I got v7 installed on a test server so I could get the Backup Copy option but, as predicted, I have a few questions.

I setup a backup job and a Backup copy job. I added the VM I want to the Copy Job using the "From Backup" choice. What would be the difference between choosing that option or "From Job"?

I didn't see anywhere to specify which proxy should be being used in this job. How do I set that? I set the copy job to copy to a data store at our data center

Thanks again

[veremin]

What would be the difference between choosing that option or "From Job"?

These options allow you to configure source for a backup copy job. More details can be found here.

How do I set that?

The proxy server is not involved in backup copy job activity, as everything is done by "source" repository and "target" repository components.

Thanks.

[soupergrover]

OK, so it's been a while since I have been able to get to this, but now I am doing some more testing and had a question. I took one of the VMs we currently "back up" using a replica job in our production methodology. I set up a second Veeam server and am "backing up" the same server using a Backup job. The Replica job usually says it transferred between 300 - 500 MB. The Backup job averages at 1.1GB transferred. I would have thought the backup job would be smaller, no? The files created by the replica and backup jobs get set off-site over night using rsync currently. If I am trying to gauge how much will go off-site, is the transferred amount telling me how much?

OK, technically that was TWO questions

[foggy]

The Replica job usually says it transferred between 300 - 500 MB. The Backup job averages at 1.1GB transferred. I would have thought the backup job would be smaller, no?

The Transferred counter shows what is actually being transferred between the source proxy and the target repository (or proxy, in case of replication). Amount of traffic should be comparable for both types of jobs (considering they run on similar schedule and have similar compression settings). What are the schedules for those jobs and what are their compression/dedupe/storage optimization settings? And, btw, what kind of repository do you use for this job?

The files created by the replica and backup jobs get set off-site over night using rsync currently. If I am trying to gauge how much will go off-site, is the transferred amount telling me how much?

It can be used as a rough estimate, however, replicas are stored in native VMware format (uncompressed) and I'm not sure regarding rsync compression, so the Transferred counter value can vary from the amount of traffic that will actually go offsite in this case.

[soupergrover]

What are the schedules for those jobs and what are their compression/dedupe/storage optimization settings? And, btw, what kind of repository do you use for this job?

Each job runs daily every 24 hours. The repository is a NAS configured as a datastore via one of the VMWare hosts. And, as far as job settings I noticed on the replica job it is optimized for WAN target, while the backup job is optimized or a local target. Everything is on the same local network. Is that maybe what is causing the difference? I wonder if the guy before me optimized it as a WAN target since they are getting sync'd off-site via another process? The whole reason to try the backup method is to do a backup copy job that sends the VM off-site. Should I optimize my backup job for a WAN target even though it is backing up to the LAN?

[foggy]

And, as far as job settings I noticed on the replica job it is optimized for WAN target, while the backup job is optimized or a local target. Everything is on the same local network. Is that maybe what is causing the difference?

Most likely. Local target uses larger block size (1MB, as opposed to 256K block for WAN target). This can result in up to 2x larger amount of transferred data.

The whole reason to try the backup method is to do a backup copy job that sends the VM off-site. Should I optimize my backup job for a WAN target even though it is backing up to the LAN?

If you're going to use WAN accelerated backup copy job, there's no need to bother about that, since WAN acceleration uses it's own, much smaller block size.

[veremin]

Also, be aware that will support "replica from backup" scenario in the upcoming v8 release. Given your current schedule, the said functionality might come in quite handy, as you would need to snapshot production VMs twice. Thanks.

[soupergrover]

If you're going to use WAN accelerated backup copy job, there's no need to bother about that, since WAN acceleration uses it's own, much smaller block size.

We do not have the WAN accelerator feature. I'm setting the initial backup job to be optimized for WAN and we'll see if that makes a difference.

[foggy]

Keep us posted on how it is going.