SAP Disaster Recovery Plan

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.

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.

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.