Backup Over Site to Site VPN

[tuscani]

I am trying to backup some large VMs (2-300gb) over a site to site VPN (50mb on each end).. job eventually fails with "primary bottleneck" being the network. Is backup over tunnel for VMs this large feasible or should I be looking at doing a replicate job instead? Or?

[Vitaliy S.]

Justin,

What kind/type of repository are you using at the DR site? Is it a Windows, CIFS, Linux box?

Thanks!

[tuscani]

It's a Windows server

[foggy]

Justin, the size of the transferred data is comparable between backup and replication jobs in case of similar settings and architecture, so replication will not change things for you. What was the actual reason of the failure? What settings does this job have (are you using WAN storage optimization and best compression)? You can also consider backup seeding to avoid sending full VM images over this link but rather transfer incremental changes only.

Some of our customers backup over even a slower links (<1Mbps sometimes). From Veeam B&R perspective, speed is not the highest concern, what is more important is that the connection should not actually drop. Typically, Veeam B&R can resist to very bad high latency connections and minor packet loss but if the connection is dropped, the job fails.

[tuscani]

I will try using storage WAN optimization and extreme compression.. thanks

[Yuki]

Did you see backups first? you should try this for sure.

We are backing up and replicating across a 100mbit link and we are pushing a lot of data (daily backup is 100-400gb). Our main server is close to 6TB. You may be running into latency and/or dropped packets, which could cause this problem. Another issue is if your link gets saturated by backup and user activity, so if you can - try to get a dedicated link to the second site.

[tuscani]

The WAN optimization and extreme compression may have did the trick... I am 14 hours in at at 66% and it has not failed yet.. xfer speed is around 5mb though

Processed: 220GB (66%)
Read: 218GB
Transferred: 176GB 1.2x

What's odd is when I check the destination location I see only a 17GB backup file and the file size has not changed in hours.

[tuscani]

Well the job did eventually fail.. as did a few other VMs around the same size.

I am seeing various errors in the job reports:

----

PrepStorageForWriteEx failed 'V:\x\x-03-31T210104.vbk' Client error: Exception of type 'Veeam.Backup.AgentProvider.AgentClosedException' was thrown

Error: Client error: ChannelError: TimedOut

Processing 'x'
Failed to save backup meta to 'V:\x\x.vbm' [y] Failed to create directory 'V:\x The RPC server is unavailable RPC function call failed. Function name: [DoRpc]. Target machine: [y].

----

Job windows shows:

Failed to save backup meta to
Load: Source 1% > Proxy 6% > Network 49% > Target 0%

[Yuki]

two issues:
1 - seems you MAY have issues with connectivity (high latency or dropped packets which cause the tunnel/data stream to collapse)
2 - once you work out communication issues, you should seed full backup if possible and then replicate changes only. that will shrink the size of data being transferred and will lessen the chance of lost packet/data

[Gostev]

In these conditions, I would definitely recommend seeding the initial full backup versus going over WAN... we ourselves are doing replication over Atlantic, and it is usually takes some luck when we have to do a full backup over the wire...

[tuscani]

Detais on how to seed the full? And how oftern would I have to do that because doesn't VEEAM do random fulls?

[veremin]

The statements provided above have do with initial backup seeding.

For doing it:

• Perform initial full backup locally
• Transfer .vbk you get to remote location
• Re-scan repository to which you moved you backup files
• Map backup job

For more information regarding backup mapping functionality kindly see the corresponding User Guide (p. 117).

Hope this helps.
Thanks.

[tuscani]

Ok.. but what happens though when VEEAM tries the next full and that fails.. is there a way to prevent future fulls and just do incs moving forward, or bad idea?

[veremin]

Synthetic full should be the answer in this case.

Hope this helps.
Thanks.

[tuscani]

That is what I have enabled (incremental with synthetic full)...

[veremin]

Then, you should be ok, since the synthetic full backup will not use network resources and will be taking place only on remote location - it will assemble new full backup file based on your increments and full backup that has been seeded previously by you.

Hope this helps.
Thanks.

[tuscani]

Ah perfect!

Still irritating I have to seed.. I know it's prob not VEEAM related as the smaller VMs.. say 60gb backup so fine over the VPN.. just these larger ones are the issue!