The following figure shows the lab setup used for this chapter. Two HANA hosts, hana-3 and hana-4, were configured with HANA System Replication.

A database user “SnapCenter” was created for the HANA system database with the required privileges to execute backup and recovery operations (see SAP HANA Backup and Recovery with SnapCenter). A HANA user store key must be configured at both hosts using the above database user.

From a high-level perspective, you must perform the following steps to set up HANA System Replication within SnapCenter.

After you have installed the SnapCenter HANA plug-in on both HANA hosts, the HANA systems are shown in the SnapCenter resource view in the same way as other autodiscovered resources. Starting with SnapCenter 4.6, an additional column is displayed that shows the status of HANA system replication (enabled/disabled, primary/secondary).

By clicking the resource, SnapCenter requests the HANA user store key for the HANA system.

Additional autodiscovery steps are executed, and SnapCenter show the resource details. With SnapCenter 4.6, the system replication status and the secondary server are listed in this view.

After performing the same steps for the second HANA resource, the autodiscovery process is complete and both HANA resources are configured in SnapCenter.

For HANA System Replication- enabled systems, you must configure a SnapCenter resource group, including both HANA resources.

NetApp recommends using a custom name format for the Snapshot name, which should include the hostname, the policy, and the schedule.

You must add both HANA hosts to the resource group.

Policies and schedules are configured for the resource group.

The resource group configuration is now finished and backups can be executed.

When a backup operation of the resource group is executed, SnapCenter identifies which host is primary and only triggers a backup at the primary host. This means, only the data volume of the primary host will be snapshotted. In our example, hana-3 is the current primary host and a backup is executed at this host.

The SnapCenter job log shows the identification operation and the execution of the backup at the current primary host hana-3.

A Snapshot backup has now been created at the primary HANA resource. The hostname included in the backup name shows hana-3.

The same Snapshot backup is also visible in the HANA backup catalog.

If a takeover operation is executed, further SnapCenter backups now identify the former secondary host (hana-4) as primary, and the backup operation is executed at hana-4. Again, only the data volume of the new primary host (hana-4) is snapshotted.

The SnapCenter job log shows the identification operation and the execution of the backup at the current primary host hana-4.

A Snapshot backup has now been created at the primary HANA resource. The hostname included in the backup name shows hana-4.

The same Snapshot backup is also visible in the HANA backup catalog.

SnapCenter 4.6 uses the same logic as described for Snapshot backup operations for block-integrity check operations with file-based backups. SnapCenter identifies the current primary HANA host and executes the file-based backup for this host. Retention management is also performed across both hosts, so the oldest backup is deleted regardless of which host is currently the primary.

To allow transparent backup operations without manual interaction in case of a takeover and independent of which HANA host is currently the primary host, you must configure a SnapVault relationship for the data volumes of both hosts. SnapCenter executes a SnapVault update operation for the current primary host with each backup run.

Since the retention management at the SnapVault target is managed outside of SnapCenter by ONTAP, the retention can’t be handled across both HANA hosts. Therefore backups that have been created before a takeover are not deleted with backup operations at the former secondary. These backups remain until the former primary becomes primary again. So that these backups do not block the retention management of log backups, they must deleted manually either at the SnapVault target or within the HANA backup catalog.

SnapCenter 4.6 manages retention for Snapshot backups, block-integrity check operations, HANA backup catalog entries, and log backups (if not disabled) across both HANA hosts, so it doesn’t matter which host is currently primary or secondary. Backups (data and log) and entries in the HANA catalog are deleted based on the defined retention, regardless of whether a delete operation is necessary on the current primary or secondary host. In other words, no manual interaction is required if a takeover operation is performed and/or the replication is configured in the other direction.

If SnapVault replication is part of the data protection strategy, manual interaction is required for specific scenarios, as described in the section SnapVault Replication

The following figure depicts a scenario in which multiple takeovers have been executed and Snapshot backups have been created at both sites. With the current status, the host hana-3 is the primary host and the latest backup is T4, which has been created at host hana-3. If you need to perform a restore and recovery operation, the backups T1 and T4 are available for restore and recovery in SnapCenter. The backups, which have been created at host hana-4 (T2, T3), can’t be restored using SnapCenter. These backups must be copied manually to the data volume of hana-3 for recovery.

Restore and recovery operations for a SnapCenter 4.6 resource group configuration are identical to an autodiscovered non-System Replication setup. All options for restore and automated recovery are available. For further details, see the technical report TR-4614: SAP HANA Backup and Recovery with SnapCenter.

A restore operation from a backup that was created at the other host is described in the section Restore and Recovery from a Backup Created at the Other Host.