Planning ahead: Disaster recovery (DR) for SAP

A full-proof disaster recovery (DR) strategy takes care of many potential threats to the SAP environment and acts as a survival mechanism for businesses at scale.

SAP — at the core of your enterprise — faces several potential threats that can paralyse your business. Only a good contingency plan can save the day.

Do your business-critical applications, say ERP or CRM, run on SAP? That’s a good choice right there. And to maintain continuous SAP availability in an increasingly complex interconnected application environment is no joke. We applaud you for keeping that up as efficiently as you have.

So, you’d already know that there are potential risks all around — shared technology risks, cyber-attack, natural calamities and so on. Since an ERP is integrated across critical business processes, impacting every area of the enterprise, any disruption could bring your business to a halt. At times, data loss and downtime are so long and severe that it can cause irretrievable loss to the company’s reputation.

To safeguard against these risks and more, you need a comprehensive disaster recovery strategy. Do you have one?

A full-proof disaster recovery (DR) strategy takes care of many potential threats to the SAP environment and acts as a survival mechanism for businesses at scale.

DR, like insurance, is an investment towards business continuity.

The purpose of disaster recovery is not to directly save cost, but to save opportunity cost in times of disaster — protecting the business from potential losses and irrecoverable damage.

In our experience, when we discuss DR, clients ask us a similar set of questions: What is the right DR? Should I build a DR for only critical applications? When should I switch to the DR?

To answer these questions, one must understand the difference between High Availability (HA) and DR.

High Availability is at an application or even at an application component level — say, database level or OS level. It is often automated. And it ensures continuity of business by covering for single component failures.

Disaster Recovery is at a site level. It is appropriate for cases when the whole of primary site is down, either due to natural or man-made calamity and would require days if not weeks to recover. It is the minimum readiness from IT in an alternate site for business to continue without major impact to end the customer.

The operative terms here are “minimum readiness from IT” and “without major impact to end customers”. It brings out two key aspects.

One, it will be idealistic to assume that all applications and features will be available in same scale and detail during DR.

Two, it will be equally idealistic to zero impact to business.

Now, let’s look at some questions.

Which Disaster Recovery?

While on-premise DR has been an obvious choice thus far, it also comes with high hardware and infrastructure costs, maintenance costs, constant need for additional space, dedicated IT support staff, susceptibility to data loss, and longer downtimes. A secondary physical DR site means investments in additional data center space, connectivity and servers. It also incurs additional operational costs — power and cooling, site maintenance, and manpower requirements. All adds up to high capital investment.

It doesn’t have to. You have a better alternative with cloud.

Cloud DR requires no onsite hardware building costs, it merely needs data-sync sized instances for normal time, is scalable on par with the growth of your business with practically no physical capacity issues, more flexible with pay-per-use models, easy connectivity from anywhere, anytime, using any device, smooth and quick backup with minimal configurations in a matter of minutes.

All in all, lower cost of operations and faster recovery times, assuring your business keeps functioning during and after any type of disaster by virtualizing each location where your data resides.

In addition, managed disaster recovery (MDR) or disaster recovery as a service (DRaaS) or cloud-based disaster recovery solutions for SAP involve a third-party service provider maintaining a virtualized copy of the physical data center that can be set up faster than traditional methods.

So, what’s a good (SAP) DR strategy?

Oh, we’re glad you asked!

1CloudHub’s SAP practice works closely and mindfully with organisations worldwide to manage their DR on cloud. Our experts work to ensure your SAP environment is always protected and backed up so that business runs smoothly. And this is how we do it.

App and DB Sync ups, Backups, User Connectivity during DR

Regular application and database sync ups and backups, storing and maintaining copies of electronic records in a secure cloud computing environment ensures that data can be easily recovered and/or failover implemented in the event of a man-made or natural catastrophe.

For both sync ups and backups, the tools and methodology form the cornerstone of DR design. Bandwidth available for initial sync up and subsequent, continuous sync has to be planned and implemented if required with QoS.

Typically, connectivity to DR site is planned from the primary site. However, in this case, if the primary site is down, user connectivity to the DR site may also be affected. Good DR design would mean thinking about these possibilities and preparing accordingly.

Depending on existing network and security policies, it could be from a secondary site, using BGP for automatic network routing, for instance. Or P2S for last-mile connectivity from anywhere.


The recovery time objective (RTO) and the recovery point objective (RPO) are two very specific parameters closely associated with recovery. The RTO is the duration within which the application must be restored to ensure uninterrupted business continuity. This is often associated with the maximum allowable or maximum tolerable outage. Say for instance, if your RTO is 24 hours, it means you’ve determined that the business can maintain operations for that amount of time without having its normal data and infrastructure available. If data and infrastructure are not recovered within 24 hours, the business could suffer irreparable harm.

While RPO dictates the allowable data loss — how much data can you afford to lose? It is useful for determining how often to perform data backups. Based on these two metrics our experts suggest the best data protection solution that would suit your business needs.

Cost of DR is significantly dependent on the goals for the RTO and RPO. A very low RPO, say below 30 minutes might incur high sync tool and network pipe cost. A very low RTO, say below 4 hours, would mean having hot standby, incurring higher costs.

Cross-region DR

While high availability deals with single failures within one region and protects your data in case of database failure, DR protects your data in case of an entire region failure. Database and sub-account replication enables replication between the primary and secondary regions. In case of a disaster, your application and database in the secondary region become active and replace the primary setup.

DR Drills

Drills form an important part of being prepared. We recommend quarterly drills. However, these drills are conducted on isolated network segments that do not impact production data.

In fact, you must mobilise DR planning early on, in the planning stage itself to align HA + DR strategy, like we discussed earlier in “Designing infrastructure for SAP migration: Important considerations.”

A good disaster recovery strategy must take into account your business’s existing facilities, the level of security required and budget, but also accommodate future growth. It must provide thorough coverage, better control and flexibility, tested and proven to meet and deliver upon accepted RTO and RPO for SAP. Today, managed disaster recovery has become an increasingly cost-effective solution for businesses, given favorable cost, risk and service attributes of the cloud.

Still on the fence about cloud DR? That’s okay. Speak to one of our cloud consultants today.

Sharing is caring!

In Blog
Subscribe to our Newsletter1CloudHub