Babysitting BESR 2010 clients and issues

[Jon_Sumida]

I really like the BESR 2010 product...except for one thing. It seems I have to "babysit" more clients then I would like to. By this I mean, I log on almost daily to my Management Console to make sure everything is going ok. But everytime there is a handful of clients that for whatever reasons have skipped/missed backups for several days or are stuck doing a backup. Normally I have to reboot the PCs or clear out the *.PQJ and *.PQH files and start a new base recovery point. I've been all over these forums and on search engines looking for reasons why these things are happening and there's no real concrete answers. I manage 300 PCs and doing this extra work to maintain the backups is stretching my time really thin. Is there an update with fixes coming soon? These are my main issues:

- skipped/missed backups, clients look fine (green check box in system tray icon). I can tell they missed because in the Manage Tasks, Computers view in the Console it shows last time run as several days ago

- misreporting of the "Last Run" date when you open the client. The one on my PC says my last backup ran was 42 days ago, but in my backup history it shows backups successfully completed every day

- backups hanging at 95% or even at other points. No future backups will run because they think it's stll not completed. Must reboot PCs and/or delete PQJ/PGH files


Again this happens on a handful of PCs usually and they seem to randomly happen. Different PCs, different dates, etc.  I've posted about some of these issues before and gotten nothing really except a link to this: " http://seer.entsupport.symantec.com/docs/352307.htm  "  That page might explain some of my issues, but there doesn't seem to be any progress on that. Anyone else experiencing any/all of these issues? I'm using version 9.0.1.36527

[Markus_Koestler]

Would you please mark this post as solved ?

[Markus_Koestler]

Would you please mark this post as solved ?

[jbtsabw]

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

[oscubed]

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.

[Markus_Koestler]

Sorry.

[Jon_Sumida]

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.

[Markus_Koestler]

Thany you very much and please keep us informed !

[criley]

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.

[kqf_chris]

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.

[Jon_Sumida]

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.

[criley]

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.

[jbtsabw]

Jon, are you replicating your restore point destination by chance?

[Jon_Sumida]

Not sure what you mean by replicating the restore point destination. Can you elaborate?

[jbtsabw]

We have a restore point destination in one data center and we replicate it to another share in another data center.

[jbtsabw]

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.

[Jon_Sumida]

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 :(

[Linas]

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

[Jon_Sumida]

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

[Dushan_Gomez]

Yes, looking forward for greater enhancement in SP2

[criley]

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).