# Amazon EBS snapshots for SAP HANA
<a name="ebs-sap-hana"></a>

Amazon EBS snapshots provide point-in-time backups of your EBS volumes to Amazon S3. EBS snapshots are stored incrementally, which means that only the blocks that have changed after your last snapshot are saved, and you are billed only for the changed blocks.

**Note**  
EBS snapshots are created at the block level. Creating EBS snapshots does not utilize storage throughput from the underlying EBS volume, or network bandwidth or CPU resources from the Amazon EC2 instance.

If you have Amazon EC2 instances running SAP HANA, you can automate the creation and retention of application-consistent EBS snapshots of the EBS volumes attached to those instances. You can then use these EBS snapshots to restore the entire SAP HANA database to the point-in-time when the EBS snapshot creation was initiated. EBS snapshots are created in a specific AWS Region, and they can be used to restore EBS volumes in any Availability Zone in that Region. EBS snapshots can also be copied to secondary Regions or AWS accounts for Disaster Recovery (DR) purposes.

The time it takes to restore an EBS volume from an EBS snapshot depends on several factors that can impact the [initialization of volume](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html). To reduce the time needed to restore a volume from a snapshot, we recommend that you enable the snapshot for [Amazon EBS fast snapshot restore](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html). Fast snapshot restore enables you to create a volume from a snapshot that is fully initialized at creation. When you automate application-consistent EBS snapshots for SAP HANA with Amazon Data Lifecycle Manager, you can configure your policy to automatically enable those snapshots for fast snapshot restore. For more information, see [Considerations](dlm-sap-considerations.md).

We recommend that you use AWS Backint Agent for SAP HANA as your primary backup mechanism, and to create application-consistent EBS snapshots for SAP HANA to supplement your DR strategy, by maintaining copies in other Regions and/or accounts.

# Considerations
<a name="dlm-sap-considerations"></a>

Only the following configurations are supported.
+ SAP HANA 2.0 SPS 05 and later with multi-tenant configuration.
+ Single SAP HANA databases. Multiple SAP HANA Systems on One Host (MCOS) is not supported.
+ SAP HANA scale-out systems are not supported.

