Abstract
As devices, systems, and networks become more complex, there are simply more things that can go wrong due either to man-made or natural disasters. See the options available with SAP HANA for disaster recovery that help organizations keep business running smoothly in such circumstances.
Key Concept
SAP HANA provides a single platform to extract and analyze massive amounts of structured and unstructured data in real time from multiple sources such as social media, blogs, online reviews, emails, and discussion forums. The analyzed information helps customer to answer specific questions, increase revenue, and make accurate and timely decisions. The analyzed information and the data that is accumulated over the years is the backbone for an organization. If something happens to the data due to natural or man-made disasters, business can come to a halt. Making use of the SAP HANA disaster recovery features can save companies from such an outcome.
Learning Objectives
By reading the article you will be able to:
Nowadays most every company has its business continuity plan that helps during an unfortunate event such as flood or earthquake. A disaster recovery plan is part of business continuity plan focusing mainly on the restoration of IT infrastructure and operations after a crisis.
There are two important terms when it comes to a disaster recovery plan: recovery time objective (RTO) and recovery point objective (RPO), as shown in Figure 1.
Figure 1 Disaster recovery concepts
RTO is the target time in the future to get your application back online and running after a disaster has struck. The goal here is to quickly calculate how much time is required to recover. The cost of the disaster recovery option varies with the time. The lower the time to recover the higher the cost. For example, if your organization’s RTO is three weeks then you may able to invest in a less expensive recovery option, whereas if it is four hours then you need a higher budget and high level of preparation.
RPO is the target time in the past from which the system will be restored. The goal here is to determine the time between data backups and the amount of data that could be lost in between backups during a disaster event. The data backup time depends on how long your organization can afford to operate without data before the disaster happens. For example, if your organization can survive with two days of lost data, then data backup RPO will be two days.
The cost analysis according to the RTO and RPO along with SAP HANA disaster recovery features is shown in Figure 2. The lower the RTO AND RPO objectives, the higher the cost.
Figure2 – RPO & RTO of Disaster Recovery Features
SAP HANA offers three features for disaster recovery:
Backups and Recovery
Data backup in SAP HANA is written into disk from memory. It can only be performed when the database is online. SAP HANA supports following backup methods (Figure 3).
is committed. The reason for saving the logs is that when eithera power failure of any other disaster happens, the log can be executed again to bring the database to the most consistent state.
Figure3 – Data and log backup
With SAP Hana SPS10 there are two new data backup options (Figure 4)
Figure4: Incremental and Differential Backup
The data backup can be performed either from the SAP HANA studio, database administration (DBA) Cockpit, or by executing SQL commands via HDBSQL. SAP HANA HDBSQL is a command line tool for executing commands on SAP HANA databases. The following authorizations are required to perform data backup in SAP HANA:
The savepoint and log play an important role in the recovery of the system during a disaster(Figure 5). The database is first restarted and then the last savepoint is reloaded. There can be a huge data gap between the last savepoint and the disaster point (Figure 5). The gap between the points are fulfilled by re-executing the incremental or differential backup and then the redo log which contains the log of recent executed transaction. Once the transaction is re-executed the database is back to its consistent state. The uncommitted transactions are rolled back using an undo log whereas the committed transactions present in the redo log are executed.
Figure5 – Savepoint and redo log
SAP has also provided an application programming interface (API) to support data backup and recovery using third-party tools. Some of the third-party tools are as follows
The backup and recovery is more successful in the case of power failure or disk failure. This does not help when the persistent storage is itself destroyed or some logical error has occurred.The cost of backup and recovery is not huge as compared to other options. The backup and recovery is used by company that does not have the need for a short RTO and RPO = 0.
Storage Replication
Storage replication is the process of mirroring disk content to a secondary data center with a standby SAP HANA system (Figure 6). The transfer process can be either synchronous or asynchronous depending on the distance between the primary and the standby SAP HANA system. As the distance between the primary and secondary center increases the latency time for writing the log also increases. The further the distance, the higher the time is to save the data between the centers. This reduces performance. The synchronous transfer is therefore used for shorter distances whereas the asynchronous method is for longer distances. Synchronous data replication between the primary and secondary site ensures zero data loss (RPO=0). This allows the protection of a data center against events such as power outages, fire, floods, or hurricanes.
The asynchronous storage replication can also be used but it is possible that during a takeover the changes that were made last may be lost. In some application scenarios, this loss can be accepted, in others not. SAP suggests you use synchronous replication as it gives more performance and even the slightest chance of data loss is removed. Due to continuous replication it offers a better RPO than backup but it requires a high bandwidth and low latency connection between the primary and the secondary site. This can be mainly used for recovery from local storage corruption or recovery after a disaster.
Figure6 – Storage Replication
System Replication
SAP HANA system replication ships all data to a secondary system located at another site. Once SAP HANA system replication is enabled, each server process on the secondary system establishes a connection with its primary counterpart and requests a snapshot of the data (Figure 7). Further all logged changes in the primary system are replicated continuously to secondary system. Each persisted. Transaction persistence to disk log in the primary system is sent to the secondary system. A transaction in the primary system is not committed before the logs are replicated.There are different options available:
SAP HANA system replication has less RTO and is faster than storage replication. SAP suggests you use synchronous replication as there can be a data loss during asynchronous replication.
Figure7 – System replication
The main benefits of system replication are as follows
The log entries in the secondary system are executed continuously, immediately after they have been received. This means that the secondary system can take over with virtually no delay, if the primary system fails. This replication solution offers a low RPO and RTO to the customers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
5 | |
5 | |
5 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 |