Need advice regarding large VM backup

Availability for the Always-On Enterprise

Need advice regarding large VM backup

Veeam Logoby ferrus » Fri Nov 25, 2016 11:38 am

We've had our Veeam installation running for 12 months now, and everything has been a huge improvement on the previous backup product.
As we're gradually migrating all of our systems across - I've come across a big problem with the Exchange backup.

To back up our three node Exchange 2010 DAG, it was decided that the best and safest way forward, after reading all the guides and advice on DAG backups - was to create another passive node, with copies of all the databases and logs - and just back that up.
This has been working perfectly for a few weeks now, but we've hit a big problem with the secondary copy job.

Our main backups go to local RAID6 DAS storage, our copy jobs are then sent to an EMC DD2500.
Obviously the speed of the Data Domains is a lot slower than the local storage - but it's now causing us a headache with the Exchange backups.

The VM size is 17.5TB. The full backup size is around 7TB. The incrementals can be around 600GB.
This is fine for the local backups. The job processing rate is 260MB/s - as the 25 disks are backed up in parallel. The merge takes some time - but it's dealing with a 7TB full backup each day - so that's fine.
The backup copy is a different story. The processing rate is 50-70MB/s - as the 25 disks are processed sequentially. The backup process can take 12-13 hours, and then the merge starts. This isn't fast either.

Taking a look at previous logs, it's taking >24 hours quite a few times. This in turn is disrupting the backups job, and subsequent day's backup copy.

I did wonder if this was related to our other Data Domain performance issues (1, 2), but I think this time - it's actually just the size of the VM.

My two initial thoughts are:

1) Create another passive DAG, and back that up in a separate job. This should halve the backup copy job window, but require another Exchange VM, and a lot of reconfiguration.
2) Create a second Veeam job, backing up the same VM - but exclude half the disks on each job. This should halve the copy job window again without requiring extra resources - but leaves me with a lot of questions regarding restoring the VM, and needing to reattach virtual disks.

And advice on the above - especially 2), or anyone have a better suggestion?
I'd be surprised it we're the only Veeam customer backing up a large VM to a Data Domain.
ferrus
Veeam ProPartner
 
Posts: 127
Liked: 20 times
Joined: Thu Dec 03, 2015 3:41 pm
Location: UK

Re: Need advice regarding large VM backup

Veeam Logoby DeadEyedJacks » Fri Nov 25, 2016 12:25 pm

Why is the Backup copy disrupting your backup job?
Suggest you disable the backup copy job schedule during the backup job window.

We have a similar issue that daily mailbox backups take around 8 hours , but the "daily" backup copy job take 2-3 days including the GFS transforms.
Our solution was length the "copy every" windows to 3 days. So inside of daily incomplete copies, we at least get a complete copy every few days.
Microsoft, NetApp, Symantec, Veeam, Veritas and VMware certified professional
MCTS, MCSE, NCDA, NCIE-BR, ASC, SCS, VMTSP, VTS, VCP
DeadEyedJacks
Veeam ProPartner
 
Posts: 85
Liked: 9 times
Joined: Mon Oct 12, 2015 2:55 pm
Location: UK
Full Name: DeadEyedJacks

Re: Need advice regarding large VM backup

Veeam Logoby ferrus » Fri Nov 25, 2016 1:03 pm

The Backup Copy uses the Backup .vib files as a source, so when the first Backup copy takes >24 hours, that delays the following days Backup Copy, which locks the files that the main Backup job needs to use - which delays that, and then it all starts spiraling.

Hadn't considered reducing the frequency of the Backup Copy job. That's a definite third option - although it would increase our risk slightly, should we lose the Backup copy.
ferrus
Veeam ProPartner
 
Posts: 127
Liked: 20 times
Joined: Thu Dec 03, 2015 3:41 pm
Location: UK


Return to Veeam Backup & Replication



Who is online

Users browsing this forum: No registered users and 53 guests