What is a Standby Database and How Does This Compare to Using Backups?

What does it meant to have a standby database, how do they work, and how are they different from traditional backup and recovery? In this blog, I will provide a quick overview of a standby database, how it is different than using backups, and how backups and a warm standby are complementary in a Disaster Recovery Plan. 

So what is a standby database?

I always like to explain things by keeping it simple and this is not going to be any different. The easiest way to understand what a standby database is is to think of it like this: You have a production database used by your application(s). To protect this database from disasters; which could be something like hardware failure or even human error, a secondary database system is created which is an exact copy of the production database. This secondary database is then kept up to date with all the changes that happen on the production database.

Now this is a simplified way of looking at it, but at the core, this is what a standby database is, it is a secondary database that is a copy of the production (primary) database which is being kept up to date. If disaster strikes, the standby database is activated to become a new “primary” database. Your applications can then be pointed to use this database.

One more thing to highlight here is that there is a slight delay between the primary and standby database, anything from 1 to 10 minutes or more, depending on how you configure it - and of course depending on the underlying infrastructure being used like network capacity and speed. 

There is a lot more to standby databases and various options available - like performing a role switch between the two configurations - not to even mention the process to create the standby database in the first place - but do not be scared, this is not that difficult, especially if you have a tool like Standby™. So if you are interested, I highly recommend you review Standby™ to better understand all the great features it provides to help you manage these standby database configurations.

What about backups?

This brings me to the next point. Some sites only rely on backups for their DR solution. And this might seem like a good solution initially, but there are a few things you need to be aware of. 

• Backups take time and so do restoring those backups. Time might seem like nothing when all is going well, but when disaster strikes, you might not have hours or days to first establish a DR site, then get the backups from off-site storage, then restore them. This can be a time consuming process and costly.
• The business will have expectations - and this is where things like RTO (Recovery Time Objective) and RPO (Recovery Point Objective) come into play. You have to agree these with the business. You might find that your expected 4 or 6 hours to get a system back to running state, is not what the business requires or expects. They might need it back in 5 minutes when a disaster strikes... This is when selecting the correct DR solution for your databases and applications becomes important.
• Taking the above two into account we should also consider the following: backups are taken at a particular point in time, they do not run all the time, but at scheduled intervals. If you have to perform a restore and recovery, would you be able to recover your backup to the last minute before the outage happens? Highly unlikely! If the system is down due to corruption, as example, then when you restore the backup - you might only be able to goto the last backup time, which could be a day old, which means you potentially lose 1 full day worth of data! That is HIGH RISK! And most companies will not accept this anymore.

Now this does not mean backups are useless. Not at all, backups are a crucial part of protecting your data and in fact it complements your Standby Database. So why do I say this? Well, keep in mind the standby database is being kept up to date as changes are happening to the primary database.  Ready at any point in case disaster happens. But what if you find that someone by accident deleted a record out of your database a day ago and you need that back? How will you do this?

You do not want to lose all the current data and restore everything back, but you can use your backups to restore the database to another system, then get the data you need and update your current system with the required data.

Now this is a simplified way to look at this, but I hope you get the idea. On another note, what we are seeing is that many sites will have more than one standby database. One which is kept up to date with the primary to the last minute or two, the second one is configured with a delay - meaning it is kept behind the primary for a specified time, the data is available local to recover it, but it is kept at example 12 hours behind, just in case something like the above happens.

This second database then opens up a number of extra options - like using it for snapshots - but that is not the focus of this blog.

In summary, backups complement your DR solution. Together they help make sure you can meet your required RPO/RTO agreements with the business but also make sure that your data is protected at different layers.

To close this off with a basic example: many sites run their backups off their standby database. If you think about it, your standby database is a copy of your primary database which is being kept up to date. So offloading your backups onto the standby database helps save valuable resources like CPU and IO on your primary system.

For more information on this topic, I highly recommend you review the following blog posts:

https://dbvisit.com/blog/rto-and-rpo-disaster-recovery-planning
https://dbvisit.com/blog/how-perform-dr-test-dbvisit-standby-v9