HANA Backup Strategy, Recovery Scenarios, and System Replication for High Availability

Explanation

Backup and recovery design for SAP HANA must satisfy two distinct but related objectives: protecting against data loss (recovery point objective, RPO) and restoring service quickly after failure (recovery time objective, RTO). Because HANA is memory-resident, a full understanding of its persistence model is required before designing backups: HANA writes data changes to redo logs continuously and periodically flushes data area savepoints to disk, so a consistent recovery requires both data backups and the redo log chain, not the log alone. A typical on-premise backup strategy combines full data backups on a defined schedule (for example daily or several times per week depending on database size and change volume), continuous log backups to capture redo information, and periodic backup catalog verification to confirm that backups are usable, not merely present on disk. Administrators must size log backup frequency against RPO requirements: if log backups run every few minutes, the maximum acceptable data loss window is bounded by that interval plus any backup transfer latency. Storage location matters too; backups written only to local disk provide no protection against a host failure, so most production designs stream backups to a backup server, external storage, or a supported third-party backup tool integrated via the HANA backint interface. Recovery scenarios differ by cause. A single corrupted table or accidental data deletion may be addressed with a point-in-time recovery to a specific timestamp before the error, replaying data backups plus subsequent log backups up to that point. A full host or storage failure requires restoring the most recent full backup and replaying all subsequent logs to the latest available point, which is why administrators periodically test full recovery procedures rather than assuming backup completion equals recoverability. Recovery testing on a non-production system is a standard due-diligence practice precisely because untested backups are a frequent source of failed disaster recovery exercises. HANA System Replication (HSR) addresses high availability and disaster recovery beyond backup/restore by maintaining a secondary HANA instance that continuously receives log data from the primary. Depending on the replication mode configured (synchronous, synchronous in-memory, or asynchronous), HSR provides different trade-offs between data protection and performance impact on the primary: fully synchronous modes minimize data loss on takeover but can add commit latency, while asynchronous modes reduce primary-side impact at the cost of a small potential data loss window on failover. A secondary site can be configured for automatic or manual takeover; automatic takeover shortens RTO but requires careful design to avoid unwanted failovers during transient network issues, often mitigated with a third site or quorum mechanism in the replication topology. In S/4HANA landscapes, HSR is commonly paired with SAP's high-availability guidance for the application layer so that a database takeover is coordinated with application server reconnection, rather than treating database and application availability as independent problems. For disaster recovery across regions, organizations combine HSR to a remote site with backup-based recovery as a fallback path, since replication protects against most failures but not against logical corruption that replicates to the secondary as well. In SAP-managed cloud environments such as HANA Cloud, backup scheduling, retention, and often the underlying replication/HA topology are managed by SAP according to the service's stated capabilities, and customer administrators typically interact through cockpit-level backup and restore operations rather than configuring backint or replication topology directly; exact capabilities should be confirmed against current service documentation rather than assumed to mirror on-premise HSR.

Code example

-- Trigger an on-demand full data backup (on-premise HANA, via SQL)BACKUP DATA USING FILE ('/hana/backup/data/FULL_BACKUP_20240115'); -- Check current backup catalog entriesSELECT ENTRY_ID, ENTRY_TYPE_NAME, STATE_NAME, BACKUP_START_TIME, BACKUP_FINISH_TIMEFROM M_BACKUP_CATALOGORDER BY BACKUP_START_TIME DESC; -- Check log backup configuration mode (log_mode should be 'normal' for point-in-time recovery)SELECT KEY, VALUE FROM M_INIFILE_CONTENTSWHERE FILE_NAME = 'global.ini' AND SECTION = 'persistence' AND KEY = 'log_mode'; -- Check System Replication status on the primary site (hdbnsutil / python script via OS command)-- hdbnsutil -sr_state-- Expected output includes: mode: sync | syncmem | async, and site mapping (primary/secondary) -- Example takeover command executed on the secondary during a DR test (run as <sid>adm)-- hdbnsutil -sr_takeover

Real project scenario

A financial services customer running S/4HANA on-premise required an RPO of under fifteen minutes and an RTO under one hour for their production database. The Basis and infrastructure teams implemented synchronous System Replication to a secondary data center for high availability, backed by daily full backups and fifteen-minute log backup intervals streamed to a backup server for disaster recovery beyond the replication scope. During a scheduled DR test, the team performed a controlled takeover to the secondary site and validated application reconnection, then separately restored a database copy from backup and log replay on an isolated system to confirm the backup chain was independently recoverable. The exercise revealed that one custom monitoring job had hardcoded the primary host name, which was corrected before the next production maintenance window.

Common mistakes

• Treating a completed backup job as proof of recoverability without periodic restore testing • Configuring log backups too infrequently for the required RPO, widening the potential data loss window • Assuming System Replication alone removes the need for backups, ignoring protection against logical corruption • Choosing asynchronous replication for a use case that actually requires zero data loss on takeover • Overlooking application-layer reconnection and hardcoded hostnames when testing database-level failover • Assuming cloud-managed backup and HA capabilities match on-premise HSR configuration options without verification

Best practices

• Define RPO and RTO requirements explicitly before selecting backup frequency and replication mode • Stream backups off the primary host to independent storage or a backup server, never local disk only • Test full point-in-time recovery and DR takeover procedures on a scheduled basis, not only during real incidents • Coordinate database takeover procedures with application-layer reconnection steps for S/4HANA landscapes • Verify backup catalog integrity regularly rather than assuming job success equals a usable backup • Confirm current managed-service capabilities before assuming cloud HANA backup or HA behavior mirrors on-premise HSR

Interview angle

Senior candidates are expected to articulate the difference between backup/restore and System Replication as complementary, not interchangeable, protections, and to reason about RPO/RTO trade-offs across synchronous versus asynchronous replication modes. Strong answers reference concrete testing practices, such as periodic restore drills and DR takeover exercises, rather than describing backup configuration purely in theoretical terms.