Replicating .vbk Files Using DFS-R

[name4521]

Veeam Backup currently can't backup a virtual machine to .vbk files and simultaneously replicate that same VM to another ESX host for disaster recovery purposes.

Has anyone considered using Window's DFS-R to replicate the .vbk files to a remote site for DR?

[Gostev]

Interesting idea!

[Aaron]

Veeam Backup currently can't backup a virtual machine to .vbk files and simultaneously replicate that same VM to another ESX host for disaster recovery purposes.

Has anyone considered using Window's DFS-R to replicate the .vbk files to a remote site for DR?

I don't use DFS for this task. I'm a linux nerd and like to keep costs down for my customers. Right now I have a site that backs up to a linux box, then a script runs that copies the data to a identical linux server over a 10mbit metro ethernet connection. There is a vmware server at the remote location for recovery purposes.


If you have large vm's you'll appreciate the need to NOT do a restore because you are using replication instead of backup/restore. I have about 5tb of machines. It's great to be able to just turn them on, rather than wait for 5tb's to copy around and then boot.

[daveline]

I don't use DFS for this task. I'm a linux nerd and like to keep costs down for my customers. Right now I have a site that backs up to a linux box, then a script runs that copies the data to a identical linux server over a 10mbit metro ethernet connection. There is a vmware server at the remote location for recovery purposes.


If you have large vm's you'll appreciate the need to NOT do a restore because you are using replication instead of backup/restore. I have about 5tb of machines. It's great to be able to just turn them on, rather than wait for 5tb's to copy around and then boot.

What do you use for a block level copy on linux? Rsync?

[Gostev]

I should note that I've heard very high words and recommendations on the Rsync before.

[Aaron]

I should note that I've heard very high words and recommendations on the Rsync before.

Yes. I use rsync. It works incredibly well. Also, it does the whole "only sends delta changes" thing when transferring files, which is handy especially with veeam because the main backup file (largest in size) changes every time due to the synthetic backup.

[name4521]

I don't use DFS for this task. I'm a linux nerd and like to keep costs down for my customers. Right now I have a site that backs up to a linux box, then a script runs that copies the data to a identical linux server over a 10mbit metro ethernet connection. There is a vmware server at the remote location for recovery purposes.


If you have large vm's you'll appreciate the need to NOT do a restore because you are using replication instead of backup/restore. I have about 5tb of machines. It's great to be able to just turn them on, rather than wait for 5tb's to copy around and then boot.

I appreciate Linux. I use it. It's the right tool for many jobs, but I'm primarily interested in Window's DFS-R in this case. I'll be installing Veeam on my Windows server anyway and will have DFS-R at my disposal. It's just a few right-clicks away and I'll have one-way block-level replication to another Windows server at my DR site set up. I'm just curious if anyone else has considered it, implemented it that way, and has used it with some success.

So, just to clarify, you're using a Veeam replication job to replicate a running virtual machine to a Linux server. That Linux server then rsyncs those files to a remote Linux server. That remote Linux server has VMware Server installed and ready to go for disaster recovery.

I can definitely see the value in not having to import those .vbk files to do a restore to get back up and running.

[Aaron]

I appreciate Linux. I use it. It's the right tool for many jobs, but I'm primarily interested in Window's DFS-R in this case. I'll be installing Veeam on my Windows server anyway and will have DFS-R at my disposal. It's just a few right-clicks away and I'll have one-way block-level replication to another Windows server at my DR site set up. I'm just curious if anyone else has considered it, implemented it that way, and has used it with some success.

So, just to clarify, you're using a Veeam replication job to replicate a running virtual machine to a Linux server. That Linux server then rsyncs those files to a remote Linux server. That remote Linux server has VMware Server installed and ready to go for disaster recovery.

I can definitely see the value in not having to import those .vbk files to do a restore to get back up and running.

I replicate directly accross my metro ethernet, and backup straight to the first linux box, that rsyncs to the other linux box...

How much data do you have? and what kind of link do you have between your sites?

[name4521]

I replicate directly accross my metro ethernet, and backup straight to the first linux box, that rsyncs to the other linux box...

How much data do you have? and what kind of link do you have between your sites?

Thanks for the clarification.

We have Internet VPN between our sites. It could take a week or two weeks or more for a full copy with what we have. After it's all set up, I'd hate for a delta to cause a Veeam replication job to tie up the Veeam backup jobs for days because it can't both replicate and backup simultaneously. I'm just looking for workarounds. I'd be willing to sacrifice "instant on" at the DR site for independent backup and replication functionality.

[Jordack]

So this got me thinking as well.

The problem I can think of would be with DFS-R staging area requirements. Your staging area should be about the same size as the data you wish to replicate. Rsync doesn't have that requirement.

There are also ports of rsync for windows,
www.itefix.no/cwrsync/

I've been using it without problems for a while now. You just configure it the same way you would the Linux version.

Jordack

[Aaron]

I believe that Veritas Replication Exec should also do the trick. I dont THINK it has such a huge staging requirement but it certainly is a nice little program.

[chad5k1]

Just to say, we had a nightmare getting DFS-R to work, mainly due to the staging area I think.
In the end we used RSYNC, but as I'm not a linux head I found a GUI version for windows, called Deltacopy
http://www.aboutmyip.com/AboutMyXApp/DeltaCopy.jsp
Works well enough, although due to the way Veeam works the replication each night to our offsite location is lengthy to say the least.

[awiesen]

Just for another data point, we use rdiff-backup, which is similar to rsync, except it keeps the deltas around so you can maintain a history as well. (So it's kind of like having offsite replication of both your vbk and vbr files -- you really only replicate the vbk file offsite, but the deltas that rdiff-backup makes are similar to vbr files.)

As someone mentioned in either this thread or a different thread, the main issues we've seen are:

(1) You want to make sure you put your swap file on another drive and don't backup that drive, because it makes for extra large deltas between your .VBK files
(2) Antivirus scans can introduce deltas between .VBK files as well. We're currently experimenting with a couple of different antivirus programs trying to find one that doesn't have a significant impact. (We were using AVG Network Edition 8.5 and it seems to make the deltas pretty big.)

One area where rsync is superior to rdiff-backup is that it can resume a failed transfer, and you can throttle the network usage directly. For really big initial replication jobs, we've used rsync to transfer the initial (huge) .vbk file, then rdiff-backup to maintain the file over time. (We use a separate bandwidth throttling program on our backup server when using rdiff-backup to ensure we can control bandwidth usage.)

- Alex

[chris.trotter]

One thing against DFS is the max file size of 64GB (at least for Server 2008 R2). This means that no single file (i.e. *.VBK) can be larger than 64GB.

We've run into this wall and are testing out rsync.

[name4521]

Thanks, Chris. That's a very important limitation of DFS that has to be taken into consideration.

[Gostev]

Thanks Chris, I was not aware about this either.