Automated Recovery of SAP HANA Database using cloud native options

In order to ensure recovery of SAP HANA database one can use SAP HSR (SAP HANA System replication) or cluster options. There is a cost associated with this approach of maintaining a copy of the DB with an identical size either on premise or in cloud.

With a focus on low costs we would recommend one to go for a cloud native solution leveraging EC2 Auto Scaling and AWS EBS snapshots which would not be possible on premise. Cost Optimized approach is part of Sonata’s CREATE-BOOT aspect of the Digital Platform Operation Model.

The restore process leveraging auto scaling and EBS snapshots would work across availability zones in a region. Snapshots provide a fast backup process, independent of the database size. They are stored in Amazon S3 and replicated across Availability Zones automatically, meaning we can create a new volume out of a snapshot in another Availability Zone. In addition, Amazon EBS snapshots are incremental by default. Only the delta changes are stored since the last snapshot. To create a resilient high available architecture, automation is key. All steps to recover the database must be automated in case something fails.

EBS Snapshots

Prior to enabling EBS snapshots we must ensure the destination of log backups are written to an EFS folder which is available across availability zones.

We create a script for taking an EBS snapshot. In the script prior to the command to be executed for an EBS snapshot by using the system username and password we make an entry into the HANA backup catalog to ensure that the database is aware of the snapshot backup. We use the snapshot feature to take a point In time and crash consistent snapshot across multiple EBS volumes without a manual I/O freeze. It is recommended to take the snapshot every 8-12 hours.

Now the log backups are stored in EFS and full backups as EBS snapshots in S3 and both sets are available across AZs. Both storage locations can be accessed across AZs in a region and are independent of an AZ.

EC2 Auto Scaling

Next we create an auto scaling group with a minimum and maximum of one instance. In case of an issue with the instance, the auto scaling group will create an alternative instance out of the same AMI as the original instance.

We first create a golden AMI for the auto scaling group. The AMI is used in a launch configuration with the desired instance type. With a shell script in the user data, upon launch of the instance, new volumes are created out of the latest EBS snapshot and attached to the instance. We can use the EBS Fast snapshot restore feature to reduce the initialization time of the newly created volumes.

If the database was started now it would have a crash consistent state. In order to restore it to the latest state we can leverage the log backup stored in EFS which is automatically mounted by the AMI.

Care will need to be taken that the SAP application server is aware of the new IP of the restored SAP HANA database server.