Speed Up Your SAP HANA System Copies Using Azure NetApp Files

In some of my previous blogs I’ve covered the topic of SAP HANA system copies. You may wonder, why is this such a prominent theme? It’s important because SAP customers benefit from having a fast and space efficient way of creating system copies. And customers who want to run their SAP system in the cloud are looking for an enterprise feature to improve the process of making system copies.

SAP system copies

To understand the importance and variety of system copies, let’s start with a typical SAP system landscape. Customers need to install the system landscape to ensure that customizations and developments can be made and tested before they are released to production. A few customers may have small landscapes, but most have larger SAP landscapes of 100 or more individual systems with different SAP software running, often dedicated to different organizational units of the company.

As shown in the following figure, the most basic setup is a three-system landscape with development, QA and test, and production systems (DEV  QAS  PRD). Customers want to test their development in an environment that is as close as possible to the production environment, so the QA and test system should be periodically refreshed with current data from the production system.

System refresh

In the basic system refresh process, you take a backup copy of the production system and restore it to the QA system. After this technical restore, you need to make the following adjustments:

• SAP technical adjustment to change the system ID and all the related activities to convert the production system into a new QA system
• Logical adjustment to (for example) remove or mask some critical data and adjust user rights and privileges

Many customers need to support different project teams to test settings outside of the development system. Some of those settings introduce irreversible changes to the system, and others might never be included in the main development. Therefore it’s advisable to develop and test in a separate ”sandbox” system.

Many customers even create a temporary system landscape to test—for example, an upgrade of a SAP landscape or other large changes. For this purpose, the development system is copied and, to test these massive changes with “close to production” data, the production system is used as a source to create a dedicated QA system for this development strand. (See the systems DP1 and QP1 in the figure above.)

System Copy

Creating a system copy basically means installing a new system based on an existing one. As part of the system copy process, all the post-copy activities need to be applied, as described in the previous section. System copy and system refresh are closely related. The main difference is that a system refresh updates the target system periodically with data from the source system, while a system copy builds a new system based on an existing system as the source.

But what happens if there is a logical error in production, or if some data is accidentally deleted? There are cases where a restore and recovery of the system is not the right solution, because that would reset the whole system, including all the data that has already been created or changed. In that case, it’s necessary to have a clone of the system from before the error happened, to be able to restore the lost data. In such an emergency situation, you don’t want to go through the post-copy activities, because the post-copy changes are often not wanted; you need the clone to be as exact as possible to be used as a repair system.

Repair system

The main difference between a repair system and a system copy is that you must not change the system ID or apply any other changes. Therefore the new system must be isolated or firewalled to ensure that the copy of the production system does not interfere with any connected systems.

Technical implementation and relevance for the cloud.

As you can see, SAP system copy, clone, refresh and repair workflows are part of every SAP administrator’s work list. The technical basis for these workflows is an offline or online backup of the underlying database or file systems. Based on the size of the database, the backup and restore process can take up to several hours, and it has an impact on the source system itself, which customers usually want to avoid.

With Azure NetApp Files, application-consistent backups are based on snapshots. They are fast, with almost no impact on capacity of the storage and no impact on performance on the source system. With a simple API command, or through the Azure portal, customers can create a new volume based on such a snapshot copy, which replaces a lengthy file-based backup and restore cycle. This storage clone is done in minutes and can be instantaneously used to start the nontechnical post-copy activities; or, in the case of a repair system, to apply the necessary redo logs to move to the point in time before the error happened.

These are the enterprise features that are required to allow enterprise applications such as SAP HANA to benefit most from the elasticity and flexible environment of a cloud deployment.

The following video demonstrates a system refresh workflow for SAP HANA based on a fast snapshot-based clone of an Azure NetApp Files data volume.

To see how to use Azure NetApp Files to create a SAP HANA storage-snapshot-based backup, read my blog - Azure NetApp Files - SAP HANA Backup in Seconds.

For more information, see the following technical reports and web pages:

• Solutions for SAP applications with Azure NetApp Files
• NetApp Cloud Central
• SAP Solutions on Azure
• TR-4746 SAP Applications on Microsoft Azure Using Azure NetApp Files

Join us at SAP TechEd in Las Vegas

Finally, don’t miss the chance to talk with me and my colleagues in person. NetApp will be at SAP TechEd in Las Vegas, September 24-27. Please visit us at Booth #401. We’ll be there to answer any questions and help you implement the best cloud strategy for SAP.