Restoring SQL "error occurred when attempting to initialize encryption"

[Aaron_Blosser]

I've been running backups just fine with a B2D device using encryption (they were originally backup to tape and I never turned off the encryption).

The backups all work fine, and I can restore files just fine from those.

However when I try to restore a SQL 2000 database to either it's original server, or a redirect to a different SQL, it's always failing. I think it's been doing that since the upgrade from 10d to 11d and this is just the first time I've done a SQL restore job. As mentioned, file restores are working fine.

The error pops up immediately after the job is submitted and says:
"Final error: 0xe0000f0c - An error occurred when attempting to initialize encryption for job."

In the event log it logs error 34113 and has the same error message above.

Our Backup Exec server has 11d with hotfix 2 and 6 installed, and the last thing I just tried was to make sure the remote SQL server has the updates for the remote agent, but it still fails on the restore.

The encryption key used by the backup is the only one and it's set as the default. For future B2D backups I'm making sure to turn encryption off and I'll look at file system encryption instead as per something I read on the Symantec KB.

Any clues? Help. :) It's weird that for the same backup set, files can restore fine so whatever "encryption" problem is going on isn't affecting those.

[Gauri_Ketkar]

Hi Aron,

Please perform a SQL backup and without encryption and test restore job.

Update us on the same and revert for any further Query



Thank you
Gauri

[Aaron_Blosser]

After discovering that my encrypted backup jobs don't restore (the SQL stuff anyway), I immediately disabled the encryption on my backup jobs.

I just did a test restore of a database that backed up since then and it restored just fine.

We do have a requirement to encrypt our tape backups at least, so it'd be nice to get that working. At least for now I can rest a little easier knowing that our backups, while unencrypted, can at least restore in case of disaster recovery.

[Amruta_Bhide]

Hello,

Are you using Compression along with Encryption?

Thanks,
Regards

[Aaron_Blosser]

Yes, we're using software compression for the backup-to-disk jobs.

[Deepali_Badave]

Hello,

Please run the sgmon before running the backup job.

How to create SGMON.LOG
<<>>

Regards,

[Aaron_Blosser]

... finally back from vacation :) ...

I ran a test backup using the same settings that were causing me problems: Backup to disk, encryption enabled, software compression enabled.

I ran the sgmon beforehand and logged the data... Backup Exec 11d has slightly different options on what to log, compared to what the link shows (there were no "notification" and "alert" buttons, so I just selected "engine", "storex", and "beserver")

The backup job reported success, so is there anything in particular I should look for in the logged output? Or should I now go ahead and try a restore which was where I was getting that weird error and see if the logs shed any light on that aspect of it?

[Aaron_Blosser]

By the way, when doing a restore, this is what shows up in the sgmon log file related to the error:

beremote: 01/03/07 12:06:15 LP_ENV::MsgError: error 0xe0000f0c processing object

Curiously, I did a test backup/restore of ONLY a single database (the same one I was trying to restore way back when) and the restore of that worked fine. Hmm...I did use a *different* backup-to-disk location for that test, so maybe that made a difference. I'll do some more testing to make sure the problems can be replicated and wasn't just something "in the air" for a few days last month with those particular backup jobs. I'll also test it by doing a mix of SQL, file, and Exchange backups like our normal jobs. Also, the errors I got when restoring showed up in the weekly tape backup as well as the daily B2D backups, so it's probably not related to the B2D functionality at all. It's just quicker for me to do testing using the B2D sets. :)

[Aaron_Blosser]

I was able to recreate the error by doing a test backup that included a file as well as a SQL database. On trying to restore the database, I'd get that error.

However, if my test backup contains just a single database, it restores just fine. What an odd thing...

[Brian_Coverston]

I found the answer to this.  It is a bug in Backup Exec 11d.  If you also restore the LAST item in the backup set, you can restore any other item, and it will work.  So if you backup 500 databases encrypted, and need to restore one in the middle, also include the LAST one on the list.

Given that, I would highly recommend making a database named ZZZZZ on your dbserver so it is always backed up last, and you can always overwrite it.

[Patty_McGowan]

Brian,

That is correct and was a workaround.

There is a Hotfix that has been released to correct this issue.

It is HotFix 14 for 11.0.6235

http://support.veritas.com/docs/287663

Patty