I saw a question posted recently about someone that had disabled TDE and was still having issues restoring a backup. This doesn’t seem like that should be an issue, but it can be. A little testing shows how.
Let’s assume I have an encrypted TDE database. If I run a query, I can see the status as 3, which is encrypted.
If I take a backup at this point, the backup will be encrypted, and to restore this on another instance, I’d need to first restore the certificate. I don’t want to do that, so let’s remove encryption. This is a simple command
ALTER DATABASE TDE_Primer
SET ENCRYPTION OFF;
This runs quickly.
If I now query for encryption, I see this.
A one means that this is an unencrypted database, but a DEK (Database Encryption Key) exists. If I were to detach and examine this database file with a hex editor, the pages would be decrypted.
I’ll now take a backup and move that to another instance. Once I’ve copied that over, I’ll try to restore the backup. In T-SQL, I’ll see this:
Why is this? The database was decrypted, as was the backup. In fact, if I open my backup file in a hex editor, I can see row data.
When SQL Server goes to restore the file, it reads part of the header. In here, the process must detect the DEK and try to decrypt that key. However, since this new instance does not have the certificate, this doesn’t work and an error is thrown, despite not needing the key since the data isn’t encrypted.
The issue here is the DEK still exists in the source database.
Let’s fix this. I’ll return to my first instance and the original database that was TDE encrypted and now is not. I can issue this:
DROP DATABASE ENCRYPTION KEY
Once I do this, it completes quickly. This is a standard DDL command, but one that’s not often used.
Once I do this, I’ll take another backup and return to the second instance. Now when I try the restore, I see this:
If you’re having issues restoring a database that used to be TDE encrypted, try removing the DEK and then backing it up.