Skip to main content
NetApp Solutions SAP

Break and delete replication peering

Contributors kevin-hoke netapp-mschoen
PDFs

In case of a disaster failover, the target volumes must be broken off so that the target host can mount the volumes for read and write operations.

Note For the HANA data volume, you must restore the volume to the latest HANA snapshot backup created with AzAcSnap. This volume revert operation is not possible if the latest replication snapshot is marked as busy due to the replication peering. Therefore, you must also delete the replication peering.

The next two screenshots show the break and delete peering operation for the HANA data volume. The same operations must be performed for the log backup and the HANA shared volume as well.

Figure showing input/output dialog or representing written content

Figure showing input/output dialog or representing written content

Since replication peering was deleted, it is possible to revert the volume to the latest HANA snapshot backup. If peering is not deleted, the selection of revert volume is grayed out and is not selectable. The following two screenshots show the volume revert operation.

Figure showing input/output dialog or representing written content

Figure showing input/output dialog or representing written content

After the volume revert operation, the data volume is based on the consistent HANA snapshot backup and can now be used to execute forward recovery operations.

Note If a capacity pool with a low performance tier has been used, the volumes must now be moved to a capacity pool that can provide the required performance.