cancel
Showing results for 
Search instead for 
Did you mean: 

granular restore password not valid No.2

https://www-secure.symantec.com/connect/forums/granular-restore-password-not-valid

This issue still exists - "tested" with SBS2008, BESR 2010 Version 9.0.2.37914. Posting into this thread is not possible anymore.

As this is a software you should *trust* in, this is ... ahm... interesting. In the end GRO is a major functionality worthless with broken Exchange and Sharepoint support.

It just seems as if Symantec has a huge problem with passwords all over: BE Agent for Linux does not work with encryption, too. Ticket open since June 2010 - and NOT solved in R2, as tech support stated last time they contacted us.

We cannot understand that problems like these exist for such a long time - are we the only company caring for data security in the form of encryption? Can't imagine that.

17 Replies

You're not alone...

Ran into this problem yesterday for the first time - Need to recover a single, super-important Email.

And since I followed the BESR user manual best practices (p. 224)...

About the recommended use of Backup Exec System Recovery with
Exchange Databases:

Additional backup applications are not needed to run with Backup Exec System
Recovery.

...my only option (as I see it) is to restore the entire exchange server into a lab environment and pull this Email from the database.

 

THE HORROR!!!

 

EDIT:

I Noticed that when I connect with GRO client to the server that holds the recovery points for my Exchange, I am presented with a password prompt for an old, no longer existing v2i file (_Drive015), where the oldest v2i around is _Drive021. Authentication failes, of course... See attched .jpg files.

This is a known issue:

This is a known issue: http://www.symantec.com/docs/TECH128501

Try the following to see if this helps:

Delete RPAM_cache.dat from C:\Documents and Settings\All Users\Application Data\Symantec\RPAM (or C:\ProgramData\Symantec\RPAM). Then try and open the recovery point using GRO again.

If this does not help, please open a case with Tech Support.

where to get the fix

I started a same case a year ago https://www-secure.symantec.com/connect/forums/granular-restore-password-not-valid

The workaround as mentioned doesn't work for us.

I tried to open a support case (mysupport) to get the fix (see at the bottom of TECH128501). After putting in the full case a couple of times, we keep getting errors (with IE9 and Chrome). I give up, it cost too much time. How can I get the fix, so we can test this in a testenvironment?

The fix for this should be in

The fix for this should be in BESR 2010 SP3 (9.0.3) - are you using this version?

If not, please update to 9.0.3 via LiveUpdate (reboot required) and try again.

Please let us know if this fixes the issue.

After live-update and workaroud not opening in a week

Thanks for your reply Chris.

I was exited to finally test the solution. After running live update and executing the work around, I opent GRO and select a backup from USB (2.0)

Then I put in my long password for the 128-bits AES encryption. The file doesn't open in a week! I aborted the process on our server. It's a HP Proliant server from 2007 with 8GB ram. Our Exchange database is 25GB.

It is faster to restore a BESR backup to an other pc/server and than export the mail via outlook.

Is there a better solution?

What chance have 2010 users got when it doesn't work in 2011!!!

Not only have you had this problem for over a year in 2010 but you've got exactly the same problem in 2011.

I have no confidence in Symantec anymore. Your backup solutions are a farce. When you reach for your backups you are already in the crap and you need to know they are going to get you out of it. YOUR'S DONT.

It's not like this is the only product that is completely unreliable. I've also experienced bugs in your Backup Exec software that made it impossible to restore a Windows 2008 Server OS (got the data backup but had to setup the server OS - a DC to make things worse) from scratch. This bug was fixed but it was way too late for me and I will never get those days back now.

For the record, the deleting RPAM_Cache.dat fix "solves" the problem in 2011. The fact that you have had a "solution" for this for over a year but not fixed a piece of mission critical software just proves what a dire company you are.

@ictmail@interrutges.nl: So

@ictmail@interrutges.nl: So it sounds as though the password issue is now resolved, right? The performance issue really is a different issue by the sounds of it. Are you able to just mount the recovery points (via windows explorer) on your server?

@TomT: to my knowledge, this issue should already be fixed in SSR 2011. What operating system are you seeing this issue on?

Server 2008 R2

I have also checked that there are no updates available

Any Update?

Have you confirmed that this is still an issue still in the 2011 version?

This should be fixed in

This should be fixed in 2011.

However, based on your earlier reply, it sounds as though it is not.

Are you able to easily reproduce this with 2011?

Should be fixed but it isn't

I've done another backup and exactly the same problem.

Had to delete RPAM_Cache.dat for it to accept password doing a granular restore.

OK, some questions in order

OK, some questions in order to narrow this down a bit:

  1. What operating system(s) are you seeing this on?
  2. What are you using as the backup destination (network share?)?
  3. How long is your password?
  4. Are you also using encryption?

1. Windows Server 2008 R2 2.

1. Windows Server 2008 R2

2. External SATA drive (system sees it as a a standard hard drive)

3. 8 Characters

4. Yes, Standard 128bit

I cannot reproduce this here

I cannot reproduce this here so there is clearly something different between what you and I are doing.

Are you using GRO on the same machine that you are backing up? Was this an upgrade from BESR 2010? If yes, has the backup job been re-created since upgrading?

Any additional information you can provide is going to help.

We are using GRO on the same

We are using GRO on the same machine we are backing up. This isn't an upgrade, it was a clean install on a new server installation.

Without knowing how your software works and the mecanics of how that file is created it is difficult to know of any other information that may be useful.

TomT: do you have a support

TomT: do you have a support contract with Symantec? If yes, please open a new case for this issue so that we can investigate further.

If you decide to go this route, please let me know what the case ID is.

And Still....

Running SR 2011 SP1.

Same problem re passwords.

Deleted the RPAM file, the password for the SERVERNAME_C_DRIVE file was accepted, but then it asked me for a password for the SERVERNAME_SYSTEM_RESERVED archive. The same job imaged both drives, so the password is the same. i.e. you can only have one password for each job, not on each source drive.

But alas, it will not accept the password.

Why does this happen version after version after version.....