Incremental Backup time increased day by day.

[Ivan_2]

Version: Backup Exec 2010 R2 with VMWare Agent.

We do the full backup on Sunday, and then incremental backup on every PM & night.

Recently, we found the incremental backup time increase a lot day by day, and resume normal after full backup.

The backup size is stabe and similar on each day but after 7/8 full backup, the time increased abnormal and especially on 12/8.

Another Server:

On Sat, backup about 6.8G takes about 4.5 hours!

Is this normal or anything we can tune?

Ivan

[CraigV]

Hi,

I'd suggest upgrading to BE 2010 R3 as your first troubleshooting step. The licenses are the same as what you are using currently.

Once done, patch the media server and push-install the patches out to your remote servers. See if this sorts the issue out and report back here.

Thanks!

[Colin_Weaver]

This might be more related to VMware's change tracking than Backup Exec itself

Although there is something else you need to be aware of - Incremental AVVI backup sets are directly linked to all of the previous incrementals since the last full and the last full itself - this is because the GRT cataloguing and recovery process has to access the complete state of the VMDK at the time of the incremental backup, not just the incremental changes. As such it its possible that something relating to this might slow down incrementals over time (and then reset when you run a full) Note the above is only a thoery I have not validated it by testing or by checking anyone from our engineering team. If I am oon the correct track though then disabling GRT might show a difference in performance.

Also Differential sets work the same way but are only linked to the full and not any other differential sets.

[Ivan_2]

As per our observation, we saw the backup job had completed backup status, then, wait for a long long time to switch to "Update Catalog".

Ivan

[Colin_Weaver]

Now the "Updating Catalog" comment is interesting as that does potentially link it with the GRT capability because we have to open/mount all the preceding backup sets to gerenate the catlogs

A bit more "possible" explanation info.

A VMware Incremental backup only backs up changed blocks, but a GRT restore restores complete files, so the catalog for a GRT set needs to identify every backup set that the blocks in each file is linked with - hence the GRT Incremental updating catalog phase has to reference/open every set back up to and including the last full which will add a time delay that for each set.

Note: You do get a 'synthetic' style benefit from this in that your incremental GRT restore selections show all the all files as if you did a full.

[Ivan_2]

I have also thought of this direction. "Update Catalog" process should be related to GRT & Incremental issue. However, the long time is spend on "Backup" process.

When I use my eye to tracking the Job Monitor page, in "Backup" process, it seems finish in a quite early stage as the "Byte Count" stopped early. The backup exec wait for a long long time and then do the Update Catalog.

As from observation, the Update Catalog speed is normal. It seems something is waiting in "Backup" Process.

Ivan