Understanding Database Backup Strategies by Pinal Dave

Backup is one of the driest topics and it seems to be something non-negotiable for a DBA role. If we look into the fine prints of why someone should take a backup, then it is fundamentally for business continuity and to recover from disaster. The last mile of defense or these backups act like your safety net when everything goes wrong for you. There are multiple strategies organizations use when working with backups. Though this blog post talks about the backup strategy, we would like to bring out that the restore strategies are equally important. If you don’t have an effective restore strategy, then the backups is of no value. The idea here is to answer some simple questions as we build our backup strategies:

Know your What?

The basic building block of any effective backup is to know what we are going to backup. This involves multiple strategies – for mission critical databases which the organization depends we will have aggressive plans and for databases which are lesser critical we will have a different plan. There is no one size fits all option. Databases are tough and sometimes tedious in the recovery process, so we need to be cognisant of how we do them.

Know your Where?

The basic trait of an effective backup is to protect us from all kinds of possible failures that can happen for our database as well as our backups. We have seen organizations take this matter seriously and have multi-factor backup strategies that make it interesting for a process to be in place. There are DBA’s who make backups from DB to Files to Tape or from DB to local files to FTP remote site or DB to files to Cloud backup or DB to Tape to remote storage server or it can also be from DB to SAN to shared storage etc. All these are valid and possible strategies that DBA’s use and there is no right or wrong answer. It is completely organization dependent and their SLAs for RTO and RPO. Though Local storage gives cheaper alternatives and can help in recovery process faster, it can also become a single point of failure if the whole site goes down because of natural disaster.

Know your When?

For systems that need to be 24 x 7 x 365, it is important to know the database access patterns before any backup can be taken. There are two fundamental question to be answered in this “When” timeframe. Those are – What is the frequency at which I need to take a backup and the second question is – What is the time I need to schedule this backup.

The frequency question can be answered easily if we understand what would be the data loss if a disaster struck just minutes before the next backup. How much data can we afford to loose? How long would it take to bring database online and how much time will it take to recover lost data? All these are business challenges that one needs to answer before taking a call on frequency.

As far as the second question is concerned – we would want to run the backups when there is minimal load on the system. Backups do consume resources on the servers and there can sometimes be visible performance degradation in the application response when backups run. Normally backups are run in scheduled pattern of maintenance windows by DBA’s every day or in a pattern. Having said that, whenever business starts in the morning – the busiest time is in the first couple of hours when people are trying to login and start their day. So we need to make sure if there are any backups run as part of maintenance automated scripts, they must finish well before the day could start.

Know your AddOns?

In this era, there are a number of capabilities the platform can give and it is important for us to know which of these are under production. There can be different resource needs if we use any of these techniques like Compression or Encryption. In SQL Server world, it is one of the given tasks that the backups needs to use the compression techniques. It minimizes the IO needs and the backup for most cases completes faster when compared to backups taken normally.

We have seen that organizations sometimes have to protect their data and resort to backup encryption techniques too. In this case, it is critical and most important to keep the encryption key also safe and available on the DR site. If we fail to take a backup of the same, then the backups can be void because we will not be able to recover the same if the keys are lost.

Do you test it?

All your backups make sense only when we are able to restore the same in hour of disaster. There is no point in taking a backup and not testing them from time-to-time. Databases like SQL Server have an option to validate the backup file once it is written to disk. It is advisable to test them in periodic fashion and always try to create a backup of your backup. We have seen DBA’s cautious because it is better to invest the extra ounce of overhead than being sorry when disaster strikes.

Conclusion

As we sign off, we are sure we could bring out some of the basic fundamental building blocks of working with backups. Though these are not written on stone, we assume that as seasoned DBA’s you are well on top of your backup strategies. If you have not planned for the same, we hope this blog will get your started in that thinking process. It is a journey which any DBA needs to refine over a period of time and look for new capabilities that the platform can offer to enhance the experience of how backups can be taken.