Refreshing a SAP HANA Database using a database backup
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:
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:
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.
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!
Will be able to do a restore based refresh in lama if the target system is not provisioned as Installation and not as a copy.
you can edit the properties of the target system in the "Configuration" > "Provisioning and RFC settings" section of SAP LaMa, and modify the "System and AS Provisioning" settings from
"This system was provided by: Installation" to "This system was provided by: Copy".
You then can select the appropriate source system - and execute the refresh.
The refresh will be executed use a backup of the newly defined source system.
Hope this helps,
Thank you for your reply ,i have tried the above option earlier trying to the change the provisioning to copy for the target system but the drop down is not getting populated for me to define source system.
one additional question - In Configuration > Systems,
do you have enabled the source system in "Provisioning & RFC" as
"This system can be used for: Copying, Cloning" ?
Yes Source system has been marked for Copying and Cloning.
Hm ... A good question what's the difference ...
On my SAP LaMa system the scenario worked perfectly: Once I've "enabled" a system for system copy, I was able to "select" that one as the new "source" for a refresh on the target system, and then execute the refresh ...
Do both systems have the same SAP HANA version?
Or are there any other major differences in the system definition in SAP LaMa?
Hana Revision's are same and i don't see any noticeable difference in the System definition in LAMA . Was your target is provisioned through LAMA cloning process or both target and source are installed and added to LAMA and later configured for Refresh?
In my case, the source was installed from scratch, and the target was then created as a copy from scratch. Then I installed another (source) system, and was later on able to "redirect" the source system for the refresh to the "new" source...
Ohh ok As per my understading from SAP documentation i guess Refresh from LAMA is only possible if target is built as a copy.