November 21, 2014 at 7:46 am
Can anyone point me to a simple summary of the new backup encryption? I've found a small handful of articles, but apparently I have some sort of mental block where keys and certs are involved.
I'm trying to determine if this is a viable replacement (for our purposes) for SQL Backup, which we started using primarily for the compression and encryption. We don't have issues with SQL Backup, I'd rather not install additional utilities for native functionality.
What I can't seem to understand is how one goes about restoring an encrypted backup onto another server. When one restores the master key onto the destination server, what happens to the existing key on that server?
Right now, we have backups off-site in third-party storage, and all we need to restore is the .sqb and the password (and the SQB converter). With native encryption, we need the .bak, the keys, the cert, and the password?
November 21, 2014 at 8:15 am
sminar (11/21/2014)
Can anyone point me to a simple summary of the new backup encryption? I've found a small handful of articles, but apparently I have some sort of mental block where keys and certs are involved.I'm trying to determine if this is a viable replacement (for our purposes) for SQL Backup, which we started using primarily for the compression and encryption. We don't have issues with SQL Backup, I'd rather not install additional utilities for native functionality.
What I can't seem to understand is how one goes about restoring an encrypted backup onto another server. When one restores the master key onto the destination server, what happens to the existing key on that server?
Right now, we have backups off-site in third-party storage, and all we need to restore is the .sqb and the password (and the SQB converter). With native encryption, we need the .bak, the keys, the cert, and the password?
see my article at this link[/url] 😉
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
November 25, 2014 at 10:05 am
Thank you, that did help. If I'm understanding this correctly, restoring to a different server won't cause conflicts with its existing keys, as long as the cert name is unique.
I do think that the added complication to a DR scenario of having to find the cert & key backups might be more of an obstacle for us than the SQL Backup license cost.
November 25, 2014 at 12:41 pm
sminar (11/25/2014)
Thank you, that did help. If I'm understanding this correctly, restoring to a different server won't cause conflicts with its existing keys, as long as the cert name is unique.
Cert names within a database must be unique, you could have a cert called Bob in the master db and also in the AdventureWorks db 😉
Since the cert in master is used to encrypt backups focus here though.
sminar (11/25/2014)
I do think that the added complication to a DR scenario of having to find the cert & key backups might be more of an obstacle for us than the SQL Backup license cost.
Maybe, but then if it's that difficult for the DBA to quickly obtain the cert backup maybe review this process. Personally i would create the cert on the DR server as soon as it's created on the source, not wait until a DR scenario. Also DR testing may require you to online the DR database, you'll need the cert in place for this.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply