Skip to Content

Overview

One typical use case managed by SAP Landscape Management is refreshing a system – overwrite the content of an existing target system with actual data from the source system while maintaining system topology and configuration. General SAP Landscape Management functionality allows to manage such an exercise via a “Storage Based” or “Virtualization Based” approach:

  • In a “Storage Based” scenario – the clone/copy of the database happens at storage volume level. SAP Landscape Management triggers the required action in the storage system via the integrated Storage Adapter: Each of the required source volumes is copied to a target volume levering functionalities in the storage hardware. Those storage volumes are later on accessed on a new or existing host and then form the content of the database system.
  • A “Virtualization Based” approach is possible too, but practically only for “smaller” system sizes: Then, an entire virtual machine, including the database footprint, is cloned to a new image. This cloned image gets then installed to another VM.

Both “Storage Based” and “Virtualization Based” scenarios rely on specific infrastructure requirements – e.g. source and target systems need to reside within the same storage system or virtualization manager boundaries. This introduces some dependencies on the underlying IT infrastructure.

For SAP HANA 2.0 databases, SAP Landscape Management 3.0 has the
integrated functionality to refresh the content using a database backup.

This removes the dependencies on the underlying infrastructure, and provides the functionality even in case that there is no “Storage Adapter” available for the storage system in scope.

This text gives a short overview about the required steps for the required configuration settings within SAP Landscape Management (and the LINUX operating system) to execute such an “Restore-based Refresh” for a SAP HANA database.

Preparation in SAP Landscape Management

General prerequisites for SAP System Copy

All the general preparation settings for SAP System Copy need to be configured first in SAP Landscape Management:

  • The infrastructure assignment defining all the infrastructure components needs to be completed: network definitions, user management methods, eventually name server update and proxy settings are defined.
  • The Software Provisioning Manager Configuration for System Copy or System Rename

In addition, the source system needs to be enabled for the Refresh Scenario.
Verify that the source system is enabled for Cloning / Copying in the System Configuration:

and ensure that the required RFC users for Post-Copy Automation are created on the source- and target system and are defined in the SAP Landscape Management System configuration.

SAP HANA backup share

The “Restore-based Refresh” requires a complete data backup of the source system. The data backup needs to be stored on a central filesystem, which then will be mounted on the target during the process.

In the example, we have a local filesystem on the source database with a set of backups:

For simplicity, I’ve used a local filesystem on the source system for the SAP HANA backup share, and exported it via NFS to the target system – the SAP HANA backup share could also be stored on a NFS/NAS server and then get mounted to both source and target system.

SAP HANA backup share – definition in the system configuration in SAP LaMa

This “SAP HANA Backup Share” gets defined in the system configuration of the source system (in the tab “Provisioning & RFC”, section “Transfer Mount Configuration for System Provisioning”) within SAP Landscape Mangement: During the restore-based refresh SAP LaMa will then ensure that the share is mounted on the target system and so the SAP HANA backup image can be accessed for the restore.

The mount options specify who the share shall be mounted on the target system during the process – “read only (ro)” is sufficient, unless you want to use the share also for storing backups of the target system.

When it is configured, the HDB backup share gets visible in the configuration view:

NFS Server configuration on the source system

In case of a “local” NFS server on the source system, add the HDB Backup Share to the NFS server export table. In the LINUX operating system, the file /etc/exports contains the table of local physical file systems on an NFS server that shall be made accessible to NFS clients.
The content of the file needs to be maintained by the root user:

vi /etc/exports
/hana/backup/data/DB_S4P          *(ro,sync,no_subtree_check)

Add the “export path” on the local server to this file (in our case “/hana/backup/data/DB_S4P”)
Ensure that the NFS services are started.

In SLES12, start (or restart) the NFS services as user root via command:

> systemctl restart nfsserver
> exportfs
/hana/backup/data/DB_S4P                <world>

With the “exportfs” command, you can verify the NFS export on the source system.

Execute Restore-Based Refresh

Now, you’re ready to invoke the restore-based refresh in SAP Landscape Management

Navigate to Provisioning > Systems and AS, then select the system to be refreshed,
and choose “Restore-Based Refresh”

The roadmap for entering all the required parameters will start.

In the Basic tab enter the master password
– which will be used as default password for all the next steps.
(As usual, you need to obey the SAP password rules for it), and choose Next

The Hosts tab appears.
The hosts should be preselected according to the refresh scenario. Press Next

The Host Names tab appears.
In a refresh scenario, the virtual hostnames typically remain unchanged. Press Next

The (OS) Users tab appears.
Due to the refresh, also the OS users should be already existing. Press Next.

Now, the selection tab for the Database Restore appears.
Select one of the available backups from the HANA Backup Share, then press Next:

In the Rename tab, Enter the SYSTEM password for the respective tenant, and press Next:

In the Isolation tab, the NFS server exporting the HANA DB share should get visible in the “allowed” communications. Press Next

Finally, in the ABAP PCA tab enter the Post Copy Automation tasklists for the clients in scope, and press Next:

Finally, start the Database Refresh Workflow in the Summary tab

The Database Refresh will be invoked, and the backup will be used for refreshing the content:

Summary

The functionality to refresh the content using a database backup provides a simple way for executing the system refresh for systems with SAP HANA 2.0 databases.
The procedure relies on the exchange of the backup data, and can be easily used/ adapted for various refresh scenarios.

As my current SAP LaMa system was not on the latest SP, and there is a lot of work on transitioning to the UI5 user interface the graphical impression shown here maybe different on your system – however the general approach still will work.
(I will retest once we moved to the recent SAP LaMa 3.0 SP9 …)

For SAP HANA (2.0) databases, this functionality is integrated into SAP LaMa.
For other databases, a similar approach can be achieved via a custom provisioning process –
a custom provisioning process also offers the capability to integrate with a backup/ restore.

 

 

 

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Benny Märcz

    Hi Edmund,

    thanks for writing this post! I’m using the storage-based approach regularly and never tested the restore-based system refresh. At least I have an idea now, what this would look like. Thank you!

    Kind regards,

    Benny

    (0) 

Leave a Reply