Need to backup a remote physical fileserver witj low band with

[BennyDC]

I have a specail request.
I need to backup a remote physical file server to the main B&R server in the main location. On the remote side i have only the physical fileserver
with +/- 17TB that i need backup to the main side a physical Veeam B&R server with attached repository.
The bandthwith is very slow 4Mb/s. I tried to do this with the agent.
After 1 week we did get up to 8% and the on the remote side the fileserver did get rebooted and we could over again.
My question is it possible to install on that physical fileserver Veeam WAN ACC and would this benifit to move this data to the main side.
AS told on the main side a physical Veeam B&R with attach disk for the repositories, its also connected via fiber to the production storage.
If this possible is it also a benifit to use a virtual proxy as WAN ACC at the main side. We don't use that at this moment as we use storage snapshots.

Case 04770077.

[PetrM]

Hi Benny,

No, it's not possible. However, you could run the primary backup on the remote site locally if you had a repository there and to leverage backup copy with WAN-accelerators to transfer data to the repository on the main site.

Thanks!

[BennyDC]

Thanks PetrM
I have currently no other extra hardware there

[BennyDC]

did got the folllowing answer back from veeam support not sure how this helps me
I appreciate you taking time to open this case. This is Shane from Veeam Support and I will be providing you with an initial response before this case is assigned to a dedicated engineer in your time zone. I would advise against it as you could end up experiencing "Snapshot Stun". When VMware take a snapshot of the VM you are backing up, your WAN Accelerator would be offline for those 10-60 seconds. That may be enough to cause the Proxy to timeout trying to write to the WAN; hence, "Snapshot Stun". If you have a particularly fast snapshot time, under 10 seconds, you might be able to get away with it. My suggestion, test it on a single run. If it doesn't work, undo it. I would advise placing the WAN Accelerator on the Proxy or on it's own VM.

[Egor Yakovlev]

Hi Benny!

I guess Shane has missed the "physical" part and suggested a scenario with virtual machines in place. I'll pass him a word.

As for your scenario, that is quite challenging even if we put technology aside: 17TB of data, if we take average compression of 50% - that gives us 8.5TB to transfer for Full backup, and (optimistic guess) 5% daily change of 870GB. If you have a 4Mb\s(I read it 4Mbps, megabits per second, unless it's a typo) network, that gives us pure 0.5MB\s(megabytes per second) bandwidth. With those numbers, Time = Amount of Data / Speed = 206 days for Full backup, 20 days for Incremental...
We have a wonderful tool to play with to get approximations for required bandwidth based on data size and expected copy window here. Feel free to check it!

So best solution here would be either having a local storage for fast local backups + periodic(sloooow) offsite copies AND\OR changing the available connection speed higher to satisfy your data growth.


/Cheers!

[BennyDC]

Hi Egor
I see in veeam as processing rate 4MB/s .
After 20h there is 270gb processed and 235gb(1.1) transeferred.
I have there only a physical server with a disk of 21TB where 17TB is used data that I need to backup.
Is there maybe a way to get the data more compressed transferred?

[PetrM]

Hi Benny,

You can change the default compression algorithm and set it to "High" for example. Also, you can decrease a size block by choosing "WAN target" as a storage optimization setting in order to get better deduplication ratio. You can fine both options in this step of backup job creation wizard. However, I don't think that you will gain a lot by applying those settings and I'm still convicted that the best way to go will be to get a storage for local backups if you don't have a chance to optimize the connection speed.

Thanks!

[BennyDC]

Hi PetrM,

Thanks for your reply, those settings don't they have only an impact on the target storage?
Will this compression also have an impact on transfer?

Thanks.

[Egor Yakovlev]

Compression and block sizing happens on the source side, aka where Veeam Agent is installed, so yes, it might reduce the sent data footprint.
However even with 4MB\s(32Mbps) throughput that would yield roughly 300GB\day transfer rate. It will take too much time.