Video Screencast Help

BE 2010-Differential backups much slower since R3

Created: 29 May 2013 | 6 comments
Hi all,
We recently migrated our Backup Exec server from 2010 to a new box running 2010 R3 SP2. Everything went smoothly, the existing DB was imported into the new server and all the existing jobs run fine. However we just finished updating all of our remote agents and we are finding that our nightly file server differentials are running very slowly, taking approximately 50% longer than before.
We have three nightly differential [use archive bit] jobs that run consecutively, backing up different DFS replicated directories via VSS. Prior to updating the remote agent on the file server, these three jobs fell within the following time ranges (last 30 days' history).
Job 1: 4:20 - 5:00
Job 2: 1:55 - 2:35
Job 3: 1:30 - 2:00
This was also true after moving to BE 2010 R3, while still running with the 2010 R1 remote agent for a few days.
After updating the remote agent, the last two nightly differential job durations have been:
Job 1: 7:00 & 7:45
Job 2: 3:35 & 3:55
Job 3: 2:55 & 3:05
Cumulatively, this means our file server backups are finishing at ~10am as opposed to ~5am and messing up other schedules. I have rearranged job/tape order to mitigate this for now, but I would like to find the root cause and fix it.
None of the job settings have changed and this only started after updating the agents, not immediately following the migration to 2010 R3. We have similar DFS/VSS based nightly-diff-plus-weekly-full backup jobs on other servers that have had their agents updated and which have not been impacted like this.
The only possible thing I can think of is that since the agent was updated after the weekly full backup on Sunday, there is not a full backup preceding the differentials that was taken with the same agent version.
Any other suggestions as to why this could have happened?
Operating Systems:

Comments 6 CommentsJump to latest comment

ZeRoC00L's picture

Are your servers rebooted after updating the BE remote agent ?
Also after installing the new version, did you run liveupdate to make sure all available updates are installed ?

If this response answers your concern, please mark it as a "solution"

Steve-R's picture

Yep, sorry, I forgot to mention, server was not rebooted immediately after agent update (it never prompted).

That was the first thing I thought when I saw the backup jobs ran long the first day. Server was rebooted yesterday evening, but it made no difference to last night's backups.

Ran LiveUpdate once to receive SP2, again to receive all hotfixes, and one more time to ensure there were no further updates.

pkh's picture

Regardless of whether there is a prompt, you should reboot your server after an update.  There might be some process holding on to some module, preventing their update.

As an aside, if you are using the archive bit method, you might want to try using the modified time method with the USN journal.  The latter method should speed things up a bit.

lmosla's picture

Are you backing up to tape or disk? 

Steve-R's picture

Thanks for the replies so far, guys.

Last night's times:

Job1 - 6:48
Job2 - 3:10
Job3 - 2:46

We're currently backing up to tape. Four tapes in total. I've shuffled the job devices around to better distribute the end-times for now.

During my investigations I've read a few posts where it has been suggested that using modified time is faster than using archive flag. This is something I'd like to investigate and test a bit more before changing the live jobs.

We are currently testing plans to start running the overnight backups to run to disk, then dump the BTD files off to the tapes during the day, which will alleviate the bottleneck caused by really slow jobs tying up tapes for extended periods.

I'd still like to get to the bottom of why this has happened, though ;)

lmosla's picture

What is the version of the Tape Drive?  If you havent already make sure it is using Symantec Drivers and if they arent installed use tapeinst.exe to intall them.

Also there has been issues if the Unknown media changer is not using the microsoft driver so if applicable make sure in Device Manager the Unknown Medium Changer is using the default Microsoft driver. see the discussion here