Six ways to protect your database backups

March 31 was World Backup Day. If you are like me, you probably spent most of your day burning old CDs to tape storage.

I often see forum posts from accidental administrators who want to know how to recover data without a backup. The short answer is, “Now is a good time to work on your resume.” The longer answer is, “Recreate all your data.”

But the truth is that you shouldn’t ever be in this position. The number one job for any administrator is recovery. If you can’t recover, you can’t keep your job.

So, here are six ways for you to help protect your backups and your job.

Know What You Need

Many of those forum posts share a common thread, which is this: the contributor clearly does not know about the system he is tasked with recovering. So, the first step is to start making a list of all your servers and applications. Ask people the simple question, “What are the critical systems and applications you work with every day, week, and month?” Don’t forget to answer these questions yourself. Make a list, use it as a reference, and keep it updated. This is where monitoring tools that have auto-discovery are your best friend.

Configure Your Backups

This seems like something Captain Obvious would tell you, but yeah, configure the backups. It’s not enough to just know what needs to be backed up, you need to make sure backups are in place. Take care to note data volume here, as you may not want all your backups happening at the same time and flooding the network. Or, worse yet, having your backups run longer than 24 hours, causing your backup software to start a new day before the previous day is complete. Good times.

Verify Backups Are Happening

You must build a process to ensure that the backups are happening. My preference here is to make sure I have three pieces of information. The first is that the backup job ran without error. The second is that the backup media is available. The third is that the backups remain consistent with our RTO and RPO requirements.

Test Your Recovery

Backups are valuable, but restores are priceless. You should be testing your recovery process on a frequent basis. Many companies do DR testing once or twice a year. I find that the volume of data grows far too much in that length of time, making DR exercises difficult. I advocate frequent testing of the recovery process to verify that the backup media is good, and that the RTO and RPO requirements are being met.

Protect Your Backups

For database backups, I like using passwords and encryption. Anything you can do to take an extra step of security to protect that data is worth your time. You should approach your backups with a very simple concept: assume it will be lost or stolen. If it was lost or stolen, make sure you minimize your risk by protecting the backup in some way.

Consider Extra Copies

If your data is critical, you want to consider having extra copies of your backups. I like the idea of using a mix of offsite tape storage and a cloud backup provider. That way I reduce my risk by storing different formats in different locations. Just make certain that you have defined an RPO and RTO for each method being used.

Summary

Backups are necessary for your business continuity planning. It is often easier to build a recovery plan first because that will often dictate your backup strategy. Whatever backup strategy you deploy, these six steps will help you ensure that your next disaster does not result in a resume-generating event.

  • Very good article and group discussion here. Backup has come a long way. I did spend some time with a SolarWinds engineer discussing their new cloud backup solution and it looks good. I have been around long enough to know that IT always cycles and there is a big move to "cloud" so I'm just wondering how long it will be before companies start saying "hey, we have storage in house, why aren't we keeping stuff here."

    But I have learned that no matter where the data is good backups are important. (nope, vital)

  • We're starting to think just that... we are considering moving back to Net Backup possibly now as an option.

  • ecklerwr1​ LOL, you may be on to something here.  We may have the same challenges because we are using the same solution; we also use CommVault.  While our CommVault guy seems really knowledgeable it seems that the product is a beast to manage with maybe too many options and too much complexity.  Maybe backup is a case where less is more?

  • We have the same problems byrona​!  I think we see some of the same things in our environments.  We standardized on commvault and that backup software has so many knobs and settings on it... it's like some devs just kept adding features for 20 years and never depreciated anything.  There are 3 or 4 ways to do anything in it.

  • One of the challenges is that folks <cough> Management <cough> often significantly underestimates the amount of time that goes into managing and maintaining backups for a relatively large set of systems; especially when you have multiple different backup methods that are being managed.  I have seen where the management of backups in this type of environment is assigned as one of many tasks to a single individual and then when things fail there aren't any backups, not because it wasn't configured but because the person managing it wasn't making sure it wasn't failing and testing it on a periodic basis as you have suggested.   Managing backups properly can easily be a full time job for one or multiple individuals depending on the size of the environment and it's important for the decision makers to understand this.

Thwack - Symbolize TM, R, and C