BE2014, Running Duplicate jobs sitting at 0 Bytes

[nPc]

I just upgraded from BE2010 to 2014 last week, in-place upgrade on a Win2008R2 machine.  The upgrade did admirable work understanding and including all the backup jobs, and things have been going reasonably well, particularly our weekend Full backups, which went very well.

However, our daily differential jobs have a major problem:  The Disk job runs fine, but the Duplicate-to-Tape jobs hang at 0 Bytes, list themselves as "Running", but do not actually engage the tape drives.  The Job Activity window has no information, save for the elapsed time.  And the jobs produce no Alerts, and never seem to fail.  And while they are sitting in the Active state, they prevent any other jobs from running. They *definitely* have blank tapes waiting for them, but those tapes are not pulled & written to.

How can I find more information about what is going on so that we can get these jobs working?  The debugger is only so useful to a layperson like myself.

What is happening here?  5 hours of hang time is insane.  The data retention policy for the disk data is adequate and should mean that the data is still present on the disk.  Why is it not going to tape?  All these jobs worked perfectly with BE2010.

In the example below the original backup is of Oracle databases, but this 0Byte-Active-Duplicate-to-Tape problem is happening with all my Differential jobs (svrs, vms, dbs, etc.)

Many thanks for assistances,

 .

 Neil

[lmosla · Accepted solution]

Hi,

 try running a repair through Programs and Features as described here: http://www.symantec.com/docs/HOWTO98871  and if needed try running a database repair through BEUtility refer: http://www.symantec.com/docs/TECH67239

if the issue continues you should contact support for further investigation

[pkh]

Try recreating your duplicate stage

1) edit your job.

2) delete the duplicate stage

3) save the job

4) edit the job again

5) add in the duplicate stage

[nPc]

Hello again, sorry for the delay, some careful testing was/is required. Largely because we have at least 55 jobs, and 4 differentials per job (M-Th).  The idea of manual deleting & recreating over 200 duplicate jobs is daunting to say the least.

I followed pkh's steps for the first 5 scheduled jobs on Thursday last, and lo & behold: ALL Thursday's duplicate-to-tape jobs ran as they should.  Thanks!

The weekend Full backups do not have this problem, so there was nothing for me to test over the weekend.  Tonight, Monday, I will see if the Monday differential-duplicate run by themselves, or if adjusting a minimum of one job is sufficient to 'release' the others.  Fingers crossed that it is the former.

If I do have to re-adjust a Monday duplicate job to push the rest through, then I will attempt the Repair as Imosla suggests.  I will report back here either way, in a day or two.

Once I know for sure, I'll mark a solution or two.

Thank you for your quick responses!

 Neil

[nPc]

So interestingly, about half my tape jobs ran perfectly Monday night, but starting about 11pm the rest failed.

I've deleted & recreated one Duplicate-to-Tape job for tonight (Tues) to see if that 'frees' the rest.  I also deleted & recreated the Duplicate job that appeared to be the triggering problem for Monday night, and it's Tuesday night brother. Report tmrw.

Does this suggest that I should do a repair to either BE or the db?  Doing both sounds rather extreme and scattershot.  Should I focus on one of them as the most likely culprit?

I've also lost the ability to right-click on a server in the Backup and Restore section;  and I cannot select "Edit Backup" on failed or cancelled jobs in the Job History window.  Both of which seem odd.

[Larry_Fine · Accepted solution]

Your issue might be this known issue.

Duplicate backups to tape or disk hang in active/running status.

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

NOTE:
Customers experiencing this issue are encouraged to contact Symantec Technical Support as data is still being collected to assist in resolving this issue.

[Steve-Young]

I would log a formal support incident and reference Larry's article.

[nPc]

Interesting, that looks like the same issue.  BEengine does indeed keep repeating:

13660    BENGINE    2264    1/28/2015 8:24:16 AM    7964    [server]             - SetCopyJob::MountDstDevice: Requesting the lock... (3426)

I will log a formal support incident.  Thank you Larry & Steve, I hadn't seen that article yet.

Much obliged.