NOTE TO READER: KingsBridge and Dbvisit have entered into a partnership with guest posts going to each others blog.  This post is from Chris Lawless, VP of Product Management.

As Dbvisitors, we talk to a lot of people about Disaster Recovery. At conferences, Oracle events, partner meetings and in day to day life we end up talking about DR all the time. You might call it the world we live in. We often get asked about backups and people inquire if backups are ‘enough’. So let’s talk about it.

Backups! First I have to say that I love RMAN. I remember making scripts to do hot backups, cold backups, full backups, partial backups and having to work around schedules to get this all done. Then Oracle introduced Recovery Manager (RMAN), and each version kept getting better and better. It really simplified the job of the DBA, allowing us to concentrate on thinking about the big picture of backups vs the tedious task of backups. My colleague, Anton Els has a great blog about RMAN and its many uses.Dbvisit Oracle Standby

I recently learned of a great new feature in the Oracle Cloud, the Database Backup Service. You don’t have to learn anything! You just take the RMAN knowledge that you already have and with the Database Backup Service the backups now point to the Oracle Cloud! This is a great way for you to keep multiple backups all in one area, safe and secure in another location and you can start your journey exploring the Oracle Cloud offerings.

Backups are still a fantastic strategy. Make no mistake backups are actually part of a balanced Disaster Recovery (DR) plan. A few months ago I talked about how 3-2-1 plans are very effective when talking about backups and DR.

But here is where they differ. Backups are typically done at certain times of the day or week. You may take a full backup once a week and then combine that full backup with some partial backups every day. There are three major weakness points when it comes to backups.

The first weakness is that you may not have everything backed up. If you backed up last night and had a disaster today, do you have all of the archive logs since then in order to have a full recovery? It might depend on what type of disaster occurred if you have the archives or not. You might if you had a problem with one server but what if your production data center went down? This is where DR excels.

The second weakness is that if you do have a full backup and all of the relevant archive logs… do you have a machine where you can restore them? Like the above scenario, this might be achievable if it is one server or two but what about the event of a true disaster such as a fire or tornado? Again this is what true DR is all about.

The third area that we can look at is that of time. Can your business meet the SLA (Service Level Agreement) required by your RTO? If you have a good backup… how long will it take to restore from that good backup? Additionally, how long will it take to have all of the archive logs applied? Have you tested this? Have you tested with the production volume and machines?

These are all reasons why having a proper DR plan and a DR solution are required to meet RTO and RPO objectives set by the business. A database backup strategy will not be backing up nightly but will have continuous streaming of the archive logs from the source database to the standby site. This means not worrying about nightly backups as the standby database will be just one archive log behind the source.

There is no need to worry about if you have a database pre created or a server set up. The very nature of the DR site is that everything is already pre-created and running. The only thing you need to do is point your application to the standby site and you are ready to go. No guesswork required. The standby database can even be a Cloud database.

And it goes without mentioning that the standby database could be in a different geographical area so as to avoid weather or natural disasters. As mentioned with backups, we will have to worry about the time needed to restore, but this is not a concern with disaster recovery. The standby database is there waiting for you to turn it on. No need to restore at all.

A bonus feature of having a proper DR database is that you can actually run your backups off of your standby database. This can alleviate pressure from the source database. Use the standby database server’s CPU, memory and resources vs your primary’s.

Having backups is important, but that does not negate the fact that they are not perfect in a true disaster. They are a useful part of a DR plan and using them in conjunction with a standby database will ensure that your business is ready for anything.