Job Taking to long, so cancels itself

[andrewparkes]

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?

[CraigV]

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/tuning-my-lto4-tape-drive

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!

[andrewparkes]

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]

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]

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

[pkh]

What is the resource that is slowing down the job?

[andrewparkes]

Resource?

[pkh]

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

[andrewparkes]

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

[pkh]

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]

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.

[Kiran_Bandi]

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]

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

[andrewparkes]

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]

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!

[Kiran_Bandi]

~ 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 

[CraigV]

...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...

[Kiran_Bandi]

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]

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]

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.