**Supported Regions**  
You can automate the creation and retention of application-consistent snapshots of your SAP HANA workloads using Amazon Data Lifecycle Manager in all [AWS Regions where AWS Systems Manager for SAP is available](https://docs.aws.amazon.com/general/latest/gr/ssm-sap.html).
+ Ensure that the EBS snapshot you use for the restore has fast snapshot restore in the `enabled` state for the required Availability Zone.
+ It takes 60 minutes per TiB to enable a snapshot for fast snapshot restore after the snapshot reaches the `COMPLETED` state.
+ Ensure that the snapshot has enough [volume creation credits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html#volume-creation-credits) to restore volumes with the full performance benefit of fast snapshot restore.
+ Ensure that you have sufficient [fast snapshot restore quota](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html#limits) in your account and Region to meet your recovery needs. The total quota required depends on several factors, including the number of volumes supporting the SAP HANA database, the snapshot creation frequency, and the snapshot retention period.
+ You can use [Amazon CloudWatch metrics](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html#fast-snapshot-restore-metrics) and [Amazon EventBridge events](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-cloud-watch-events.html#fast-snapshot-restore-events) to monitor the fast snapshot restore state for a snapshot.
+ We recommend that you do not use the SSM document for SAP HANA without Amazon Data Lifecycle Manager. Doing this will result in EBS snapshots that are not managed by Amazon Data Lifecycle Manager.
+ It is your responsibility to ensure that the SAP HANA database is prepared to create snapshots and that it has at least 2 percent available memory and CPU resources. Otherwise, Amazon Data Lifecycle Manager will not initiate the instructions to freeze I/O and to create the application-consistent EBS snapshots.
+ The time required to complete snapshot creation depends on several factors, including the amount of data that has changed since the last snapshot of the EBS volume.
+ The time it takes to restore a SAP HANA database from EBS snapshots will be impacted by the [initialization of EBS volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html#ebs-initialize-linux). You can use [fast snapshot restore](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html) to ensure that the EBS volumes created from the EBS snapshot are fully-initialized at creation and instantly deliver all of their provisioned performance.
+ If you choose to not use fast snapshot restore, you can manually [initialize the EBS volume](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html#ebs-initialize-linux) after creation. However, this can take several minutes or up to several hours, depending on your EC2 instance bandwidth, the IOPS provisioned for the volume, and the size of the volume.
+ You can verify that application-consistent EBS snapshots of your SAP HANA workloads were successfully created by reviewing the snapshot tags, the emitted Amazon CloudWatch metrics, and the emitted Amazon EventBridge events. For more information see [Identifying snapshots created with pre and post scripts](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dlm-script-tags.html) and [Monitoring pre and post script execution](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dlm-script-monitoring.html).

# How to automate the creation of EBS snapshots for SAP HANA
<a name="dlm-sap-how"></a>

In a running database, to be application-consistent, EBS snapshots must be aligned with an internal database snapshot. For more information, see [Create a Data Snapshot](https://help.sap.com/docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/9fd1c8bb3b60455caa93b7491ae6d830.html) in the SAP documentation.

To create application-consistent snapshots, Amazon Data Lifecycle Manager performs the following steps with pre and post scripts:

1. In the pre script, operating system checks are performed, the I/O is paused, and the SAP HANA SQL command is run to create a consistent internal database snapshot.

1. Amazon Data Lifecycle Manager initiates EBS snapshot creation for the volumes attached to the targeted instance.

1. In the post script, the SAP HANA SQL command is run to mark the internal snapshot as either completed or failed.

Amazon Data Lifecycle Manager also provides monitoring capabilities and manages the retention of the EBS snapshots after creation.

To automate the creation of application-consistent EBS snapshots for SAP HANA using Amazon Data Lifecycle Manager, you need the following:
+ An Amazon Data Lifecycle Manager policy that is enabled for pre and post scripts for SAP HANA and that uses an AWS IAM role with the permissions required to manage application-consistent snapshots. We recommend that you also configure the policy to automatically enable the EBS snapshots for fast snapshot restore. For more information, see [Considerations](dlm-sap-considerations.md).
+  AWS Systems Manager Agent (SSM Agent) installed and running on the target instances with the SAP HANA workloads that you want to back up.
+ Access to the Systems Manager document for SAP HANA, ` AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA`, which is available in all [AWS Regions where AWS Systems Manager for SAP is available](https://docs.aws.amazon.com/general/latest/gr/ssm-sap.html).
+ (Recommended) A [resource tagging](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) strategy that includes tagging your Amazon EBS volumes in a way that enables you to map them to your specific SAP HANA workloads.

For more information about setting up your target instances, the Amazon Data Lifecycle Manager policy , and your SAP HANA environment for automated application-consistent snapshots, see [Automating application-consistent snapshots with pre and post scripts](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automate-app-consistent-backups.html).

# Restoring SAP HANA from EBS snapshots
<a name="restore-strategy"></a>

A successful restore strategy is dependent on many factors, including:
+ The failure scenario or event that led to the restore
+ The recovery point to which you need to restore
+ The date and time of your last successful backup

All of these factors can impact the restore and recovery approach. It is recommended that a comprehensive disaster recovery (DR) strategy is developed, tested, and well documented to ensure that the recovery process and recovery times are well understood.

The following steps do not cover detailed instructions on log recovery, which is likely to involve a secondary backup mechanism, such as AWS Backint for SAP HANA. Ensure that when you select the volumes to recover, you consider the potential impact on your recovery point.

**Topics**
+ [Step 1: Prepare for a restore](#step1)
+ [Step 2: Attach or replace the restored EBS volumes](#step2)
+ [Step 3: Recover SAP HANA database](#step3)
+ [Step 4: Resume standard operations](#step4)

## Step 1: Prepare for a restore
<a name="step1"></a>

1. Get information about the EBS volume to restore. This information can help you identify which volumes need to be restored. For example, it can help you to identify the data volumes and the log volumes for your workload. Use this information to tag your volumes or save the information in a location that will not be impacted by the loss of the instance.

   Run the following commands and note the volume’s ID, serial number, UUID, mount point information, fstab configuration, and attachment information.

   ```
   $ lsblk -o +LABEL,UUID,SERIAL | sed 's/vol/vol-/g'
   ```

```
$ cat /etc/fstab | column -t
```

```
$ aws ec2 describe-volumes \
  --filters Name=attachment.instance-id,Values=<instance_id> \
  --query 'Volumes[*].[VolumeId,Size,Attachments[0].Device,Attachments[0].InstanceId,Attachments[0].State]' \
  --output table
```

1. Review the fast snapshot restore state for the EBS snapshots. EBS volumes that are created from snapshots with fast snapshot restore instantly deliver all of their provisioned performance. This eliminates the latency of I/O operations on a block when it is accessed for the first time. This is important for SAP HANA restores as tables are read from disk on startup so that they can be loaded into memory. Before you create the EBS volume, ensure that fast snapshot restore is in the `enabled` state for the snapshot in the Availability Zone in which you want to create the volume. You will also need sufficient volume creation credits. For more information, see [Considerations](dlm-sap-considerations.md).

1. Identify the backup and backup catalog. If possible, identify the time stamp and backup ID of the backup you plan to restore to. Ensure that the backup catalog is available in a location that will be available after the EBS volume is restored.

1. Stop SAP HANA and any backup schedules. If you are restoring in place, ensure a clean SAP HANA and operating system state for the recovery.

   Run the following command to stop SAP HANA and any connected SAP applications using sapcontrol or other SAP tools, and to remove remaining processes and clean shared memory segments.

   ```
   $ cleanipc <hana_sys_no> remove
   ```

   (Optional) Do the following to prevent SAP HANA from trying to start up before the restore is complete. This can be helpful if you need to restart the operating system before the restore is complete.

   ```
   $ cd /usr/sap/<hana_sid>/SYS/profile
   $ vi <hana_start_profile>
   ```

   Then, check and change the value of `autostart` to `0`.

   ```
   #autostart=1 # Previous value changed for restore.
   autostart=0
   ```

1. (Optional) Temporarily disable or modify Amazon Data Lifecycle Manager policies or schedules to exclude the EC2 instance where you are performing the restore. This prevents interference with the restore and ensures that the required snapshots are retained for the duration of the restore process.

## Step 2: Attach or replace the restored EBS volumes
<a name="step2"></a>

The following steps are dependent on whether you are restoring to the EC2 instance where the backups were created or to a new EC2 instance. If you are replacing EBS volumes on the same instance, then you must detach all previous volumes.

1. Identify the mount points to be restored from the EBS snapshot and, if applicable, unmount the filesystems associated with the old volumes from the EC2 Instance. For example, run the following command as the root user.

   ```
   $ umount </hana/data>
   ```

   If you are concerned that the state of the volumes might impact the ability to reboot the instance, you can comment out the entries in `/etc/fstab`.

1. Follow the prescriptive guidance on [Restoring an EBS volume from an EBS snapshot](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html#restore-snapshot) to create volumes from the snapshots that match the backup time and the volumes that need to be restored, and then attach the volumes to the instance using the mapping information that you noted in Step 1.

   If you are using striped Logical Volume Manager (LVM) volumes, take additional care to ensure that all required volumes in the volume group are recovered from the same point.

1. Scan or refresh connected volumes. Run the following command as the root user.

   ```
   $ pvscan --cache -aay
   ```

   If you are using LVM, run the following command.

   ```
   $ vgchange --refresh
   ```

1. Remount the volumes and ensure that `/etc/fstab` reflects the required filesystems. For example, run the following command.```` 

   ```
   $ mount </hana/data>
   ```

   Review the operating system logs for any errors.

## Step 3: Recover SAP HANA database
<a name="step3"></a>

After the EBS volumes have been restored, follow the instructions in the SAP documentation to recover the SAP HANA system database and all tenants. Ensure that the backup catalog and any required logs for roll forward are available. This can include access to AWS Backing for SAP HANA and/or local filesystems.

As both the system and tenant databases generally share the same filesystems, all databases need to be recovered.

1. Recover the SAP HANA system database. For more information, see [Recover SAP HANA From a Data Snapshot](https://help.sap.com/docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/9fd053d58cb94ac69655b4ebc41d7b05.html) in the SAP documentation.

1. Recover all SAP HANA tenant databases. For more information, see [Recover all Tenant Databases From a Data Snapshot](https://help.sap.com/docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/b2c283094b9041e7bdc0830c06b77bf8.html) in the SAP documentation.

## Step 4: Resume standard operations
<a name="step4"></a>

If you previously disabled the Amazon Data Lifecycle Manager policy when you started the restore process, then you should now re-enable the policy so that it will continue to automate the creation of application-consistent EBS snapshots for all targeted EC2 instances.

You might also consider changing the `autostart` back to `1` so that SAP HANA restarts automatically after a system reboot.