Backup question of remote server (leads into V7)

[Starman]

I have Veeam in my primary data center and I'm now backing up 300+ gig VM's over the WAN at night from a remote Esxi server. They have pretty fast broadband however the initial back up still takes days. The incremental only take 20 mins or so. The issue I have is at a few sites that their rural broadband like to reboot themselves in the middle of the night making it impossible to get my initial backup.

If I created a storage data repository store on the Remote servers virtual machine (to say a sata drive that's installed on the remote server), when I back that server up with the Veeam at my local office, would Veeam then pull the data across the WAN process it then send the backup files back over to the WAN to the remote repository? Or, is Veeam smart enough to simply back it up strait from the remote ESXI server to its local repository and avoid sending it over the WAN. My guess is obviously the first.

What I'm getting at is being able to process the backup on the remote site then use 7.0 WAN acceleration to send it over to my local storage afterwards.

I used to try this with DFS but I found that it could leave me in Jeapordy on a virtual machine if everything crashed in the middle of the file being DFS'ed to the other site, leaving the backup in an inconstant state. I am worried about this with the WAN set up in 7.0 also.

Thank You

[Helqasem]

Veeam will work well in this scenario.

If you have a remote proxy and remote repository at the remote site, the backup will happen locally (RemoteProxy->RemoteRepo), with no data transmitted across the WAN. You would then use a WAN accelerated v7 Backup Copy Job to copy the backups from your remote site to your local repository.

This is exactly the use case for the new WAN acceleration functionality.

[Starman]

Thank you, does this happen with 6.5 right now? Meaning, remote site, remote repository the backup happens locally? I only ask because I cant wait until 7 comes out to get these servers backed up

[Gostev]

Yes.

[Starman]

Thanks Gostev! You guys never cease to amaze me with Veeam. I have a break out session at VMworld and Ill be sure to throw in how much I love Veeam (hope to hit the Veeam party again this year).

[Gostev]

You are welcome. And you are most welcome to our party, too
We loved the venue from last year so much, we booked it again!
It will be awesome!

[Gostev]

P.S. One thing to keep in mind with the deployment above: although we don't use WAN link to transfer the virtual disk data, it still serves as a control/management channel (like initializing backup proxies with tasks etc.). In other words, WAN link has to be up for jobs in the remote site to run. So, in scenarios when this WAN link is only up once in a blue moon (like with cruise ships, for instance), this architecture is not going to work well - and you will need to go with a local B&R install in the remote site instead.

[Starman]

P.S. One thing to keep in mind with the deployment above: although we don't use WAN link to transfer the virtual disk data, it still serves as a control/management channel (like initializing backup proxies with tasks etc.). In other words, WAN link has to be up for jobs in the remote site to run. So, in scenarios when this WAN link is only up once in a blue moon (like with cruise ships, for instance), this architecture is not going to work well - and you will need to go with a local B&R install in the remote site instead.

Thank you! Already have the job up and running. 2 day job over the wan (200 gig on this VM) was done in 45 minutes and for now I'm setting up DFS to replicated the jobs themselves over to the Veeam server.

[veremin]

Glad to hear that everything works as expected.

As mentioned, should any issues related to job failing due wan link drops occur, then just deploy a separate instance of VB&R in the remote location and use it as local backup server for such jobs. In this case it might be also worth installing Enterprise Manager in order to have visibility across two servers.

Thanks.