The basic concepts behind taking a backup are well understood, but people are frequently surprised by the many ways backups can go wrong. First, we’ll explore the most common problems around SQL Server backup and recovery, so that you can spot any issues in your own environment. Then, we’ll talk about how to prevent these issues in the first place. The foundation of disaster recovery is having a verified backup in place, so the knowledge you’ll gain from this session could help to save your business.
We hate losing data as professionals. We should not make the simple mistakes that make it easier for this to happen.
Most of us that work as data professionals hate the idea of losing data. When the developer calls and says his test database is gone and backups were never set up, we may shrug our shoulders and offer to help next time, but we feel bad. We will try everything we can do to recover the data, usually going out of our way to give it our best effort.
We will lose data. There will be situations that are out of our control, and we have to accept that. However we should try not to make the easy mistakes ourselves that might cause data loss. I ran across a short piece on Five Sure Ways to Lose Data and I agree with the items, but I think there are a few more things we should watch out for.
One of the easiest mistakes to make to forget is to set up backups. Too often we implement new databases under time pressure, dealing with software that is dropped in our laps at the last minute. Security permissions are never documented and during the frustration of just getting something deployed, we may forget to set up a backup system, intending to do it next week.
Don’t do that. Get backups set up immediately. It’s quick, it’s easy, and you should have some automated process or script ready. As soon as you complete backups, invite yourself to a meeting to set up monitoring in the next day or two. That’s one of the other easy things to fix: ensuring your backup schemes are working by monitoring your servers. Your monitoring should include alerts for DBCC checks and high severity errors in addition to backups at a minimum. Automating this, or using a tool, are the best things you can do.
There are lots of other things we might ignore that can cause data loss, but if you get your backups working, you should be able to recover from most any situation.
I was talking with someone the other night about their database systems and they mentioned they had implemented TDE (Transparent Data Encryption) to comply with HIPAA regulations. This person had verified that they were backing up the Database Encryption Key, which you definitely need if you want to restore a backup from a TDE encrypted database. However they weren’t sure if the certificate that protected the DEK, and the master keys on that instance were being backed up. Probably most scary to me, they hadn’t tested any restores of the database.
Encryption is serious business, and if you are going to implement it in your databases, you had better be sure you understand how the various keys and certificates work. You better be sure you have protected your passwords, and that you can find them in the event of some issue.
Most importantly, though, is that you need to practice recovering your database to another instance. Preferably you’d learn how to recover on an instance that hasn’t ever enabled encryption as well as one that has a different SMK or DMK.
Practicing restores isn’t just about encryption and the potential for data loss because you don’t have a key. Practicing restores is important for all of your systems to be sure you have the skills to successfully complete a restore. It helps ensure you know where the files, tapes, disks, or any other resources are located. Most importantly it ensures that your backup process is actually running smoothly.
Please don’t assume your backup process works. Whether you’re an accidental DBA stuck with their first SQL Server, or a ten year senior DBA that has performed hundreds of restores at previous jobs. You need to test your process and ensure that you can perform restores on the systems you are managing.
Steve Jones
The Voice of the DBA Podcasts
We publish three versions of the podcast each day for you to enjoy.
It’s important that you backup your database. The most important thing you can do. However making backups isn’t enough: you need to verify those backups are good.
A humorous short video from Grant Fritchey (b | t) and RedGate on why:
Ideally you verify every backup every day, but that’s not always feasible. At least make sure you’re doing one backup from every database at least once a month.
Voice of the DBA 