Backups hang at 95% in 'Updating History' state when clients are using a shared backup destination folder.
|Article:TECH139416|||||Created: 2010-09-08|||||Updated: 2010-12-02|||||Article URL http://www.symantec.com/docs/TECH139416|
|NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.|
If a backup is hanging at 95% during the backup process, and multiple machines are backing up to a shared backup destination, or even the same location but with a unique subfolder, then this issue may be related to a file 'lock' on RPAM_Store.dat which is created/updated during backup operations.
In most cases, the backup is complete but it is recommended to check the validity of the recovery points.
No specific error is seen but the backup hangs at 95% in 'Updating History' state.
This issue is commonly seen when multiple clients are backing up to a shared backup destination and when the backup jobs are overlapping.
At this time, it is believed that a file 'lock' on RPAM_Store.dat is causing this issue.
The issue described only applies to Backup Exec System Recovery (BESR) 2010 (9.0.x), therefore the solution is designed specifically for BESR 2010.
There are two temporary workarounds for this issue (Note; use either workaround but not both):
- Manually create a sub-folder for each server, and then point each job to the individual folders. Do not select 'Save backup files to a unique subfolder' (Tasks/Options/General). Manually selecting a specific folder will direct the RPAM_Store.dat file to be created in the specific folder for each client machine.
- RPAM.dll can be unregistered which will also disable the ability to mount a recovery point. If this workaround is used, RPAM.dll can be re-registered when the recovery point needs to be mounted or opened in GRO (Granular Restore Option). To unregister RPAM.DLL, open a command prompt and use the following command: RegSVR32.exe /U C:\Program Files\Common Files\Symantec Shared\rpAccess\Rpam.dll
Once the DLL has been successfully unregistered, the Backup Exec System Recovery service (VProSvc) will need to be restarted. To re-register, remove /U from the above command.
Symantec Corporation has acknowledged that the above-mentioned issue is present in the current version(s) of the product(s) mentioned at the end of this article. Symantec Corporation is committed to product quality and satisfied customers.
This issue is currently under investigation by Symantec Corporation. Pending the outcome of the investigation, this issue may be resolved by way of a patch or hotfix in current or future revisions of the software. However, this particular issue is not currently scheduled for any release. If you feel this issue has a direct business impact for you and your continued use of the product, please contact your Symantec Sales representative or the Symantec Sales group to discuss these concerns. For information on how to contact Symantec Sales, please see http://www.symantec.com
Please be sure to refer back to this document periodically as any changes to the status of the issue will be reflected here.
RPAM_store.dat is causing backups to crash (during creation) when multiple backups are being stored at the same destination
Article URL http://www.symantec.com/docs/TECH139416