Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Job Taking to long, so cancels itself

Created: 29 Jan 2013 • Updated: 04 Feb 2013 | 24 comments
This issue has been solved. See solution.

We are running Backup Exec 2012 on a Windows Server 2008 R2 Server. It has been running fine for the the best part of the last year ,however over the past few months it seems to be taking longer to backup, but the extra amount of data is only ab increase of about 10GB or so. On 28th December it took 15:43:18 to backup 680GB @ 893.23MB/Min. 26th January it backed up 686GB @ 882.76MB/Min , but cancelled it self due to reaching the maximum configured run time.

We could turn off the maximum run time but this would mean it clashing with the start time of the next job due it it being a full backup, so thats not really the answer to it as has worked fine for past god knows how long.

So what causes it, as 6GB of data shouldnt really take an extra 6+ hours to backup and verify.

Any ideas?

Comments 24 CommentsJump to latest comment

CraigV's picture

Hi,

What type of data are you backing up and to what device?

If tape, check out pkh's article below on tuning a tape drive and see what difference it makes:

https://www-secure.symantec.com/connect/articles/t...

You can also make sure that any AV running on that server isn't perhaps scanning the BE services, and if so, put in an exclusion for them.

Thanks!

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

andrewparkes's picture

Its just file data from a file server, backing up to a Dell LTO3 tape drive.

Cleaned the drives again yesterday to see if that makes a difference. Had a thought about the AV last night so am looking into that today.

Will check that other article though and see, thanks

pkh's picture

Expand your joblog and examine the backup and verify time for each resource.  Compare this with a previous "good" backup to see which resource and what stage is causing the slow-down.

andrewparkes's picture

Its the verify stage, it "backs up" more or less in the same amount of time

Kiran Bandi's picture

Seems readnig the tape is the issue! Is it happened on 26th Jan for the first time? If so, the media that was used might be the cause. 

Also make sure you are using Symantec drivers for tape devices. Upgrade the tape drive firmware if it is running older version.

CraigV's picture

...and if it is multiple tapes? How does the advice now relate?

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Kiran Bandi's picture

~ 700GB. LTO 3 tapes. Maximum 2 tapes?

Finding a bad media (if present) among them won't be a big problem.

Symantec drivers and firmware upgrade suggestions are nowhere related to number of medias.

If you have any query please open up a new discussion wink

CraigV's picture

...I think I know enough about BE, hardware etc. to get by...no need to attempt to be funny or sarcastic as it was a simple question. It was a simple question, backed up by the OP's comments below yours...blush

Alternative ways to access Backup Exec Technical Support:

https://www-secure.symantec.com/connect/blogs/alte...

Kiran Bandi's picture

backed up by the OP's comments below yours

That's the point, why can't you wait for OP to come back against someone's advice???? Don't you think that is much better than we both making unnecessary noice in forums? It will take ages for me to understand........

andrewparkes's picture

It is using the symantec drivers, it has worked fine with them for ages. Firmware was updated about 8 month ago, dont think there is a newer version.

Can't see how it can be the media, as multiple tapes are used so they cant all be bad, surely.

I think its possibly either the tape drive itself is the issue, might try moving to another library and trying it there. Could also be the latest version of SEP 12.1.2, as its caused issues with other programmes we run since it was installed, so maybe need to look further at the exclusions

Kiran Bandi's picture

Why they all have to be bad? One among them is good enough to create hell a lot of issues...

~700Gb to LTO 3 tapes. Max 2-3??

might try moving to another library and trying it there

Good luck!

andrewparkes's picture

Well its been happening everyday for the past few weeks. Using 2 tapes at a time, out of a total of about 100 tapes, so surely even if one is bad, we would have been able to isolate it as a recurring incident on that tape over time as it would only use that tape every month or so?

Im sort of leaning towards the issue being the actual tape device, hence the reason for moving the jobs to another one.

It was cleaned last night, and the backup for last night has just finished, some 6 hours earlier than it has been. Now whilst we could think this has solved the issue, we actually cleaned it last week and it worked fine for the one day before taking ages again... So will leave it at that for now and see what happens tomorrow i thikn before looking further into it, I am however, expecting it to go back to taking a lot longer, in which case, surely its the heads in the drive?

Kiran Bandi's picture

surely its the heads in the drive?

You can use Dell Library and Tape tools to check the device functionality. Incase of any error, contact vendor and ask for replacement if under warranty.

andrewparkes's picture

Yeah, they will be run later today. Will report back if the uncover anything :)

pkh's picture

What is the resource that is slowing down the job?

pkh's picture

C; drive, D; drive, system state, Exchange....  Things that you back up.

andrewparkes's picture

My bad, it only backs up the one drive. al ldata is stored on that

pkh's picture

Do you realise that if that disk crashes, you loose your data as well as the backup?  The idea of a backup is to get the backup as far away from the resource as possible.

If it is the C: drive that you are backing up, are you backing up the system state?

andrewparkes's picture

What?

We back up the E:\ drive to tape, we have a rotation policy and offsite storage for long term tapes? We have successfully restored all the data when we migrated the file server to 2008.

Explain to me again how we lose everything?

We dont back up the C:\ drive, there is no need to.

pkh's picture

it only backs up the one drive. al ldata is stored on that

I thought that you meant that all the backup data are stored on that one drive together with the data.

=================

Regarding your SEP, see this document

http://www.symantec.com/docs/TECH168940

==================

We dont back up the C:\ drive, there is no need to.

As an aside, if you don't backup the C: drive, how are you going to restore the server?

andrewparkes's picture

I thought that you meant that all the backup data are stored on that one drive together with the data.

Nope, that would be stupid and a waste of time/money. It does state on the discussion that its backed up to tape

=================

Looking into the SEP exclusions, although it worked fine previously, using the same SEP policies so not sure if that is the issue, but will check anyway.

==================

We dont back up the C:\ drive, there is no need to.

It backs up the data on another drive, not C:, the data is the important bit. The server is not as it can be restored to another server if required

andrewparkes's picture

Well todays backup is still running the backup operation, by the time it gets to the verify stage it will have cancelled itself again anyway! Going to swap the drives over and backup to another library to see if that makes a difference

andrewparkes's picture

Would seem that adding the exclusions and unticking the "scan on backup" option in the SEP polices have sorted it. The past few backups have all finished on time. Must be yet another bug in SEP 12.1.2 that causes the problem as we never had it in 12.1.1 and before as it always finished in time.

Fun and games, I swear this SEP AV is just designed to cause more problems than it solves

SOLUTION