Easy: Restoring from a RAID 1 device

Unfortunately something rather disastrous appears to have occured. I loaded up the backup disk, and found it nearly empty (928GB free of 932GB). This was not the case last time I tried a restore job (the disk was nearly full, and included several useful backup sets).

While the lost backup was not crucial, I am trying to prepare this equipment for potential backup restoration processes in the future and it now appears some part of the process of catalogging and inventorying this tertiary disk in fact erased the concents. Could someone with a keen eye for error maybe go over my earlier posts and point to where that might have occured? Keeping in mind that this disk had all its contents intact right up until the last error I saw on March 11th, and it has been disconnected from all devices (and power) since then.

Good afternoon and thank you for your patience. I was pulled onto other emergency projects, but have finally found the time to return to this issue.

1. Check!

2. Check!

3. Fixed - account did not have associated mailbox. Created one.

4. Fixed - sent an email from my account after creating mailbox.

5. Fixed - sent an email from the backup admin account to my mailbox.

6. Check!

7. Fixed - waiting for account to propogate.

8. Check!

After the account propgates to the Global Address List I will re-attempt the restore, and I'll post the results. Thanks!

Would you pls confirm the following (verbatim from KB) :-

1. The account must be an Exchange Full Administrator (Exchange 2003), Exchange Organization Administrator (Exchange 2007), and Organization Management (Exchange 2010) at the top level of Exchange.
2. The account must be a Domain Administrator. (Recommended, ensure that Domain Admins is a member of the Local Administrator's group on the Exchange Server)
3. The account must have an active mailbox on the Exchange Server.
4. The account must have received an e-mail via the mailbox.
5. The account must have sent an e-mail via the mailbox.
6. The account must be named so that it is unique within 4 characters.
7. The account must be visible to the Global Address List, "Unhidden".
8. Make sure the default system logon account of Backup Exec and Backup Exec Service Account are the same.

Oddly my update to your comment didn't seem to post, which is too bad because I included a lot of details.

Your tip was very helpful - after removing the config files and re-sharing the drive I was able to load it up as a second storage device. I inventoried and catalogged and this time, when I started a new Exchange restore job, the older backup sets were visible (yay!).

I started a restore job for just the single mailbox I need and unfortunately it threw an error related to credentials:

"The job failed with the following error: Cannot log on to EWS with the specified credentials. Review the resource credentials for the job, and then run the job again."

I checked my share first to confirm that all the permissions were clean - confirmed that Everyone had full access, but just to be safe I added the network admin account I use to manage the server as well as the backup exec System Account ("system-backup'). I drilled down into the advanced options and added both to the Permissions table there as well.

Back in Backup Exec I ran "Test Credentials" and all the results came back "Successful".

I tried the restore again, and this time I got a different error:

"The job failed with the following error: A communications failure has occurred between the Backup Exec job engine and the Agent for Windows."

I feel like I'm really close, but I am at a loss for how to proceed. Any advice you can offer would be greatly appreciated!

Great news, and less great news.

@VJware - your tip about removing the config files was excellent, and post-removal I was able to mount the shared backup as a second storage device. I did an inventory and catalog and, sure enough, when I went into Exchange restore options for my server I found the old backup sets. Woohoo!

Sadly, the restore job failed.

"The job failed with the following error: Cannot log on to EWS with the specified credentials. Review the resource credentials for the job, and then run the job again."

I check to make sure my network share permissions were clean (confirmed - Everyone has full access).

Then I ran the Test Credentials function in the restore wizard and all my credential tests came back successful.

I tried running the same restore job a second time and got another failure:

"The job failed with the following error: A communications failure has occurred between the Backup Exec job engine and the Agent for Windows."

Honestly, I'm surprised to see a different error - I would have expected the same issue with EWS login credentials given that I was unable to find the EWS login credential configuration.

Any additional tips would be greatly appreciated!

Thanks for that super helpful link! I'm going to read through before I try the solution recommended in the earlier comment, if only to familiarize myself with the way the system works.

In our case the entire backup process is stored to the same disk, including all inventory and catalog files, and that entire disk is mirrored on to a second disk that is pulled out on Monday morning (when no backups are running) and replaced with the next disk in queue.

Good morning VJware,
 

First some more details of my efforts:

My first attempt was in fact to remove both the primary and secondary drives from the stardom, and then to put the old disk into the primary drive slot under the presumption that Backup Exec would automatically see the old backup sets. When I tried to do a restore job, however, it was still showing the same backup sets from the recent disk (that I hadd removed). I presumed (perhaps incorrectly) that this was a cache of the newer inventory so I tried to run an inventory job on the old disk, and the job failed with an error that unfortunately I did not record. My conclusion (again, possibly erroneously) was that there was some sort of configuration on the stardom or disks that prevented me from loading up the old data directly from that setup. My experience with RAID configurations is, as you can probably see, very limited.

Since I had also done a restore job about two years ago with a third party IT team, and during that process we had removed the hard disk from it's stardom enclosure and accessed the information from a networked workstation (regrettably I do not recall exactly how) I purchased a usb enclosure and set up the hard disk as a new drive on my workstation, shared to the server running B.E., and when it failed to load up the storage device I posted here.

Today I will try your recommendation about the changer.cfg and folder.cfg files. *fingers crossed*

Hmm if you are doing what it appears you are and in effect flat file copying disk based backup sets, by extracting a mirrored disk to a vault which is kept offline whilst more backup operations take place, then you are going to have all sorts of problems with inventory and catalog information being mismatched (as well as possible drive letter issues if GRT is involved) If this is the case there may be no easy way to restore as lots of manual steps wil be needed to get things consistent.

See this document to understand why

http://www.symantec.com/business/support/index?page=content&id=TECH176061

It might be easier if your catalogs and BEDB.BAK are also stored on the disk that you swap out as then you would at least have a potentially matched set of the 3 key components of Backup Exec.

In your scenario I think I would install a clean version of Backup Exec somewhere and then attach that disk and run inventory and catalog jobs so that new references are created with no way to mismatch with historical data still on the backup server. However in the long term you might want to reconsider your backup solution (topology and process design)

Why not insert the oldest disk into the Stardom itself so that it is recognized by BE as the original storage ?

The other option may work. Copy the contents of the oldest disk into a network share except the changer.cfg, folder.cfg files. Try creating a Disk Storage from BE's interface now and point it to this network share. If this gets added successfully, run an inventory and catalog of the storage device and check if the restore selections are available or not.

Though, I would still recommend putting back the oldest disk into the original enclosure and running a restore from there.