LinkedIn
Twitter
Introduction
System recoveries, system copies and system refreshes are a crucial aspect of SAP system management. These processes allow organizations to safeguard their systems and to quickly restore systems after unexpected failures, create replicas of their production environment for testing, development, disaster recovery and system refresh. Conventional methods involve complex processes and often require significant downtime, impacting business operations.
Google Cloud offers a streamlined and efficient solution for addressing above challenges using backup snapshots. By leveraging the Disk Snapshot feature of Google Cloud’s Agent for SAP, you can create point-in-time snapshots of your organization’s SAP HANA databases, and use the snapshots as the source for above operations. Additionally, you can combine the disk snapshot feature with traditional Backint based database backups to recover your SAP HANA database to a specific point in time.
In this blog, we will explore the benefits of using snapshots of your SAP HANA data volume for SAP system copy and provide step-by-step instructions for:
- Recovering the target system by using disk snapshots.
- Combining disk snapshots and Backint based backups to recover the target system to a specific point in time.
This example can be extrapolated to system recoveries and system refreshes as the overall process is similar.
Benefits of using disk snapshots for SAP System Copy
- Reduced Downtime: Disk snapshots enable near-instantaneous system copy, minimizing downtime and ensuring minimal disruption to business operations.
- Simplified Process: The system copy process is greatly simplified by using backup snapshots, eliminating the need for more time consuming backup and restore process.
- Integration with SAP HANA Tools: The snapshot process integrates seamlessly with SAP HANA's own backup and recovery tools, streamlining your operations.
- Cost-Effective: Snapshots offer a cost-effective solution for system copy, as organizations only pay for snapshot storage.
- Secure and Reliable: Google Cloud provides robust security measures, including encryption at rest and in transit, ensuring the confidentiality and integrity of SAP data during the system copy process.
- Scalable: Google Cloud’s scalable infrastructure can accommodate large SAP system copies, enabling organizations to easily scale their SAP environments as needed.
Step-by-step guide to performing SAP system copy using a snapshot
Pre-requisites (both source and target systems)
- SAP HANA is installed and configured. The SAP HANA version number of the target database must match or be higher than the source database (Reference)
- The target and source systems are single-node (scale-up) systems
- The SAP HANA Data and Log Volumes are located on separate disks and managed via LVM
- The Google Cloud SDK is installed - Guide
- Google Cloud’s Agent for SAP is installed, as outlined here
- Backint based backup and recovery is configured, and verified data and logs are successfully backed up to Cloud Storage. For Point-in-Time Recovery, log backups are required - GCP backint guide
- Store SAP SYSTEM passwords in Secret Manager (Recommended) though Google Cloud’s Agent for SAP has an option to accept plain text password
Example system
For this example, we will use below system information
|
System |
SID |
Database VM |
GCS bucket |
Data Disk Name |
|---|---|---|---|---|
|
Source - Production |
PRD |
prd-vm |
prd-backup |
prd-vm-data |
|
Target - Stage |
STG |
stg-vm |
stg-backup |
stg-vm-data |
Create a snapshot of the SAP HANA source database (PRD)
- Login as root or any user with appropriate authorization for snapshot management. A list of required commands and how to create a sudoers group with the required permissions can be found here with appropriate authorization for snapshot management.
- List all disks attached to the VM and identify the disk hosting the SAP HANA data volume:
gcloud compute instances describe prd-vm --zone=VM_ZONE \
--format=”value(disks.deviceName)” - Create a snapshot using Google Cloud’s Agent for SAP:
sudo google_cloud_sap_agent hanadiskbackup -host=localhost \
-port=30013 -sid=PRD -hana-db-user=SYSTEM \
-source-disk=prd-vm-data -source-disk-zone=VM_ZONE \
-password-secret=SECRET-NAME - Verify that Snapshot is created successfully. Make a note of the name of the snapshot. You will need that while restoring the target system.
gcloud compute snapshots list --filter="sourceDisk=prd-vm-data"
You can also query the SAP HANA backup catalog for the entry related to the data snapshot you created:
SELECT BACKUP_ID, STATE_NAME, COMMENT FROM M_BACKUP_CATALOG WHERE ENTRY_TYPE_NAME = 'data snapshot'
BACKUP_ID,STATE_NAME,COMMENT 1701903965347,"successful","snapshot-prd-vm-data-20240410-141028"
Restore snapshot to the target SAP HANA instance (STG)
Use Google Cloud’s Agent for SAP to restore the snapshot to the target SAP system. The agent accepts a parameter for the new disk name. The restored disk will be mounted as /hana/data after detaching the current data disk.
- Find all snapshots for the source data disk (prd-vm-data):
gcloud compute snapshots list --filter="sourceDisk=prd-vm-data" - Identify the snapshot to be restored and provide that in source-snapshot parameter:
sudo google_cloud_sap_agent hanadiskrestore -sid=STG \
-source-snapshot=snapshot-prd-vm-data-20240410-141028 -data-disk-name=stg-vm-data \
-data-disk-zone=ZONE -new-disk-name=NEW-DATA-DISK-NAME - Change directory name(s) and permissions as the new disk is a copy of source system (PRD):
mv /hana/data/PRD /hana/data/STG
chown -R stgadm:sapsys /hana/data
Recover target database (STG)
Use Case 1: Recover the database to the time the snapshot was created
As <sid>adm, run:
HDBSettings.sh recoverSys.py --command "RECOVER DATA USING SNAPSHOT CLEAR LOG"
hdbsql -U hdbuserstore_key_name_to_systemdb "RECOVER DATA FOR STG USING SNAPSHOT CLEAR LOG"
Use Case 2: Recover the database to a specific point in time
Use a Backint based backup to apply logs to perform Point-in-Time Recovery. You can access the Cloud Storage bucket (which stores the source database’s backup) from the Target database by updating the recovery_bucket parameter. Follow the specification found here.
Sample backint parameter file → /usr/sap/STG/SYS/global/hdb/opt/backint/backint-gcs/parameters.json
{
"bucket": "stg-backup",
"log_to_cloud": true,
“recovery_bucket” : “prd-backup”
}
As <sid>adm execute the following steps:
HDBSettings.sh recoverSys.py --command "RECOVER DATABASE UNTIL TIMESTAMP 'YYYY-MM-DD HH24:MI:SS' CLEAR LOG USING SOURCE 'SYSTEMDB@PRD' USING CATALOG BACKINT USING SNAPSHOT"
hdbsql -U hdbuserstore_key_name_to_systemdb "RECOVER DATABASE FOR STG UNTIL TIMESTAMP 'YYYY-MM-DD HH24:MI:SS' CLEAR LOG USING SOURCE 'PRD@PRD' USING CATALOG BACKINT USING SNAPSHOT"
Recover all tenants if there is more than one using the above procedure. After successful recovery, remove recovery_bucket parameter from backint parameter file (parameters.json) so that any future recovery of STG system will use default backup bucket parameter.
Perform post-processing tasks, such as updating the SAP system configuration, update SYSTEM passwords, backup database and any customization specific to the instance.
Conclusion
Disk snapshots coupled with Google Cloud’s Agent for SAP, alongside traditional backup and recovery, provide a powerful and efficient solution for database recoveries and system refreshes. This simplifies operations, minimizes downtime, and reduces costs for your organization. Google Cloud's robust infrastructure and security ensure smooth SAP system copies and safeguarding your business-critical operations
Recovery time will vary depending on the size of your SAP HANA database. A traditional Backint based recovery can take significantly longer compared to the Disk Snapshot feature of Google Cloud's Agent for SAP. The Disk Snapshot method offers a substantial reduction in runtime, potentially saving you a vast majority of the recovery time.
