6c8f17e7 - job still in progress issues

[Jon_Sumida]

I have some clients that skipped their backups over the holiday (Mon) and they are showing this error:

Error EBAB03F1: Operation aborted.
Info 6C8F17E7: An automatic recovery point was not created because an earlier recovery point from the same job was still in progress.
Details:
Source: Backup Exec System Recovery

I've seen this happen when a backup job was still in progress, but this isn't the case for these machines. Checking the logs, I find the previously mentioned entry, then the next one in line states:

Info 6C8F1F7E: A scheduled incremental recovery point of drive C:\ was created successfully.
Details:
Source: Backup Exec System Recovery

First one is dated 5/30/2011 11:00PM, which is the normally scheduled time. The second log entry is dated 5/27/2011 11:06PM.  This was Friday night. My backup policy is set to skip running on weekends. So everything looks good after Friday night according to the log and then last night it skips the backup because it thinks a job was still in progress. Note that pm 5/27/2011 11:00PM there is another entry that states a job was still in progress, but ths backup job is reported as finishing successfully afterwards.

Not sure why this is happening all of a sudden, but I have multiple users with the same issue now.

[Markus_Koestler]

This is a known issue:

http://www.symantec.com/business/support/index?page=content&id=TECH129983&key=56720

[criley]

Markus is correct. I would suggest that you unregister RPAM.DLL to see if this helps.

[Linas]

I was working with support with same issue and they wanted me to do the unregister Rpam so I did

Not knowing it would invalidate all my backups so now I can not restore any old backup because they are removed from database and I still get the same messages of duplicate jobs running

I teck I am working with told me a patch would come out a week later from May 21  or I should start from scratch and install and deploy SSR2011 I asked if the duplicate job issue is resolve in ssr2011 but I did not get response he told me he would call the next day to discuss this and other concerns I had

Well I am still waiting a week later?

No call

No patch

No answer

But still same messages of duplicate jobs running 

[criley]

Not knowing it would invalidate all my backups so now I can not restore any old backup because they are removed from database and I still get the same messages of duplicate jobs running

That should not happen.

Can you open the recovery point(s) using the recovery point browser? If yes, do a manual verify to see if they are valid.

[Linas]

Files are on server but not seen by besr

Systems at risk no recovery point exist after Rpam

This happened weeks ago did not have to restore so we are ok

Just very disappointed this happened and I feel the need to warn others this might happen and the fix doesn’t work and to wait for patch

Backup are running even with all the errors of duplicate jobs running it seems for every backup job

Waiting for support to call

Waiting for patch

[criley]

Waiting for patch

There is no ETA on this yet I'm afraid.

I would still check my above comments. If you can verify the recovery points using the recovery point browser, they are valid and can be used for restore.

[Jon_Sumida]

The RPAM solution didn't work. Do I have to restart the BESR service first?

[criley]

You have to stop the service, unregister (wait for success message), then restart the service.

[Jon_Sumida]

Ok. Geez, even if this does work, what a pain to have to do this to 200+ PCs to make sure it doesn't occur. Is this issue resolved in SSR 2011?

[criley]

It's not fixed in SSR 2011 yet (I wish I could say it was).

Just to clarify: the issue that RPAM.dll causes is some backups to hang at 95% which in turn causes subsequent backups to be missed/skipped. This generally is seen when you have multiple machines backing up to the same network location.

I agree that the workaround is not ideal but it's all we have at the moment. I would suggest you try on a few machines to verify that it actually helps before you roll out this change to all your clients.

[Jon_Sumida]

Well I'm not getting the hanging at 95% issues as much anymore. My backups get skipped altogether because they think another backup process is in progress. I have to go in and delete the PQH and PQJ files after stopping the service, then I restart it and usually everything is good for a little while until the same problem (or another one) pops up. I started a "babysitting BESR 2010" thread a while back and unfortunately I still am doing so a lot more than I would like.

[criley]

OK, that still sounds like an issue related to RPAM.DLL so I would try the workaround to see if it helps.

If that does not help, get a case open with tech support.

[Jon_Sumida]

Thanks Chris. If there's no known fix for this issue, I won't bother opening a case with tech support since they will likely have me try the solution you guys already suggested. It's odd that this product would have issues with backing up to the same network location since I assume a lot of people would configure their backup system this way. It's not realistic to have a backup destination for each PC for my environment. Although if we did, I wouldn't have about 90% of the problems I run into now.  My external drive backup destination clients run smoothly majority of the time.

[Linas]

What happened to support

I am working on this with Andreas from Symantec support and it seems he is unavailable

Back in May 21 he was waiting for new patch to address this issue and mentioned new SSR install I inquired about the new install No answer

June 1^st The patch is out and that’s the last I heard from support

Is the patch out?

Or is the patch a bust?

[criley]

Is the patch out?

Or is the patch a bust?

If you are referring to a patch for the issue where backups hang at 95% in 'updating history', there is no patch (not yet anyway).