Performing Backups & Restore (part 3 of 3)

By Ashwin Venugopal -

 



To read part 1 please click here
To read part 2 please click here


SAP HANA File-Level Backups

While choosing a "file" type to specify a particular path in the file system where SAP HANA can write the backup files, you have to consider the number of data disks which can be limited while the other option of Azure blob storage offers much space with a nice blob storage with some cost benefit.

A geo-replicated storage account can also be used to store the SAP HANA backups providing a dedicated geo-replicated storage account for your dedicated VHDs for SAP HANA backups.

Azure backup agent

It readily helps you to not only backup the complete VMs, but also files and directories through the backup agent already installed in the guest OS. However, you can also copy SAP HANA backup files to a Windows VM on Azure and then use the Azure backup agent from there which might also add some complexity and slow down the backup or restore process, hence this approach isn't recommended to the customers.

Azure storage utilities

You can easily use CLI or PowerShell, or develop your own tool with the help of the Azure SDKs to copy files to Azure storage. You can also select the other options like AzCopy and blobxfer widely used by various customers for production environments to copy SAP HANA backup files. These tools can directly copy the data either to azure blob storage or Azure file share, while also providing a range of promising features like md5, hash or automatic parallelism to copy a directory with multiple files.

Blob copy of dedicated Azure data disks in backup software RAID

In this approach all the data disks are not backed up on a VM to save the whole SAP installation, instead there is a dedicated software named RAID to store  a full SAP HANA file backup which includes only the disks having the SAP HANA backup.

As only the dedicated file system is affected, there are no concerns about the SAP HANA data or log files consistency on the disk and if you want to make sure that no no process should write to the backup stripe set, then you have to unmount it before the blob can copy or mount it again afterwards; or else find an appropriate way to "freeze" the file system (like, via xfs_freeze for the XFS file system).

Copy SAP HANA backup files to NFS share

You can easily store the SAP HANA backup files on an NFS share to make the potential impact on the SAP HANA system low from a performance or disk space perspective. While it can put load on the network and also affects the SAP HANA system to some extent, it creates no impact in managing the backup files.

Copy SAP HANA backup files to Azure files

You can easily mount Azure file share inside an Azure Linux VM, while currently, SAP HANA backup doesn't work with this type of CIFS mount directly and hence it is not recommended.

SAP HANA Snapshot-based Backups

SAP HANA can easily support storage snapshots (for single container systems) except for SAP HANA MCS with more than one tenants. The following steps are followed in the process:
  • Prepare for a storage snapshot by initiating the SAP HANA snapshot
  • Run the storage snapshot (like, Azure blob snapshot)
  • Confirm the SAP HANA snapshot
After you are done with the storage snapshot, you can now confirm the SAP HANA snapshot with the help of an SQL statement to run: BACKUP DATA CLOSE SNAPSHOT

Note- You should confirm the HANA snapshot as it might require extra disk space in snapshot-prepare mode due to "Copy-on-Write" and also you can't move to new backups until SAP HANA snapshot is confirmed first. 

HANA VM backup via Azure backup service

The Azure backup service readily helps in restoring and backing up of a VM with the help of following considerations:

  1. For Linux VMs, only file-consistent backups are possible, since Linus doesn't have an equivalent platform to VSS.
  2. Applications need to implement their own integrity validation mechanism for the restored data.

Hence, it should be confirmed that SAP HANA is in a consistent state on disk whenever the backup starts and also the storage snapshot should be definitely confirmed or abandoned as soon as possible.

Azure backup readily helps in maintaining the file system consistency through Azure VM extensions that only work in pairs with the Azure backup service and has following major phases:

  • Execute prepare script- script needs to create a SAP HANA snapshot
  • Take snapshot
  • Execute post-snapshot script- script needs to delete the SAP HANA snapshot created by the prepare script
  • Transfer data to vault

Restore from application consistent backup against a VM

Azure backup can easily help you to restore Azure VMs as well as disks from Azure VM backup also called recovery points. Restoring the files and folders can only be done only for the Azure VMs deployed using the Resource Manager model and protected by a Recovery Services Vault.

HANA license key & VM restore via Azure backup service

The Azure backup services can help in creating new VMs during restore. You can select either creating a VM during restore, restoring the disks, or restoring the disk contents, after which a new VM can be easily created. Once the new VM is created on Azure, it changes the unique VM ID.

The SAP hardware key used for SAP licensing uses the unique VM ID, due to which a new SAP license should be installed after a VM restore.

SAP HANA VM backup via manual disk snapshot

You can also configure your own backup solution by creating blob snapshots of Azure VHDs manually via PowerShell which may offer more flexibility but does not resolve following issues:

  1. You must still confirm that SAP HANA is in a consistent state by creating a SAP HANA snapshot.
  2. The OS disk can't be overwritten even if the VM is deallocated due to an error stating that a lease exist. 

However, only the data disks of Azure VMs can be restored with the help of following steps:

  1. Verify that SAP HANA was in a consistent state by SAP HANA snapshot feature
  2. Perform file system freeze 
  3. Take blob snapshots from data disks
  4. Perform file system unfreeze
  5. Confirm SAP HANA snapshot
  6. Shut down the VM and detach data disks
  7. Attach new disks based on blob snapshots
  8. Set HANA back to the HANA snapshot 





To read part 1 please click here
To read part 2 please click here










Comments

  1. AnonymousApril 7, 2022 at 8:14 PM

    Performing Backups And Restore (Part 3 Of 3) >>>>> Download Now

    >>>>> Download Full

    Performing Backups And Restore (Part 3 Of 3) >>>>> Download LINK

    >>>>> Download Now

    Performing Backups And Restore (Part 3 Of 3) >>>>> Download Full

    >>>>> Download LINK fp

    ReplyDelete

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different groups of computers, re
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning of alert rule parameter
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can query the log data stor
Read more