Automating application-consistent Amazon EBS Snapshots for SAP HANA databases

Customers host their SAP HANA environments on AWS to run their business-critical processes, such as financial planning, data analytics, and supply chain management. Reliably backing up data in SAP HANA is paramount for users to restore the database in the event of disruptions and urgent business needs.

To reliably back up SAP HANA, SAP documentation (SAP Note 2039883 – FAQ: SAP HANA database and storage snapshots, FAQ #20) recommends that users consider backing up their SAP HANA databases as Amazon Elastic Block Store Snapshots (EBS Snapshots), especially for Disaster Recovery (DR) purposes. Today, you can back up your SAP HANA databases running on Amazon Elastic Compute Cloud (Amazon EC2) instances in the form of application-consistent Amazon Elastic Block Store (EBS) Snapshots using Amazon Data Lifecycle Manager and the AWS System Manager document for SAP HANA. In addition, you can use AWS Backint Agent for SAP HANA to back up directly to Amazon Simple Storage Service (Amazon S3). The combination provides flexibility for users who want to perform database-level restore using data from Amazon S3, as well as share, copy, and restore their entire SAP HANA database with EBS Snapshots. With the added support for SAP HANA in AWS Backup that was announced in April 2023, you benefit from centralized, console-based backup management with a consistent experience across all supported AWS resources.

In this post, we walk through the use of Amazon Data Lifecycle Manager, a policy-based lifecycle management solution for EBS Snapshots, and AWS Systems Manager to automate the creation of application-consistent EBS Snapshots for SAP HANA. We also outline how to enable and manage Fast Snapshot Restore so the EBS volumes are fully initialized at creation, allowing you to use your SAP HANA databases immediately. Using this capability frees up resources and eliminates the burden of maintaining and orchestrating complex custom scripts on your fleet of EC2 instances. Automating the process with Amazon Data Lifecycle Manager also reduces the risk of missed backups and decreases storage costs by making sure snapshots are deleted on time.

Solution overview

Previously, we outlined how to create application-consistent snapshots using Amazon Data Lifecycle Manager and custom scripts, as well as the necessary steps to create Amazon Data Lifecycle Manager policies that use AWS Systems Manager Agent to run custom scripts on your EC2 instances.

In this post, we build on those instructions to create application-consistent EBS Snapshots of SAP HANA databases using SAP HANA data snapshots. Amazon Data Lifecycle Manager uses the AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA AWS Systems Manager document (SSM document) for SAP HANA to coordinate with SAP HANA on your instance to freeze I/O, quiesce the database, and flush memory to disk. Then, the policy initiates the creation of the EBS Snapshot. Once the snapshot has been initialized, the policy calls the SSM document for SAP HANA to thaw I/O and return the SAP HANA database back to operation, as shown in the following figure.

Note that this feature only supports single SAP HANA databases and not multiple SAP HANA systems on One Host (MCOS). It also only supports SAP HANA 2.0 with multi-tenant databases.

Please note:

• As part of Step 2 in the above diagram, the SSM document for SAP HANA also:
  • Checks that there is at least 2% CPU and 2% memory is available
  • Creates an internal database snapshot for a database instance (which appears in the backup catalog).
  • Calls xfs_freeze
• As part of Step 6 in the above diagram, the SSM document for SAP HANA also:
  • Quiesces the SAP database
  • Confirms that a data snapshot has been created

Prerequisites

You must install AWS Systems Manager Agent on all EC2 instances in which you want to create application-consistent EBS Snapshots and make sure the agent is running. You must setup all EC2 instances with the relevant permissions so that AWS Systems Manager can execute the SSM document for SAP HANA. You must also make sure the AWS Identity and Access Management (IAM) service role that is used for your Amazon Data Lifecycle Manager policy has the appropriate permissions to run the documents on the targeted EC2 instances. The easiest way to do this is to attach the AWSDataLifecycleManagerSSMFullAccess IAM policy to the IAM role.

Walkthrough

To automate the creation of application-consistent EBS Snapshots for SAP HANA, you must:

1. Setup your SAP HANA workload to create application-consistent EBS Snapshots using the SSM document for SAP HANA. The document (AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA) has been developed specifically for SAP HANA in the format that can be consumed by Amazon Data Lifecycle Manager.

2. Create an Amazon Data Lifecycle Manager policy. The policy is responsible for coordinating the execution of the SSM document, initiating the snapshot, marking the snapshots as application-consistent, as well as managing its retention and other actions

3. (Optional) Automatically enable and manage Fast Snapshot Restore on the snapshots.

4. Validate that the snapshots created are application-consistent.

Step 1: Setting up your SAP HANA environment

You must perform the following steps on every EC2 instance and SAP HANA environment where you want to create application-consistent snapshots using Amazon Data Lifecycle Manager and the SSM document for SAP HANA:

1. Setup your EC2 instance with SAP HANA. If you don’t already have an existing SAP HANA environment, then you can refer to the SAP HANA Environment Setup page.

2. Log in to the SystemDB as “SYSTEM” (or a suitable administrator user).

3. Create a database backup user to be used with Amazon Data Lifecycle Manager. In our example, we are creating user <dlm_user> with password <password>.

CREATE USER <dlm_user> PASSWORD <password> NO FORCE_FIRST_PASSWORD_CHANGE;

4. Assign the BACKUP OPERATOR (or BACKUP ADMIN) role to the database backup user that was just created.

GRANT BACKUP OPERATOR TO <dlm_user>

5. Log in to the operating system as the administrator, for example “<sid>adm”.

6. Create an “hdbuserstore” entry to store connection information so that the SSM document for SAP HANA can connect to SAP HANA without users having to enter the information.

hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3<HANA InstNr>13 <dlm_user> < password>

For example, if your SAP HANA Instance Number is “00”, then the previous command would become:

hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 <dlm_user> < password>

7. Test the connection

hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy"

Step 2: Create an Amazon Data Lifecycle Manager policy

Now we create Amazon Data Lifecycle Manager policies to automate the creation and management of EBS Snapshots that are initiated in between the pre-scripts and post-scripts. The following outline steps are necessary when creating the policy through the Amazon EC2 console. However, you can also create the policy by using API/CLI and AWS CloudFormation.

If you already have policies creating crash-consistent snapshots, then you can modify those policies and enable Pre/Post script feature. As long as all the other prerequisites have been met, your policies can start creating application-consistent EBS Snapshots the next time it runs.

1. To get started, launch the Amazon EC2 console, then select Lifecycle Manager under Elastic Block Store in the left-side navigation panel. Under Schedule-based policy, select EBS snapshot policy.

2. In Target resource types, select Instance and then supply tags of all instances that you want to target. In this example, we target all EC2 instances with the tag (SAPHANA_Snapshot:DLM). Add a description for the policy, as shown in the following figure.

3. For IAM role, most users should select Default role, as this has all the permissions necessary for the policy actions, as shown in the following figure. When creating/modifying policies through the console, the AWSDataLifecycleManagerSSMFullAccess IAM policy (which has all the permissions for this feature) is automatically attached to the default role. If you are using API/CLI to create or modify policies for this feature, then you must manually attach the IAM policy to the default role. If you choose to use a custom IAM role, then you must make sure the IAM role has all the necessary permissions to run the SSM document for SAP HANA on targeted instances.

4. On the next page, setup your policy creation schedule, as shown in the following figure. We recommend you use Retention Type = Age. In this example, we are creating snapshots every 24 hours at 11:00 UTC and retaining them for 7 days.

5. Under Advanced Settings, make sure you check the box to Enable pre and post scripts for this schedule, as shown in the following figure. Next, select the tile labeled SAP HANA. When you select this tile, your policy uses the “AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA” SSM document for SAP HANA to create a data snapshot.

6. You can also set additional parameters here, such as the Script timeout period, and enable Retry script if it fails.

The Script timeout period is the amount of time that Amazon Data Lifecycle Manager waits for successful completion of the script. If the time is exceeded and Amazon Data Lifecycle Manager has not received confirmation of successful completion, then your policy treats the script as having failed.

You can set Retry script if it fails to automatically retry initiating the failed script. You should consider this if you want a higher likelihood of your script completing successfully, and your database can withstand being quiesced repeatedly in a short amount of time.

Note that you should unselect the Default to crash-consistent snapshots if script fails if you do not want to create crash-consistent snapshots of your SAP HANA databases. If enabled, then Amazon Data Lifecycle Manager attempts to create crash-consistent snapshots if it is unable to successfully run your pre-script. In most cases, if the pre-script fails to freeze the data volume to flush the journal, then you may not be able to successfully restore the database from the resulting snapshots (see SAP Note 2039883 – FAQ: SAP HANA database and storage snapshots, FAQ #21 for more information).

You can use the tags applied on the snapshots as well as Amazon EventBridge to later determine if the EBS Snapshots were created as part of successful executions of the pre-script and post-script in the SSM document for SAP HANA, as shown in the following figure.

7. Under Advanced Settings, you can also set the policy to automate other actions, such as Fast Snapshot Restore, cross-region copy, and cross-account sharing. If you do not want to enable any of these actions, then you can proceed to creating the policy.

Step 3. (Optional) Automatically enable and manage Fast Snapshot Restore on the snapshots.

We recommend that users consider enabling Amazon EBS fast snapshot restore (FSR) on EBS Snapshot backups of their SAP HANA databases. EBS volumes created from FSR-enabled snapshots are fully initialized at creation, which means SAP HANA does not need to pre-warm by accessing every block to load data into memory.

You can set the same Amazon Data Lifecycle Manager policy (from Step 2) to automatically enable FSR on the most recent set of snapshots and disable older snapshots. However, before enabling FSR, you should review all the considerations when using Fast Snapshot Restore, as it may impact both your Recovery Point and Recovery Time Objectives, such as FSR account quota.

By default, users can enable FSR on five snapshots per account per AWS Region. Users can request for this quota to be increased. Users should consider the number of EBS volumes (supporting SAP HANA) that they want to regularly back up as EBS Snapshots, as well as the retention count and period of those FSR-enabled snapshots per the following formula:

*Note: The addition of one (+1) is needed in the formula because Data Lifecycle Manager always enables FSR on newly created snapshots before disabling FSR on older snapshots.

Time for snapshot creation/FSR optimization

After a policy initiates a snapshot, it takes some time for snapshot creation to complete. Once the snapshot completes, then Amazon Data Lifecycle Manager enables Fast Snapshot Restore on the snapshot (assuming you enabled it as part of the same policy). It takes 60 minutes per TiB to optimize a snapshot, during which time the Fast Snapshot Restore state for the snapshot is ‘optimizing’. Once complete, the Fast Snapshot Restore for the snapshot moves to the ‘enabled’ state. Snapshots that are in the ‘enabled’ state and that have sufficient volume creation credits (see the following section) offer the full performance benefit when restoring volumes.

Volume creation credits

Once a snapshot has FSR enabled, the number of volumes that receive the full performance benefit of FSR is determined by the volume creation credits for the snapshot. This depends on the number of credits in the ‘credit bucket’ of that snapshot. Each volume that you create from a snapshot with fast snapshot restore enabled consumes one credit from the credit bucket. The size of a credit bucket and the rate at which it refills depend on the size of the snapshot.

If you are using FSR-enabled snapshots for disaster recovery, and when restoring, you only ever create a single volume from that snapshot, then you don’t need to worry about volume creation credits. However, if you plan to use a single FSR-enabled snapshot to create multiple EBS volumes simultaneously, then you should be aware that not all volumes created are fully initialized at creation.

Fast Snapshot Restore (FSR) cost

Although creating and managing an Amazon Data Lifecycle Manager incurs no additional cost, you are billed for each minute that fast snapshot restore is enabled for a snapshot in a particular Availability Zone (AZ). You can set your Amazon Data Lifecycle Manager policy to only enable FSR on the most recent set of snapshots to reduce the cost associated with FSR. For more information and examples, refer to FSR pricing and billing.

Now we go through the steps to enable Fast Snapshot Restore on your Amazon Data Lifecycle Manager policy:

1. Continuing from Step 2, you can enable Fast Snapshot Restore on the same policy that you have set to automate the creation of application-consistent EBS Snapshots for SAP HANA, as shown in the following figure. In the Advanced Settings section, select the box for “Enable fast snapshot restore for snapshots created by this schedule”.

In this example, we are setting the policy to make sure the most recent set of application-consistent EBS Snapshots for each EC2 instance has Fast Snapshot Restore enabled in us-east-1a, so that volumes created from those snapshots instantly deliver all of their provisioned performance.

2. Once you have set the parameter, you can create the policy.

Step 4: Validate that the snapshots created are application consistent

Once your Amazon Data Lifecycle Manager policy has created an EBS Snapshot, you can check if it is application-consistent.

1. Navigate to the Amazon EC2 console and select Snapshots, as shown in the following figure.

2. Select the snapshot and select Tags in the bottom panel, as shown in the following figure. If you see the tag key ‘aws:dlm:lifecycle-policy-id’, then the snapshot was also created (and is managed) by Amazon Data Lifecycle Manager. If you see tags for ‘aws:dlm:pre-script: SUCCESS’ and ‘aws:dlm:post-script: SUCCESS’, then both the pre-script and the post-script of the SSM document for SAP HANA completed successfully, and the resulting EBS Snapshot is application-consistent.

Refer to Troubleshooting Systems Manager Run Command for additional information if you do not see application-consistent snapshots created from this process.

3. To view that the HANA data snapshots were created successfully, check the status using the HANA backup catalog. The three main methods to view the catalog are shown in the following:

Method 1: HANA Studio > System Overview > Database Administration > Manage Database Backups

Method 2: HANA Cockpit > Systems view > Open system > Double-click backup (select Database)

Method 3: Through the Command Line interface using the stored DLM_HANADB_SNAPSHOT_USER user:

hdbsql -U DLM_HANADB_SNAPSHOT_USER "select BACKUP_ID, ENTRY_TYPE_NAME, SYS_START_TIME, STATE_NAME, SYSTEM_ID from M_BACKUP_CATALOG where ENTRY_TYPE_NAME = 'data snapshot'"

Cleaning up

To cleanup snapshots created from this post, start by navigating to the Snapshots screen, searching for all snapshots created by the policy, selecting all the snapshots, and then selecting Actions followed by Delete snapshot.

Similarly, you should delete the Amazon Data Lifecycle Manager policy to make sure no future snapshots are created by the policy. You can do so by navigating to the Lifecycle Manager screen, selecting the policy, and then selecting Actions followed by Delete lifecycle policy.

Conclusion

In this post, we went through how to automate the creation and retention of application-consistent Amazon EBS Snapshots of SAP HANA databases using SAP HANA data snapshots. We hope this can reduce the amount of time and effort needed to enhance the data protection of your SAP HANA databases running on Amazon EC2 instances for various scenarios including advanced analytics and machine learning. We also have documentation to help you restore SAP HANA from EBS Snapshots.

With Amazon Data Lifecycle Manager, you have the ability to exclude the root/boot volume when creating a set of application-consistent snapshots. You can exclude non-boot (data) volumes, which is useful if you want to save costs by not creating backups of volumes that are only used to store logs or temporary data. You can also set your policy to manage Fast Snapshot Restore on the most recent set of snapshots so that you can create new EBS volumes that deliver maximum performance without needing to be initialized.

As a final takeaway, we encourage you to try this in your own environment. You can also learn more about this feature by reading our technical documentation and exploring different use cases for using pre- and post-scripts with Amazon Data Lifecycle Manager.

We welcome your feedback. If you have questions or suggestions, leave them in the comments section.