SAP HANA backup and recovery: Backint, log backups, and the scenarios that matter

A backup strategy is only ever tested for real during a recovery, and by then the decisions were made months earlier. The parameters that decide whether you can recover to the second before a bad transport — or only to last night's data backup — are set once and rarely revisited. This is a practitioner's walk through HANA's backup types, the Backint interface, the log_mode trap that quietly removes point-in-time recovery, and the handful of catalog checks worth watching continuously.

The backup types, and what each one actually captures

HANA persists committed data to the data volume at savepoints and streams redo to the log volume continuously. A data backup is a consistent copy of the data area; log backups are the redo written since, and they are what turn a static data backup into a recoverable point in time. The delta variants exist to shorten either the backup window or the restore chain.

Differential and incremental both trade restore simplicity for a smaller backup footprint. A differential is self-contained relative to the last full; an incremental chain must be applied in order and breaks if a link is missing. Neither removes the need for log backups — they only reduce how much data has to be re-read from data backups before log replay begins.

File-based versus Backint

A data or log backup has to land somewhere. The two destinations HANA understands are a filesystem path (typically /hana/backup) and Backint — the certified interface a third-party backup tool implements so HANA streams the backup straight into the tool's backend rather than to a local mount. On AWS that backend is usually object storage (S3); on-premises it is whatever the enterprise backup product manages.

File-based is simple and needs no extra software, but the backup files then have to be copied off the host by something else, and a large HANA fills /hana/backup quickly. Backint removes the local staging step: the backup is written directly to durable, off-host storage as it is produced, which matters most for large databases where a local copy is both slow and space-prohibitive. The destination of a given backup is recorded in M_BACKUP_CATALOG_FILES.DESTINATION_TYPE_NAME (file or backint), so you can confirm from SQL that backups are actually going where policy says they should.

Log mode: 'normal' versus the 'overwrite' trap

The single parameter that decides your recovery ceiling is log_mode in global.ini [persistence]:

• normal — log backups are taken, log segments are freed only after they are backed up, and point-in-time recovery is possible. This is the only correct setting for production.
• overwrite — no log backups are taken; log segments are freed at the next savepoint. You can only recover to a data backup, losing everything since. It is meant for sandboxes and load-and-throw-away systems.

overwrite is a trap in production because nothing breaks day to day — the database runs fine, data backups still succeed, and the missing capability only surfaces at the one moment you need it. A system quietly left in overwrite can lose a full day of transactions at restore. Switching to normal requires a restart and a fresh complete data backup before log backups begin, so it cannot be flipped on retroactively to recover an incident that already happened.

The mirror-image risk under normal: if log backups stall — a full backup destination, a broken Backint agent, a wedged backup job — the log area cannot free segments and keeps growing until the log volume is full, at which point the database stops accepting transactions. A stalled log backup is therefore not just a recovery gap; it is a countdown to an outage. Watch free space in the log area (M_DISK_USAGE, M_LOG_SEGMENTS) alongside the fact that log backups are advancing at all.

Reading the backup catalog

The backup catalog is the source of truth for what was backed up and whether it succeeded. M_BACKUP_CATALOG holds one row per backup entry with its type and state; M_BACKUP_CATALOG_FILES holds the individual files/pipes and their destinations. Two questions matter operationally: when was the last successful data backup, and are log backups still flowing.

-- Last successful backup of each type, and how many succeeded.
-- ENTRY_TYPE_NAME = 'complete data backup' / 'differential data backup'
--                   / 'incremental data backup' / 'log backup' / 'data snapshot'
SELECT ENTRY_TYPE_NAME,
       MAX(SYS_END_TIME)  AS last_successful,
       COUNT(*)           AS successful_entries
FROM   M_BACKUP_CATALOG
WHERE  STATE_NAME = 'successful'
GROUP  BY ENTRY_TYPE_NAME
ORDER  BY ENTRY_TYPE_NAME;

-- Are log backups actually advancing? If this timestamp stops moving,
-- the log area will eventually fill and stop the database.
SELECT MAX(SYS_END_TIME) AS newest_log_backup
FROM   M_BACKUP_CATALOG
WHERE  ENTRY_TYPE_NAME = 'log backup'
AND    STATE_NAME      = 'successful';

-- Where did the most recent data backups land -- file or backint?
SELECT c.ENTRY_TYPE_NAME, c.SYS_END_TIME, f.DESTINATION_TYPE_NAME
FROM   M_BACKUP_CATALOG      c
JOIN   M_BACKUP_CATALOG_FILES f
       ON  c.BACKUP_ID = f.BACKUP_ID
WHERE  c.STATE_NAME = 'successful'
AND    c.ENTRY_TYPE_NAME LIKE '%data backup'
ORDER  BY c.SYS_END_TIME DESC;

Note the catalog is per database. On a single-node non-MDC system it is straightforward; on a scale-out or multitenant system you read it from each database independently — covered below.

Recovery scenarios, and what each one needs

"Do we have backups" is the wrong question. The right one is which recovery you can perform, because each scenario has different prerequisites. If any piece is missing, that scenario is off the table regardless of how many data backups exist.

Only the first two require an intact log-backup chain. The third is the fallback you are forced into when log backups are missing — and it is exactly what overwrite silently limits you to.

System replication is disaster recovery, not a backup

If the database is protected by HANA System Replication (HSR), it is tempting to treat the secondary as a backup. It is not. Replication faithfully ships every change — including the logical mistakes: a dropped table, a bad mass update, and a corruption that propagates all reach the secondary too. HSR protects against losing a site or a node; it does nothing against losing data to a logical error. You still take data and log backups on an HSR-protected system, and the recovery scenarios above are still how you undo a bad change. Replication and backups are complementary layers, not substitutes — the performance checklist covers watching the replication state itself.

Multitenant: SYSTEMDB and each tenant are independent

On a multitenant (MDC) system, SYSTEMDB and every tenant database are backed up and recovered independently. Each has its own backup catalog, its own log_mode, and its own recovery. A clean SYSTEMDB backup tells you nothing about whether a tenant's backups ran, and recovering one tenant does not touch the others. The practical consequence: backup posture has to be checked per database, and a monitoring layer has to present all of them without letting one tenant's catalog leak into another's view.

What to monitor: alert versus trend

Backup monitoring fails in two directions — alerting on nothing until a restore fails, or alerting on so much noise that the one real signal is ignored. The split that works:

The two non-negotiable alerts are the age of the last data backup and whether log backups are still running — everything else is a slower-moving conversation about capacity and windows.

How Farrenio fits

Farrenio watches backup posture across every HANA database it monitors — the age of the last successful data backup, whether log backups are actually advancing, and free space in the log and backup areas — reading each SYSTEMDB and tenant independently and keeping the tenant boundary intact, with an audit trail behind every catalog read. It sits next to the rest of HANA monitoring, so the backup view and the memory/replication view are one screen rather than two tools, and it pairs naturally with the HANA performance monitoring checklist. To see your own SIDs' backup posture on one board, write to contact@farrenio.com and we will scope a short trial on a non-production database.