cancel
Showing results for 
Search instead for 
Did you mean: 

BESR 2010 hangs at 95% complete Updating History

NeilB
Level 4

We have about 8 servers being backed up with BESR 2010.  Intermittently one will stop at 95% complete and show "Updating History".  What is the permanent fix for this.  Often I can restart the service and run the backup again and it is fine.  Other times not.

One server is upgraded to version 9.0.1.36527 but that did not fix this issue.

All suggestions welcome...

 

1 ACCEPTED SOLUTION

Accepted Solutions

Markus_Koestler
Moderator
Moderator
   VIP   

You can download BESR SP2 from https://fileconnect.symantec.com. Prepare you serial number, you'lL need it for downloading.

View solution in original post

24 REPLIES 24

Markus_Koestler
Moderator
Moderator
   VIP   

Try to update to SP2 aka 9.0.2

Sush---
Level 6
Employee Accredited Certified

Here are some of the technotes which you can refer to resolve the issue:

 

http://www.symantec.com/docs/TECH62474 : Backup job hangs at approximately 95% with a status of "Updating History" when using Backup Exec System Recovery (BESR) 

 http://www.symantec.com/docs/TECH141655 : A backup job hangs at 95% and "Progress and Performance" remains "Updating history".

http://www.symantec.com/docs/TECH139416 : When backing up multiple machines to the same destination, some hang at 95% with an Updating History status.

 

Thanks,

-Sush...

NeilB
Level 4

Thanks Markus,

 

Where can I find SP2?  I can only find SP1 on the Symantec site.

NeilB
Level 4

Hi  Sush,

The article ...

http://www.symantec.com/docs/TECH139416 : When backing up multiple machines to the same destination, some hang at 95% with an Updating History status.

... seems the most relvant.

I have our backups directed to a single share on another machine and each machine backs up to its own folder in that share.  Howerver the RPAM_store.dat file is external to all those sub folders and shared by all the backups.  Do I need to delete it and recreate all the backups to get one per server inside the individual sub folders? 

What is the consequence of deleting it on the machine that holds the backups?

Thanks for your help.

Markus_Koestler
Moderator
Moderator
   VIP   

You can download BESR SP2 from https://fileconnect.symantec.com. Prepare you serial number, you'lL need it for downloading.

NeilB
Level 4

Thanks Markus,

 

I have downloaded it and will give it a try.

Markus_Koestler
Moderator
Moderator
   VIP   

May I ask you then to mark this post as solved ?

NeilB
Level 4

Hi Markus,

I am having some issues installing the update.  I hope to be successful on the weekend.

 

Markus_Koestler
Moderator
Moderator
   VIP   

Any success installing the updates ?

NeilB
Level 4

Not yet. 

I ran it the first time and it said it would upgrade the current installation.  Then after running for some time it said it was interrupted and no changes were made.  I tried again and it offered to modify or repair.  I chose repair, it ran for a while and then said it was interrupted and no changes were made.  I tried modify and got the same result.  So I guess I will fully uninstall the current version and do a new install.  That should be fine.  Weekend work.

 - Neil

NeilB
Level 4

I instaled the update successfully on the weekend and I have deleted the history and job and recreated it to a specific share on the server to which it is backing up.  So far so good...

arth
Level 3

No, 9.0.2 does not fix the problem (and I didn't think it would either, based on the release notes).

Stopping the services and deleting the pqh and pqj files does NOT fix the problem, nor does deleting the RPAM_Cache.dat file, nor a combination of the two.

Even uninstalling BESR 9 and reinstalling (9.0.2) does not fix it.

The first backup set after reintalling succeeds.
Subsequent backups to the same set hang at 95% with "updating history".

The destination is a network drive (and no, it's not FAT, and yes, it supports permission/ownership settings), and the directory isn't used by anything else except BESR.

I see others mentioning an RPAM_Store.dat file -- no such file gets created,  either on the client side or the server side.
The server only has .iv2, .iv2i and a [machinename].sv2i file.
On the client side, there's only the RPAM_Cache.dat in the ProgramData/Symantec/RPAM directory.

I'm at a loss for what else to try.

criley
Moderator
Moderator
Employee Accredited

No, 9.0.2 does not fix the problem (and I didn't think it would either, based on the release notes).

Agree with you.

I see others mentioning an RPAM_Store.dat file -- no such file gets created,  either on the client side or the server side.

Are you sure about this? Typically this gets created in the root of the backup destination folder.

Something that has worked for some customers is to unregister RPAM.DLL:

RegSVR32.exe /U C:\Program Files\Common Files\Symantec Shared\rpAccess\Rpam.dll

Let us know if this helps or not.

arth
Level 3

Yes, I'm sure there's no RPAM_Store.dat

As a sysadmin, I never allow remote connections to write to the root of a share, and the BESR docs don't list that as a requirement either.

Andreas_Horlach
Level 6
Employee Accredited

Arth, where are you saving your backup image files to?

Jon_Sumida
Level 5

Can we remove the solved status to this? This is the most glaring problem with BESR 2010 IMO and it isn't resolved.

criley
Moderator
Moderator
Employee Accredited

Jon Sumida;

If you are still experiencing issues like this, I would suggest that you open a case with support so that this can be looked at in more detail.

arth
Level 3

A subdirectory of the share.

\\servername\backup\machinename

The account configured in BESR has full access to the machinename folder, and read/traverse accesss to the root folder of the share (\backup).

And both file backups and the first backup for any partition to a set works fine -- it's the second and subsequent incremental backups for a partition to a set that will hang at 95%.  And neither the first backup nor subsequent backups ever create any RPAM_store.dat files.

arth
Level 3

Further to this, the followng information in http://www.symantec.com/docs/TECH139416 appears to be incorrect:

"Workaround 1-  Manually create a sub-folder for each server, and then point each job to the individual folders.  Do not select "save backup in unique subdirectory".  Manually selecting a specific folder will direct the RPAM_store.dat to the specific folder."

Unfortunately, this is wrong.  With BESR2010 (all version up to and including 9.0.2), the RPAM_Store.dat goes to the root folder even if you select a subdirectory.

This is bad news for two reasons:

1:  The problem not only affects multiple users backing up to the same location, but also single users; if they don't have write/create/modify access to the root folder, incremental backups will hang.

2:  Much worse, it's an exploitable security flaw.
If allowing full access to the root of a backup share, users can then rename an existing folder, create a new one in its place where they are owner, and then recursively take ownership of and read the backups and personal or professional data of other backup users.
There are dozens of other possible exploits too, including but not limited to symlinks to UNCs or denial-of-service attacks by pre-creating folders and files.

The only workaround I have found is to create a unique share per BESR instance, with the administrative and performance overhead that entails.

Since this is a rather severe security flaw, I hope that Symantec fixes it quickly, so RPAM_Store.dat files get written to the selected backup folder, not the root folder, just as the technote article state it will.
(And preferably even throw up a one-time warning if the root folder of a share is writeable if the user has selected a subdirectory, as most users are probably not even aware that this is a security issue on shared systems.)