This is in continuation of my previous blog post Backup and Recovery of SAP HANA Database on Azure using Azure Backup Plugin for HANA – Part II
5. SAP HANA RESTORE
To restore, below permission is required:
◉ Backup Operator permissions in the vault where restore needs to be done.
◉ Contributor (write) access to the source VM that’s backed up.
◉ Contributor (write) access to the target VM:
◉ If restoration is happening to the same VM, this is the source VM.
◉ If restoration is happening on an alternate location, this is the new target VM.
To initiate restore go to Recovery Service Vault → Backup Item and click on the database which needs to be restored and then click on Restore
5.1 Alternate Location
Restore the database to an alternate location and keep the original source database. This method is very useful during the system copies
Target Host, HANA system, Restore DB name needs to be mentioned in this case
Restore point can also be selected as per the requirement
5.2 Overwrite DB
Restore the data to the same SAP HANA instance as the original source. This option overwrites the original database.
Restore point can also be Selected as per the requirement
After clicking on OK, Azure will trigger the restore of the HANA backup
Trigger has been finished successfully
Restore progress can be checked in the Backup jobs of Recovery Service Vault
Execution can also be checked from the OS level of the HANA VM using below command
HDB info
Further traces can be checked in files /usr/sap/<sid>/HDB<nr>/<host>/trace/backint.log and /usr/sap/<sid>/HDB<nr>/<host>/trace/backup.log
According to the size of the database, restore has been finished
Status of the HANA database can be checked using below command from OS console
We can check the status of the SYSTEMDB as well as tenant DB using below query
SELECT DATABASE_STATUS, ACTIVE_STATUS FROM M_DATABASES
Start the Tenant database using below command
ALTER SYSTEM START DATABASE <SID>
Now, connectivity from SAP Application can be checked using R3trans -dx
Now SAP Application can be started.
5.3 Restore as files
To restore the backup data as files instead of a database, choose Restore as Files. Once the files are dumped to a specified path, these files can be taken to any SAP HANA machine where restore needs to be done as a database. Because files can be moved to any machine, restoration can be done across subscriptions and regions.
After specifying the Destination Path on the server and point of recovery click on OK
Restoration of database is going to trigger
Restoration of database has been triggered successfully
Restoration can be monitored from Backup jobs and once the restoration is finished
We can go to the location to which restoration of the file has been done and Based on the type of restore point chosen (Point in time or Full & Differential), one or more folders created in the destination path. One of the folders named Data_<date and time of restore> contains the full and differential backups, and the other folder named Log contains the log backups.
In the Data_<date and time of restore>, all the files are restored
Later, it is necessary to maintain the permission of the files to sidadm and use below command to generate the catalog file for HANA to restore. Extract the BackupId from the JSON metadata file for the full backup, which will be used later in the restore operation. Make sure that the full and log backups are in different folders and delete the catalog files and JSON metadata files in these folders.
hdbbackupdiag --generate --dataDir <DataFileDir> --logDirs <LogFilesDir> -d <PathToPlaceCatalogFile>
In the command above:
◉ <DataFileDir> – the folder that contains the full backups
◉ <LogFilesDir> – the folder that contains the log backups
◉ <PathToPlaceCatalogFile> – the folder where the catalog file generated must be placed
Later HDBSQL commands can be used to restore the database
5.4 Cross Region Restore
As one of the restore options, Cross Region Restore (CRR) allows to restore SAP HANA databases hosted on Azure VMs in a secondary region, which is an Azure paired region.
6. STOP/RESUME BACKUPS FROM AZURE
6.1 Stop Backups
Protection of SAP HANA database can be stopped in a couple of ways:
◉ Stop all future backup jobs and delete all recovery points.
◉ Stop all future backup jobs and leave the recovery points intact.
If option to leave recovery points has chosen, then need to consider below:
◉ All recovery points will remain intact forever, and all pruning will stop at stop protection with retain data.
◉ Cost will there for the protected instance and the consumed storage.
If deletion of data source has done without stopping backups, new backups will fail. To Stop backup go to Recovery Service Vault à Backup Items → select Database → Stop Backup
Select the required options and then click on Stop Backup
Azure will start to perform the operations for the selected database
Database backup has been stopped successfully.
We can see that same data base has been removed from the Backup Items:
6.2 Stop Protection
Unregister an SAP HANA instance after you disable protection but before you delete the vault:
Goto Recovery Service Vault then click on Backup Infrastructure, then click on Workload in Azure VM
Servers will be displayed, in which need to unregister the VM from Azure
Specify the reason and server name as confirmation and click on Delete
Azure will start to unregister the host from Backup
Unregistering is successful
Now list for protected servers are empty
6.3 Resume Backup
When stop protection for the SAP HANA database, if selection of Retain Backup Data option has been chosen, then protection can be resumed later. If backed-up data was not retained then, protection cannot be resumed.
To resume protection for an SAP HANA database:
Open the Backup Item and select Resume Backup.
On the Backup policy menu, select a policy, and then select Save.
7. MANAGING BACKUPS
7.1 Backup Jobs
Azure Backup shows all manually triggered jobs in the Backup jobs section on Azure portal. The jobs seen in this portal include database discovery and registering, and backup and restore operations. Scheduled jobs, including log backups aren’t shown in this section. Manually triggered backups from the SAP HANA native clients (Studio/ Cockpit/ DBA Cockpit) also don’t show up here.
7.2 Backup Alerts
Alerts are an easy means of monitoring backups of SAP HANA databases. Alerts helps to focus on the events about the most without getting lost in the multitude of events that a backup generates. Azure Backup allows to set alerts, and they can be monitored as follows:
Azure Backup allows the sending of alerts through email. These alerts are:
◉ Triggered for all backup failures.
◉ Consolidated at the database level by error code.
◉ Sent only for a database’s first backup failure.
7.3 After Upgrade of HANA
7.3.1 Upgrading from SDC to MDC (SID Changes)
Upgrades from SDC to MDC that cause a SID change can be handled as follows:
◉ Ensure that the new MDC version is currently supported by Azure Backup
◉ Stop protection with retain data for the old SDC database
◉ Perform the upgrade. After completion, the HANA system is now MDC with a system DB and tenant DBs
◉ Rerun the pre-registration script with correct details (new SID and MDC). Due to a change in SID, issues could be faced with successfully running the script, in that case Azure Backup support needs to be contacted.
◉ Re-register the extension for the same machine in the Azure portal (Backup → View details → Select the relevant Azure VM → Re-register)
◉ Select Rediscover DBs for the same VM. This action should show the new DBs in step 3 as SYSTEMDB and Tenant DB, not SDC
◉ The older SDC database will continue to exist in the vault and have old backed up data retained according to the policy
◉ Configure backup for these databases
7.3.2 Upgrading from SDC to MDC (No Change in SID)
Upgrades from SDC to MDC that don’t cause a SID change can be handled as follows:
◉ Ensure that the new MDC version is currently supported by Azure Backup
◉ Stop protection with retain data for the old SDC database
◉ Perform the upgrade. After completion, the HANA system is now MDC with a system DB and tenant DBs
◉ Rerun the pre-registration script
◉ Re-register the extension for the same machine in the Azure portal (Backup → View details → Select the relevant Azure VM → Re-register)
◉ Select Rediscover DBs for the same VM. This action should show the new DBs in step 3 as SYSTEMDB and Tenant DB, not SDC
◉ The older SDC database will continue to exist in the vault and have old backed-up data retained according to the policy
◉ Configure backup for these databases
7.3.3 Version Upgrade (For SDC and MDC Both)
Upgrades to the OS, SDC version change, or MDC version change that don’t cause a SID change can be handled as follows:
◉ Ensure that the new OS version, SDC, or MDC version are currently supported by Azure Backup
◉ Stop protection with retain data for the database
◉ Perform the upgrade or update
◉ Rerun the pre-registration script. Often, the upgrade process may remove the necessary roles. Running the pre-registration script will help verify all the required roles.
◉ Resume protection for the database again
No comments:
Post a Comment