11-07-2010 05:41 PM
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...
Solved! Go to Solution.
11-08-2010 09:23 PM
You can download BESR SP2 from https://fileconnect.symantec.com. Prepare you serial number, you'lL need it for downloading.
11-07-2010 11:05 PM
Try to update to SP2 aka 9.0.2
11-07-2010 11:20 PM
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...
11-08-2010 07:23 PM
Thanks Markus,
Where can I find SP2? I can only find SP1 on the Symantec site.
11-08-2010 07:28 PM
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.
11-08-2010 09:23 PM
You can download BESR SP2 from https://fileconnect.symantec.com. Prepare you serial number, you'lL need it for downloading.
11-09-2010 03:45 AM
Thanks Markus,
I have downloaded it and will give it a try.
11-09-2010 05:03 AM
May I ask you then to mark this post as solved ?
11-10-2010 04:31 PM
Hi Markus,
I am having some issues installing the update. I hope to be successful on the weekend.
11-11-2010 12:24 AM
Any success installing the updates ?
11-11-2010 03:11 PM
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
11-14-2010 02:35 PM
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...
11-15-2010 09:05 PM
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.
11-16-2010 01:38 AM
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.
11-16-2010 07:34 PM
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.
11-17-2010 11:29 AM
Arth, where are you saving your backup image files to?
11-17-2010 12:34 PM
Can we remove the solved status to this? This is the most glaring problem with BESR 2010 IMO and it isn't resolved.
11-18-2010 12:53 AM
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.
11-18-2010 03:08 PM
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.
11-19-2010 01:32 PM
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.)