Table of Contents

Abstract

Introduction

Architecture considerations

SnapCenter Refresh and Repair scenarios

System Refresh of QA, test, sandbox or training systems

Repair system to address logical corruption

Summary

Additional Information

Abstract

This article and demo video provide an overview of how SAP system refresh and cloning operations of SAP HANA systems on Azure NetApp Files (ANF) can be executed by using NetApp SnapCenter. SnapCenter leverages Azure NetApp Files snapshot and volume cloning capabilities and offers end-to-end workflows for highly efficient data protection and SAP system refresh operations.

Co-authors: 

• Nils Bauer - SAP Technical Marketing Engineer
• Arnt de Gier - Azure NetApp Files Technical Marketing Engineer

Introduction

When snapshot backups have been implemented for your HANA systems, these backups can also be used to address other use cases, which require copies of a HANA database. The implementation of snapshot backup operations is described in detail in the blog SAP HANA data protection on Azure NetApp Files with SnapCenter.

With Azure NetApp Files, you can create a new volume based on the content of any available snapshot backup in a matter of a minute or even less, independent of the size of the volume. This allows us to quickly create HANA system copies or clones for various test scenarios.

The best-known use case is the SAP System Refresh, where data from the production system needs to be copied to a test or a QA system. By leveraging the Azure NetApp Files restore volume from snapshot (aka cloning) feature, you can provision the volume for the test system from any snapshot of the production system in a matter of seconds. In a second step the new volume needs to be attached to the test system and the HANA database needs to be recovered.

The second use case is the creation of a repair system, which is used to address logical corruption in the production system. In this case an older snapshot backup of the production system is used to start a repair system, which is an identical clone of the production system with the data before the corruption occurred. The repair system is then used to analyze the problem and export the required data before it got corrupted.

The last use case is the ability to run a disaster recover failover test, without stopping the replication and therefore without influencing RTO and RPO of the disaster recovery setup.

When Azure NetApp Files cross region replication is used to replicate the data to the DR site, the production snapshot backups will be available at the DR site as well and can then be used to create a new volume for disaster recover testing.

Architecture considerations

To fully leverage the Azure NetApp Files capabilities to quickly create a new volume based on a snapshot, a couple of architecture recommendations must be considered up front:

• Source and target HANA system must be in the same VNet, so that the target HANA system can mount the new volume created from the source snapshot.
• If different VNets are used, they must be peered to provide access to the new volume. Additional cost for cross VNet traffic must be considered in such a configuration.
• The SnapCenter workflow will create the new volume in the same capacity pool as the source volume. If the target volume should be in a different capacity pool, it must be moved manually after the refresh operation.

Moving volumes to a different capacity pool is possible within the same NetApp account and is instantaneous.

SnapCenter Refresh and Repair scenarios

In the subsequent sections, the functionality and benefits of SnapCenter workflows in two critical scenarios are described. Firstly, how SnapCenter can significantly enhance the efficiency of system refresh operations for QA, test, sandbox, or training systems is explored, ensuring that testing and training environments are consistently updated with the latest data. Following this, the approach to setting up a repair system to address logical corruption is discussed, highlighting the use of Azure NetApp Files snapshot backups to create consistent clones for in-depth analysis and resolution of issues without adversely impacting the production system.

System Refresh of QA, test, sandbox or training systems

There are multiple scenarios in which data from a source system must be made available to a target system for testing or training purposes. These test and training systems must be updated with data from the source system on a regular basis to ensure that testing and training is performed with the current data set. These system refresh operations consist of multiple tasks on the infrastructure, database, and application layers, and they can take multiple days depending on the level of automation.

The SnapCenter workflows can be used to accelerate and automate the required tasks at the infrastructure and database layers. SnapCenter utilizes Azure NetApp Files snapshot backups and cloning technology instead of restoring a backup from the source system to the target system. This allows the necessary tasks up to starting a HANA database to be completed in minutes rather than hours. The time needed for the cloning process is independent of the size of the database, therefore even very large systems can be created in a couple of minutes.

The workflow for system refresh operations is described in this video.

Repair system to address logical corruption

Logical corruption can be caused by software errors, human errors, or sabotage. Standard high-availability and disaster recovery solutions often do not address logical corruption. Therefore, depending on the layer, application, file system, or storage where the logical corruption occurred, it may not always be possible to meet minimal downtime and maximum data loss requirements.

The worst case is logical corruption in an SAP application. SAP applications often operate in a landscape in which different applications communicate with each other and exchange data. Therefore, restoring and recovering a single SAP system in which a logical corruption has occurred is not the recommended approach. Restoring the system to a point in time before the corruption occurred results in data loss. Also, the SAP landscape would no longer be in sync and would require additional postprocessing.

Instead of restoring the SAP system, the better approach is to try to fix the logical error within the system by analyzing the problem in a separate repair system. Root cause analysis requires the involvement of the business process and application owners. For this scenario, you create a repair system (a clone of the production system) based on data stored before the logical corruption occurred. Within the repair system, the required data can be exported and imported to the production system. With this approach, the production system does not need to be stopped, and, in the best-case scenario, no data or only a small fraction of data is lost.

When setting up the repair system, flexibility and speed are crucial. With Azure NetApp Files snapshot backups, multiple consistent database images are available to create a clone of the production system as shown in the figure below. Creating new Azure NetApp Files volumes from a snapshot backup typically takes less than a minute, unlike the hours needed for a redirected restore from a file-based backup.

Summary

NetApp SnapCenter offers data protection workflow orchestration for your HANA landscapes. SnapCenter leverages the created snapshot backups to provide an end-to-end workflow for system refresh operations. The Azure NetApp Files feature set for cloning operations enables the creation of a new volume based on a snapshot in a matter of a minute or less independent of the size of the database.

Additional Information

1. Solution architectures using Azure NetApp Files | SAP on Azure solutions
2. SAP HANA data protection on Azure NetApp Files with SnapCenter
3. SnapCenter Concepts
4. SnapCenter Data Protection
5. SnapCenter Software documentation
6. Install SnapCenter on a Linux host
7. Install SnapCenter on a Windows host
8. TR-4667: Automating SAP HANA System Copy and Clone Operations with SnapCenter