Video Screencast Help

Issues following R3 upgrade

Created: 24 May 2011 • Updated: 08 May 2015 | 6 comments
This issue has been solved. See solution.

Hi all, we have just upgraded to the 2010 R3 install.

Since the upgrade we are experiencing a few issues that i'm hoping someone may be able to feed back on.

We have a number of jobs that are managed by policies, since the upgrade some of the jobs do not run (remain in queued state) whilst others do run. This is particularly bad for our VMWare jobs.

Those jobs that do run (in some cases after several hours of being queued) are not using Client side deduplication - only media side is being used, this knocks on to the job rate going through the floor compared previously.

All remote agents have been upgraded, some automatically from within the program and the others manually using the .cmd files.

Duplicates are also experiencing issues, these are either not running or in some cases are starting and then stopping part way through. (duplicates are dedupe storage to LTO5).

Has anyone come accross similar issues at all? 

Many thanks

Comments 6 CommentsJump to latest comment

CraigV's picture

Hi there,

Did you get any errors during your upgrade?

When jobs queue, they also normally have an alert that needs to be responded too...right-click your queued job, choose: Respond to alert, and then see what it states. Place that message here.

I'd also recommend running BEutility.exe and repairing your BEDB.


Alternative ways to access Backup Exec Technical Support:

seanbh's picture

Hi there,

Thanks for the response. The upgrade to R3 passed without any issues, no errors raised.

No alerts are coming up as part of the queued jobs, they literally just sit there for anything between a few minutes (as is standard), a couple of hours or indefinitley.

No errors/alerts have been raised so far with the exception of the client side deduplication being unable to be used.

Will give the repair a go tomorrow and see if it helps. Fingers crossed for the jobs tonight...

sbora's picture

If the backups are targeted to deduplication folder then you may be facing issue documented in following document:

Fix for this issue is in piperline. In case you need pre release version of this fix you need to contact technical support.


seanbh's picture

Hi sbora,

Many thanks for the link, have logged the call with tech and will get a call back regarding the issue.

Last nights backups run was improved but the 'queued' issue remains with jobs starting at very random times!

Will post an update with how things go.


seanbh's picture

Still waiting for callback

Still waiting for callback from Symantec.

Better news is that my backups were much better last night, on the previous day I had a lot of entries in the application log relating to Event 58064 : Library insert when trying to run a backup to deduplication:

Please insert media 'OST00000037-4CA73D551F897949' into the robotic library by creating an Import media job.

If the media does not have a bar code, click Options on the Import Job Properties, and select 'Auto-inventory after import is completed'.

For more information, click the following link:

The dedupe location in question had been removed from the main media set in R2 and into Retired media due to an issue with the end marker, I reinstated this into the main pool yesterday and the jobs ran far better, not perfect still but much closer to the norm.

seanbh's picture

Just had a call from Symantec relating to the 'queued' status and linking to the use of deduplication storage and changes that have occured between R2 and R3.

For at least this part of my issues it sounds consistent with my own experience so far given the jobs returned to almost normality last night.