2165547 – FAQ: SAP HANA Database Backup & Recovery in an SAP HANA System Replication Landscape

  1. Where can I find more information about SAP HANA Backup & Recovery and SAP HANA System Replication?
You can find further details about backup and recovery and about SAP HANA System Replication in the SAP HANA Administration Guide on http://help.sap.com/hana_appliance.
Also here is a nice blog containing a step-by-step description of an SAP HANA System Replication and a recovery with the given data and log backups after a takeover was performed:http://scn.sap.com/docs/DOC-53608.
  1. Does the secondary system write backups?
No, the secondary system does not write backups as long as it is running as secondary system – neither data nor log backups. However, after a takeover to the secondary system was done (after it has become the primary system) it immediately starts writing log backups.
  1. Can a secondary system be recovered?
Only primary systems can be recovered with data and log backups. This includes former secondary systems that performed a takeover or which were decoupled from the system replication.
  1. What needs to be considered regarding the backup location?
If the data and log backups are stored in a file system or in a 3rd party backup storage, it is important that the backup location is at a save place and cannot be harmed by a disaster in the data center. It should also be a location that can be accessed – in case of a takeover to the secondary site – also from this other site. Only in that case you are prepared for a recovery of this secondary site (now primary), if this becomes necessary. Because only if you have access to the data backup and log backups taken prior to the takeover, the secondary site is recoverable to its most recent state.
However, you must take care that after a takeover the former primary does NOT write any longer log backups to the same backup location! The cluster management tool you are using should take care of this.
  1. What happens to the log backups after a takeover?
After a takeover to the secondary site the log backups are also written there now. Thus it is essential to stop the original primary writing log backups – especially, if the same location is used by primary and secondary site (which is NOT RECOMMENDED)! This can be reached by either stopping the original primary or by setting the parameter auto_log_backup = false.
  1. What happens if a new tenantDB (in a SAP HANA Multitenant Database Container scenario, called MDC for the rest of this note) is created in a running SAP HANA System Replication?
For the system replication to start also for this tenantDB it must be backed up.
  1. What needs to be considered in a recovery of the primary to its most recent state?
Whenever a recovery to the most recent state of the primary was done, the secondary will trigger the start of the system replication once the primary is online again.
  1. What needs to be considered in a point-in-time recovery of the primary?
Whenever a point-in-time recovery of the primary system was done, the secondary site must be newly registered for SAP HANA System Replication. This is necessary, because if the secondary was not offline during the recovery it immediately starts replication once the primary is online again. Otherwise incompatible and outdated log segments would be send to the secondary, since the data and log volumes changed on the primary site.
  1. What happens if a primary system was recovered with a data backup taken prior to the SAP HANA System Replication configuration?
The secondary cannot connect after the recovery, because the primary does not know anymore that it is part of a system replication configuration. SAP HANA System Replication would have to be enabled again. Then the secondary can re-register.
  1. What happens if a primary system was recovered with a data backup taken while SAP HANA System Replication was active?
If the fullsync option was set in the system replication, the system cannot start after recovery, because no write operations are possible. The fullsync option would have to be disabled (in global.ini).
In an MDC environment where only one single tenantDB needs to be recovered, fullsync would only have to be disabled for this tenantDB. Please proceed as follows:
  1. Disable fullsync for tenantDB – either with SAP HANA studio or in the global.ini (/usr/sap/<SID>/SYS/global/hdb/custom/config/DB_<tenantDB>/global.ini set[system_replication]/enable_full_sync=false and afterwards execute “hdbnsutil -reconfig“)
  2. Recover tenantDB
  3. Enable fullsync again
If the number of hosts was reduced after the backup was taken, then this wrong information is contained in the primary which was recovered with this backup. The number of hosts now differs between the primary and the secondary and this cannot be handled by the secondary. An example would be, if the data backup was done with 5 hosts, and the current system and thus the current secondary only has 4 hosts configured, then SAP HANA System Replication cannot work.
  1. What happens if a primary system was recovered with a data backup from a foreign system while the system replication was active?
If the primary was recovered with a backup taken from another system, the secondary site would have to be re-registered after the recovery. (This kind of recovery is used for system copies.)
  1. What happens if a primary system was recovered with a data backup taken prior to an addhost / addvolume OR until a point-in-time prior to an addhost / addvolume while the SAP HANA System Replication was active?
Recovery to the most recent state is no problem, because during addhost / addvolume automatic backups are created keeping the system recoverable.
A point-in-time recovery, however, requires that the secondary re-registers after the recovery with the same number of active hosts as the primary.
  1. What happens to the SAP HANA System Replication, if a takeover happens while a recovery / tenantDB recovery (in MDC) is running?
In general it should be prevented to perform a takeover while a recovery is running! A cluster manager initiating the takeover must be able to distinguish between an offline status related to maintenance (recovery) or crashes.
If this happens anyway, the secondary takes over and will be in the same state as the primary was prior to its recovery. That is, in the same state that triggered the last data and log shippings. If necessary, the recovery will have to be repeated on the new primary (former secondary) to reach the same state.
During recovery the tenantDB (in MDC) is offline and also has this status on the new primary after takeover. If the tenantDB is then started on the new primary, it is in the same state as it was on the original primary prior to the recovery. The recovery would have to be repeated for this tenantDB on the new primary.
  1. What happens after a successful recovery of a tenantDB (in MDC) …
    • …with a data backup taken prior to the system replication configuration?
    • …with a data backup taken while the system replication was active?
    • …to a specific point-in-time with a data backup taken while the system replication was active?
Until HANA SPS09 the whole secondary site would have to be re-registered, since the persistencies on the primary and the secondary sites now differ and also on the secondary site logs arrived that are newer than the point-in-time to which the primary was recovered.
For HANA SPS10 it is planned to provide a SAP HANA System Replication command that can re-register on volume level (and thus also on tenantDB level) called sr_initialize.
  1. How can the SAP HANA System Replication be used to create a system copy?
You can unregister the secondary site from the configured system replication – in a state, where all services are active and in sync – and bring the system online. However, if you plan to use this system productively, you should rename it and acquire a valid license because this now active seconary system only has a temporary license.
Additionally you must take care that after a system copy which was done in such a way, the backup locations of the former primary and the now actively running former secondary must be strictly separated so that the log backups from the two systems are not getting mixed up.

 

Leave a Reply