09-01-2010 09:01 PM
12-15-2010 11:57 AM
Would you please mark this post as solved ?
01-13-2011 12:34 AM
Would you please mark this post as solved ?
01-13-2011 08:48 AM
Markus, I doubt his problem has been solved. This is the closest thread I can find to the problems we are having. I have a case open with Symantec and these problems have not been solved. I have been given an orphan patch and it has not solved my problem.
I have similar problems to his:
Recovery point sets that only make a base
Systems that prompt to run missed backups when the backups have run
Incorrect incremental file naming
Missed backups with no errors in the logs
01-16-2011 10:02 AM
We are not here to resolve your need to fulfill your problem resolution quota, or make your stats look better. We're here to solve problems. I have the same problem as this person and bunches of other people on the forum have the same problem. And yet there is no resolution offered from Symantec support - either on the forums or in person. Your attitude towards failed backups seems to be "deal with it". This is not acceptable to us or to our clients.
It is annoying and counterproductive to ask that a thread be marked solved when simple reading of the the thread shows that the problem is anything but solved.
01-17-2011 03:41 AM
Sorry.
01-19-2011 02:39 PM
No worries Markus. I see you try to help a lot of people on this forum. I'm still having a lot of problems that I originally posted above. Some get resolved on some clients, then it pops up again.
It looks like this RPAM_Store.dat file is the issue on the hanging back ups. The article here:
http://www.symantec.com/business/support/index?page=content&id=TECH139416
Suggest some solutions that don't seem very realistic for me. I understand creating a new directory for each client being backed up to create an individual RPAM_Store.dat file for each, but that would require me making 200+ policies for each client I want to back up. Not going to happen.
The other solution suggests this:
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
That seems a bit more realistic to do. I'll try that and see what happens.
01-19-2011 10:21 PM
Thany you very much and please keep us informed !
01-20-2011 12:59 AM
That seems a bit more realistic to do. I'll try that and see what happens.
Yes, that is the current workaround (for jobs that get stuck @ 95% showing 'Updating History'). Note that we should have an orphan (beta fix) for this issue soon.
01-20-2011 11:09 AM
I would also like to get the beta patch as well once it is released. This was a very time-consuming issue for me to deal with and there still is no actual fix, just workarounds.
01-21-2011 11:56 AM
Just for clarification Chris, that workaround is done on the client side and not the BESR server side right? I ask because I have BESR installed on my server as well so the files exist on both.
01-24-2011 01:06 AM
Jon; you will need to implement the workaround on any BESR 'client' that is showing this issue.
By client, I mean any server or workstation with BESR installed.
01-27-2011 09:54 AM
Jon, are you replicating your restore point destination by chance?
01-28-2011 05:59 PM
Not sure what you mean by replicating the restore point destination. Can you elaborate?
02-01-2011 11:26 AM
We have a restore point destination in one data center and we replicate it to another share in another data center.
02-03-2011 09:02 AM
Ok, I have been working on this for quite some time now and we have traced it to problems with RPAM. If you don't need granular recovery or to mount a recovery point as a drive, disable RPAM by unregistering the file RPAM.dll found under Program Files\Common Files\Symantec Shared\rpAccess. (This is the same solution for the job getting stuck at 95% when updating the history).
Delete Documents and Settings\All Users\Application Data\Symantec\Backup Exec System Recovery\History\RPAM_history.dat.
Delete documents and Settings\All Users\Application Data\Symantec\RPAMRPAM_Cache.dat. However, you will still have the problem of old records in the RPAM_Store.dat.
However, you will still have the problem of old records in RPAM_Store.dat which is located at the root of your restore point destination. I need a SQL to delete those records. I can see the records in tblImageLocation, but I think there are related records in other tables as well.
03-01-2011 12:52 PM
Thanks for sharing. Sorry for the delay in answering. I've been busy in a move. I am going to try to implement something like what you just did. Then I plan on deleting the PQJ and PQH files to have all my back ups start from scratch. The latest hang ups I've experienced really locked up my backups and now most if not all will not complete at all. Doesn't get hung up at 95%, gets hung up in the beginning. Something is locked somewhere so I'm basically starting over from scratch :(
03-01-2011 02:00 PM
I am looking at the Management Solution
I opened a case with support my computer was always shown at risk and now support called and I am not in risk any more at first I thought maybe I wasn’t managed any more and was not listed any more but to my surprise I am in the Backed Up status
So I go to Manage Tasks on the Besr2010MS and click my computer and click Details to check its status and first page is Status and it shows Backed UP with a description “This computer is currently protected by Backup Exec System Recovery. All recommended drives are backed up.”
So next I check Events I see E and L drives backed up and further down the list I see
2/22/2011
“Info 6C8F1F65: The drive-based backup job, Backup of C:, has been started automatically.”
The next tab Backup History
I see L drive Available and E Available
But C Unavailable and agene and agene
Next tab Volume Status 0-1 Not Reported last backup Never
C drive status Backed up 1/31/2011
E drive backed up 2/24/2011
I checked the backup location E and L backup’s are there. There is no C backup
Now I compare with my Bosses PC
Under Status tab it shows Attention Needed A backup policy or task is assigned but has not been run for a long time
I don’t know what its talking about the jobs just ran on the 25 and they are weekly backups
03-02-2011 09:04 PM
That's kind of how it is. The reporting feature of the status of the backups isn't very accurate I find. Some of mine would say they haven't backed up for months when I checked on the console, but when I go onto the actual PC, open BESR and check the history, it says it's been backing up every day as it should. Just more of the "babysitting" that I originally complained about when I first started this thread.
There's so many of us experiencing some or all of these issues, I wish SP2 would come out and fix it all. Wishful thinking? Maybe, maybe not
03-02-2011 09:53 PM
Yes, looking forward for greater enhancement in SP2
03-03-2011 02:37 AM
Jon,
Are you talking about the standalone BESR client or the managment solution (BESR-MS)?
There are known issues for both that could explain what you are seeing:
http://www.symantec.com/docs/TECH140310
http://www.symantec.com/docs/TECH137591
Do either of these match what you are seeing?
SP2 for both BESR and BESR-MS is already available (and has been for some time).