Enterprise Readiness with SAP HANA – Persistence, Backup & Recovery

Enterprise Readiness – Planning Your Data Center

As High Availability and Disaster Recovery become increasingly important topics for many enterprise customers embarking on digitization, we will be taking time to explain more on this topic in a blog series to help customers better plan and prepare their data center operations, with SAP HANA as the platform of focus.

We began this series with an earlier blog on Enterprise Readiness, and will continue with more topics in the following months.

Design & Setup, Scalability Options

We begin this blog on the Plan phase, where we focus on the installation options available for SAP HANA. With SAP HANA, there are two options available: a. as a full-appliance delivery, or b. a tailored data center integration approach.

Choosing between the two options above depends on the IT manager’s following priorities:

1. Time to value
2. availability of existing assets: Servers, Storage, Network
3. Landscape limitations: space, other challenges connecting a new appliance into the landscape

For managers looking for faster time to value, the HANA appliance comes with a pre-configured hardware setup, along with pre-installed software that can be up and running in the landscape quickly. However for managers with large existing IT investments and infrastructures, the HANA Tailored data center integration approach could prove as an attractive alternative to capitalize on pre-existing assets.
Below is a table highlighting the advantages between both options, and provides a rough guide on which option would be more feasible.

Figure 1

On Scalability, the SAP HANA system can be scaled up or scaled out, depending on business requirements. Scale-up options are usually recommended for production workloads, while we recommend a scale-out cluster model for the SAP Business Warehouse application on SAP HANA. Instances of SAP HANA can also be deployed into the cloud such as the SAP HANA Enterprise Cloud service or the SAP HANA Cloud Platform, or also in public clouds such as Amazon Web Services or Microsoft Azure. SAP plans to support additional public clouds as they become available, thus addressing the issue of scalability that our customers may face as their business grows.

Persistence

While the database holds the bulk of data in memory to ensure maximum performance for both online transaction processing (OLTP) and online analytical processing (OLAP), SAP HANA uses persistent storage as a fallback in case of failure. Every five minutes, SAP HANA pushes this data – along with SQL data, undo log information, and modeling data – to persistent storage assets. This write process is asynchronous.

Information about transaction log changes on the other hand, is saved directly to persistent storage as soon as transactions are committed. These transaction logs are saved synchronously.

The following figure below helps provide a break-up visualization of the system.

Figure 2

Backup and Recovery

SAP HANA supports three backup options: full backups, delta backups (either incremental or differential), and log backups. The figure below helps provide a visual summary of how these would like, without the delta backups, which we will cover later.

The data and undo log information is written to the disk (data area), asynchronously every 5 minutes, as described earlier above.

The log captures all changes by database transactions (redo logs), and is saved to disk (log area) continuously and synchronously after each COMMIT of a database transaction (waiting for end of disk write operation).

In addition to memory and persistent storage for the staging of backups, the database also offers an external backup staging area. The staging area can help protect data in situations such as when a third-party backup tool has a maintenance window. SAP HANA parks backups in the staging area for a defined downtime period.

Figure 3

Delta Data Backups

On top of the full data backups, delta backups provides more options for the IT manager, and reduce the reliance on full data backups which can be limiting in some cases.

• Full Data Backups: All data.
• Incremental Backups: Changed data since the last data backup (delta or full).
• Differential Backups: Changed data since the last full data backup.

Figure 4

With the delta data, users can also mix both incremental and differential backups together, depending on their operational requirements. Additionally, Data Backups which were successful can be reused for the next attempt of recovery. SAP HANA offers resumable recoveries to shorten the time required for a failed recovery attempt. This feature reuses milestones during recovery execution as a safety measure. SAP HANA’s latest SPS 12 release also focuses on extending this feature from data backups into log backups. The log backup file handling could further be potentially optimized in future releases to reduce the number of backup files per day.

How a backup recovery works

To sum it up, the below shows how backup recoveries will be executed at the moment of a power failure:

1. Database loads from the last full data backup
2. Data changed since the last full backup (known as differential backup) are applied or
3. data changed since the last data backup (known as incremental backup)
4. Log backups of transactions, in which changes are applied
5. Log entries of all transactions kept in the online log volume of SAP HANA are applied, until the latest committed status before power loss.

Figure 5.

Additional Backup Recommendations

The above features we talked about showcase the native backup features of SAP HANA. Aside from these, there are also available alternative storage backups snapshots combined with the usage of the SAP HANA internal snapshots for keeping the internal consistency within the SAP HANA database. This allows the user to have multiple reset points per day, which usually with the help of fast snapshot restores can offer a nice extension to the native backup options described before.