Posted by This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.
Table of Contents
Disaster Recovery Failover Testing
System refresh of QA, test, sandbox, or training systems
Repair system to address logical corruption
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 BlueXP backup and recovery. BlueXP leverages Azure NetApp Files snapshot and volume cloning capabilities and offers end-to-end workflows for data protection and SAP system refresh operations.
Co-authors: Nils Bauer – SAP Technical Marketing Engineer (NetApp)
Introduction
When snapshots have been implemented to protect your SAP HANA systems, these can also be used to address other use cases, which require copies of an SAP HANA database. The implementation of snapshot operations is described in detail in the blog SAP HANA on Azure NetApp Files - Data protection with BlueXP backup and recovery. With Azure NetApp Files, you can create a new volume based on the content of any available snapshot in a matter of a minute or less, independent of the size of the volume. This allows us to quickly create HANA system copies or clones for various test scenarios.
Scenarios and use-cases
Using Azure NetApp Files’ advanced data management features leveraging snapshots allows us to quickly create HANA system copies or clones for various test scenarios.
SAP System Refresh
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 to new volume 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 must be attached to the test system and the SAP HANA database recovered.
Repair System
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 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 from a moment before it got corrupted.
Disaster Recovery Failover Testing
The last use case is the ability to run a disaster recovery failover test, without stopping the replication and therefore without influencing RTO (Recovery Time Objective) and RPO (Recovery Point Objective) of the disaster recovery setup.
When Azure NetApp Files cross-region replication is used to replicate the data to the DR (Disaster Recovery) site, the production snapshots will be available at the DR site as well and can then be used to create a new volume for disaster recover testing.
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 regularly 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 BlueXP System Refresh workflow can be used to accelerate and automate the required tasks at the infrastructure and database layers. Instead of restoring a traditional stream-based backup from the source system to the target system, BlueXP uses the Azure NetApp Files snapshot and restore to new volume technology, so that the required tasks up to a started HANA database can be performed in minutes instead of hours. The short time needed for the restore to a new volume (‘clone’) process to enable access to the new volume 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. Logical corruption often cannot be addressed with standard high-availability and disaster recovery solutions. As a result, depending on the layer, application, file system, or storage where the logical corruption occurred, minimal downtime and minimal data loss requirements can often not be fulfilled.
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 owner. 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 snapshots, multiple consistent database images are available to create a ‘clone’ of the production system as shown in the figure below. New Azure NetApp Files volumes based on a snapshot are created in a matter of a minute or less rather than multiple hours if a redirected restore from a file-based backup is used to set up the repair system.
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:
- Source and target HANA system must be in the same VNet (Virtual Network), so that the target HANA system can mount the new volume created from the source snapshot.
- If different VNets are used, they must be VNet peered to provide access to the new volume. Additional cost for cross VNet traffic must be considered in such a configuration.
- The BlueXP system refresh 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.
Summary
NetApp BlueXP backup and recovery offers data protection workflow orchestration for your HANA landscapes. BlueXP leverages the created snapshots 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.