Backup Offsite very long

[aevenot]

Hi,

I'm doing offsite backup and I encountered some issues.

Architecture
Remote Site : 1 ESXI 5.0 with 7 VMS
6 VMs are Production Servers
1 VM is my Veeam Backup with only proxy installed 6.5.109 (OS Windows 2012)
Data : 1To, daily change data ~20Go


Datacenter
1 VM for Veeam Backup with Backup Server and EMS (OS Windows 2012) and 2To LUN iSCSI for repo
1 VM for vCenter Server 5.0 (OS Windows 2012)


I have one backup job with these options
Incremental(Compression optimal and optimized for WAN target) with 30 days retentions
Backup repository is local
Backup proxy : Automatic.


My backup job is taking very long to end, ok I have lot of data to send but it's very long to process data.
My job is running since 12h with
Processed Data 176Go, very far for the 1,1 To
Read : 13,3Go
Transfered : 8,3Go

The job has chosen the right Veeam backup proxy but I find this job very long. It would be better for me to backup locally and copy the vib to my remote server, so why choosing a distributed architecture


Maybe my configuration is bad but I ask for advice

[dellock6]

Hi,
is it correct the direction of the of the backup is Remote->Datacenter, right?
Since it's a backup, optimal compression of data crossing the wan link (by the way, what is the bandwidht? Maybe it's too small...) comes by using proxy at remote site and repository at datacenter. To be sure it's running ok, first configure the remote proxy, no need to leave the job with automatic.
Second, what are the bottleneck stats?

Luca.

[aevenot]

Yes you're right about the direction.

My link is 2mb so I have done the first backup to a usb drive connected to the proxy.

Bottleeck is network of course and it's as if all the processing data are going over the wan link and not only the delta.

[dellock6]

Have you done the correct backup mapping to point to the seeded backup?

Anyway, 2 Mbit link allows you to move across it at most 900 MB in an hour, so if your daily change is 20 Gb, it's going to last for at least 22 hrs, even more considering tcp overhead...

By your numbers, 12h to move 8.3 Gb gives you a speed of 691 MB per hour, that is a link usage at 76%, it could be given as I said TCP overhead and maybe some other kind of traffic using the line meanwhile.

Luca.

[aevenot]

Yes correct mapping.

The job has crashed this night

Error 701 on MSSQL$VEEAMSQL2008R2 --> There is insufficient system memory in resource pool 'internal' to run this query.
and
Error 0 on VeeamBackp --> Service cannot be started. System.Net.Sockets.SocketException (0x80004005): Only one usage of each socket address (protocol/network address/port) is normally permitted

So my job is long I Know but the last window showed me 73% of the process, GRRRRR !!!!

Job History
Time : 26h
Read : 21,5 Go
Transfered : 14,5Go

[veremin]

Error 701

This is a generic SQL error. It seems that the server where SQL database resides on is underprovisioned. As the result, there is not enough memory to run query against VB&R database.

Hope this helps.
Thanks.

[ahmsafeer]

is it possible for the backup product to delete the oldest backup automatically in order to create the most recent backup in case the disk is running out of disk space ?

[Vitaliy S.]

Ahamed, backup chains are controlled by configured r retention policy settings. If you need to delete old backup restore points, you need to adjust retention policy accordingly.