Symptom
To protect your data against data loss usually there is a backup
strategy in place where - during normal database operation - the payload
(the actual data) stored in the data area and log area is saved to data
and log backups at different locations.
This SAP Note provides answers to frequently asked questions about backup and recovery of an SAP HANA database for which an SAP HANA System Replication scenario is configured.
It does not describe how to perform a backup and recovery but emphazises some of the specifics that need to be considered in this kind of landscape.
This SAP Note provides answers to frequently asked questions about backup and recovery of an SAP HANA database for which an SAP HANA System Replication scenario is configured.
It does not describe how to perform a backup and recovery but emphazises some of the specifics that need to be considered in this kind of landscape.
Other Terms
SAP HANA System Replication; Backup; Recovery; Multitenant Database Containers; MDC; FAQ
Reason and Prerequisites
You use an SAP HANA database with SAP HANA System Replication configured.
Solution
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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:
- 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")
- Recover tenantDB
- 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.
- 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.)
- 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.
- 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.
- 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.
- What needs to be considered in a point-in-time recovery of the primary after failback to the original setup?
In a
failback after a takeover from a primary on SiteA to the secondary on
SiteB – you register the former primary (SiteA) as new secondary for the
new primary (SiteB). Following the “register” command, the system
replication is re-established: the new secondary (SiteA) request an
initial data shipping (likely a delta data shipping will do, instead of a
full data shipping) and in parallel the primary (SiteB) starts sending
redo log buffers – and starts writing log backups. This way the roles
are switched in the system replication landscape.
With another takeover and re-register you
can establish your original setup – with SiteA as primary and SiteB as
secondary. Such a primary system is point-in-time recoverable provided
that you have the the following backups are available:
- the data backup of SiteA
- all log backups of SiteA until the takeover
- all log backups of SiteB since this takeover and until the failback (register + takeover)
- all log backups of SiteA since the failback
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.
Header Data
| Released On | 19.10.2015 08:09:31 | ||
| Release Status | Released for Customer | ||
| Component | HAN-DB-BAC SAP HANA Backup & Recovery | ||
| Other Components |
| ||
| Priority | Recommendations / Additional Info | ||
| Category | FAQ |
No comments:
Post a Comment