Restore encypted SQB issue
reulberg
Posts: 11
I seem to be having a strange issue restoring an encrypted .sqb file
I have 2 instances.
the restore on instance 1 of an encrypted sqb worked fine.
attempting to restore a different encrypted sqb on instance 2 gave me this error:
Failed to encrypt information. Win32 error code: -2146893809.
I have 2 instances.
the restore on instance 1 of an encrypted sqb worked fine.
attempting to restore a different encrypted sqb on instance 2 gave me this error:
Failed to encrypt information. Win32 error code: -2146893809.
Comments
I suspect that your issue maybe more related to SQL Backup than the SQL Virtual Restore.
Can you please run the following SQL Backup commands in a new query window to verify the encrypted backup file used against instance 2:
A support call from this forum post has been created for you, call reference F0057009. Please reply with the results of running the above query via e-mail to support@red-gate.com and place the call reference number F0057009 into the subject field of the e-mail.
Many Thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com
I am sorry to hear that you are having this issue.
Are these 2 instances on the same machine or different machines?
Where is the Win32 error? Coming from SQL Server or a HyperBac log file?
Would you be able to paste me the output from SQL Server and the log file contents from Program Files (x86)\Red Gate\HyperBac\Logs or send them to support@red-gate.com referencing this forum post.
Thanks,
Redgate Foundry
I will script the SQL virtual restore actions and post the output momentarily -- I was using the sql virtual restore Gui when I encountered this error.
Matthew: 2 instances of sql server on the same physical box. I am not sure of the origin, I will run the script version of the sql virtual restore commands, and email the results as requested.
Thanks![/b]
When I first encountered this error I was using the gui, and the gui doesn't allow one to proceed past file selection.
When manually executing a script, it throws the same error, but completes with a usable DB...
Requested info emailed.
due to the error, I cannot automate this restore job.
Two SQL Instances on the same server. Using SQL Virtual Restore (SVR) wizard against one instance you can successfully an encrypted SQL Backup .sqb file. However, using the same SQL Virtual Restore wizard on the second instance restoring a different encrypted .sqb file the process fails with the reported Win32 error code: -2146893809.
The server that creates the encrypted SQL Backup .sqb files, are they from the same server? Or from different servers?
What version of SQL Backup creates each .sqb file you are using with SVR?
What version of SVR and HyperBac components are installed?
The .sqb file that restores successfully on the first Instance, are you able to successfully restore this file using the SVR wizard to the second instance?
On the server where SVR is installed, can you please reply to support call F0057009 with the following Hyperbac files:
- Status.dat, openstatus.dat and hyperbac.conf from C:\Program Files (x86)\Red Gate\HyperBac\bin on 64-bit machine or C:\Program Files\Red Gate\HyperBac\bin on 32-bit machine
- Service.log and any other logs in C:\Program Files (x86)\Red Gate\HyperBac\logs on 64-machine or C:\Program Files\Red Gate\HyperBac\logs on 32-machine
Many Thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com
The .sqb file is from the same server
What version of SQL Backup creates each .sqb file you are using with SVR?
6.5.1.9
What version of SVR and HyperBac components are installed?
hyperback: 5.5.1.10; SVR: 2.3
The .sqb file that restores successfully on the first Instance, are you able to successfully restore this file using the SVR wizard to the second instance?
No, it will not let me get past the file selection screen.
Requested files zipped and emailed.
in the
[OS drive]:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
directory, the account that Hyperbak service was running under didn't have 'full control' permissions. Once that was addressed, smooth sailing.
Many thanks to Red Gate support for figuring it out!