This editorial was originally published in the Simple-Talk newsletter.
Imagine for a moment if you will. As a DBA, and as the protector of your organization’s data, you have implemented many safeguards to protect your data. You have set up periodic jobs to back up your databases; you check daily to ensure that the backups were actually taken; and you periodically perform test restores to ensure your backups work. In addition, you have established an appropriate backup retention policy and you store backups offsite. With all of this planning and hard work, you are confident that your organization’s data is safe. But is it?
What would happen if your backups, in transit from the data center to the offsite storage, were misplaced or stolen? Or what would happen if the backups at the offsite storage location were stolen? Sound unlikely? Not really. There have been many reported instances of backups being misplaced and stolen. In fact, I personally know of a multi-billion dollar company that sends their backup tapes to their offsite location using an employee’s car, then stores them in a locked, but very cheap metal cabinet that could be broken into in seconds with a crowbar. What would be the organization’s liability if their data was stolen? I’m even afraid to think about it.
Although it is unlikely that your backups will be misplaced or stolen, I personally don’t want to take the risk that this might happen to the backups I am responsible for. As you probably know, by default, data from a SQL Server database backup can easily be restored to any other computer and the data viewed. The exception to this is if the data has been encrypted, which is the exception rather than the rule.
In SQL Server 2008, Transparent Data Encryption (TDS) was introduced in the Enterprise Edition of SQL Server. This feature allows data at rest (such as backups) to be fully encrypted and protected should a backup be misplaced or stolen. If you are using SQL Server 2008 Enterprise Edition, I recommend you take a look at TDS and consider implementing it.
But what if your company doesn’t use the Enterprise Edition of SQL Server 2008, how do you protect your backups from prying eyes? Currently, your only realistic choice is to use a third-party backup compression program that offers data encryption as a feature (which virtually all do). This way, your backups, wherever they are located, will be protected and you can rest assured that your organization’s data won’t be compromised.
So my first question to you is this, do you think backup encryption is as important as I think it is? And second, how do you go about protecting your backups? Do you encrypt them, do you use some other form of backup protection, or are you crossing your fingers, hoping that you never face the situation of missing or stolen backups?
2 thoughts on “Are Your Backups Really Safe?”
At my current company we use TDE to encrypt our production databases and then use a third party tool to backup the files (also password protected), which is then collected by the company that stores our backups offsite at a secure location. How do we know it’s secure? We did a site visit first to inspect the facilities, it’s the only way to know for sure that it’s not just marketing hype.
Looking forward to seeing you over here in the UK at SQLbits in a short time.
Absolutely agree on this one!!
Given the budget crunch for where I work and the need for FIPS certified processes and a previous DBA who just did nothing from what I can tell I had quite the job cut out for me trying to get it all set up.
After about 3 solid days of work I have setup SQL jobs (using Ola Hallengren’s excellent backup scripts), but then had to take it a few steps further. Using PSExec and WinZip command line utility I was able to automate, compress, and encrypt our backups via 256-AES cryptography all using a standard SQL job. Best of all this was done with absolutely no budget impact whatsoever!! Gave myself a gold star for that one!!
Comments are closed.