Home > Glossary > SAP Disaster Recovery Plan

SAP Disaster Recovery Plan

Updated 3rd November 2023, Rob Morrison

Since SAP often forms one of the most important data flow components within an organization, SAP disaster recovery plan has always been top of mind for all stakeholders. There are a large variety of different disasters that can happen suddenly, and if you’re not ready for it – it’ll cost you severely; anywhere from irreparable damage to your data, to complete business loss. Almost every minutes of downtime is a disaster for a company, and every additional hour can run into thousands of dollars – and more – of additional cost.

This is why companies need to always be ready and able to minimize the possible downtime as much as they can. There are a few important terms for that, such as RTO and RPO.

RTO stands for ‘recovery time objective’. It represents the amount of time you can afford your company’s SAP systems to be offline. It shouldn’t matter what the exact type of disaster is that occured: network failure, power outage, a hurricane, you name it – you’ll want your SAP or HANA database back, up and running, within the “allowed” time period – and that’s exactly what RTO means.

Now, there are quite a lot of different assets and/or services that can become involved or affected in a disaster, and each of them has a different RTO. For example, banking systems or high-demand online stores measure their RTO in actual seconds, while a less time-relevant businesses’ RTO could be up to several days. Of course, there are a lot of different cases in between these examples, too.

sap disaster recovery

RPO is a recovery point objective and it will likely also be an important factor of your SAP disaster recovery plan. RPO represents the maximum amount of data (measured in terms of the data’s age) that can or cannot be lost in case of a disaster. Basically, some sort of data loss is almost inevitable, unless you’re mirroring your entire database at all times. This is where RPO matters. What is tolerable to your business? Just as RTO, your RPO varies a lot depending on the nature of your business. For example, stock trades may have an extremely sensitive RPO, while other businesses can afford much larger RPO.

There are several different options available when it comes to SAP disaster recovery. Some of them are cloud-based and are relatively new, while other solutions are somewhat older and use a different approach. The choice of SAP disaster recovery plans, in general, makes the whole process much more flexible, since you may more easily find a solution that better suits your specific business needs, including affordable RPO and RTO, affordable prices, acceptable disadvantages of a specific method, etc.

You can find various services that offer different SAP disaster recovery plans, each with their own benefits and shortcomings. When choosing a SAP DR solution for yourself, there are a few questions you’ll want to keep in mind:

What are the vendor’s scalability limits?
What are the fastest RTO’s and RPO’s they can offer, and does it meet your requirements?
Is this vendor – and its solution both easy to use and adaptable to your business’s unique needs?
How far can the vendor go in regards to customizability when providing a SAP disaster recovery service?

Typically there are two possible ways of implementing SAP disaster recovery plan:

Synchronous. As the name suggests, synchronous implementation of a disaster recovery plan means that there would be no changes to the “main” database until it gets a signal from a disaster recovery site about that the database is being updated.
Asynchronous. This one is different, in that the “reserve” database isn’t updated every time there’s a change in the “main” database. Instead, the disaster recovery database is updated later, most likely within a fixed time amount. This means more data being possibly lost in case of a disaster, but at the same time it lessens the burden that comes with updating the entire database with every change, no matter how minor it is.

Speaking of disaster recovery plans, there are several types of those out there, each with their own characteristics and shortcomings:

Traditional data recovery method. The name itself implies that it is probably the oldest method there is – two identical servers, the “main” one and the “reserve” one. Database logs are gathered from the “main” database and are sent to the “reserve” one. This method has a lot of drawbacks, the primary one being the uptime speed and the overall ownership cost. Nevertheless a lot of companies still use it as their primary option.
Using cloud services for data backup and recovery. This option could also be called the ‘economic’ one, since the overall cost of using Amazon Web Services or similar isn’t that big and can be handled by smaller businesses. Cloud services are mostly used by companies that don’t have a lot of frequent changes within their database, and the data itself is backed up every once in a while. It may indeed be a good option for start-up businesses, but overall security concerns make it a tough choice for bigger companies with more sensitive data.

Disaster recovery with Bacula. The Bacula Enterprise SAP module implements the official SAP BACKINT interface, which simplifies backup and restore of SAP, using traditional SAP database tools. The SAP module uses various techniques and strategies to back up SAP and can be combined with the Bacula Enterprise Oracle SBT plugin to allow direct data transfer between Oracle RMAN and Bacula Enterprise. Once the SAP module is installed, it runs backups and restores simultaneously, and works transparently in the background. The backup administrator can benefit from Bacula Enterprise multiplexing features to run backups and restores in parallel.

Regarding specific SAP disaster recovery providers, you can find answers to these and other questions about Bacula Systems by reading this whitepaper and this article. There’s also a free SAP disaster recovery plan template available here.

About the author

Rob Morrison is the marketing director at Bacula Systems. He started his IT marketing career with Silicon Graphics in Switzerland, performing strongly in various marketing management roles for almost 10 years. In the next 10 years Rob also held various marketing management positions in JBoss, Red Hat and Pentaho ensuring market share growth for these well-known companies. He is a graduate of Plymouth University and holds an Honours Digital Media and Communications degree, and completed an Overseas Studies Program.