SAP Database Administration Basics (Backup, Recovery, HANA Admin)

Core DBA responsibilities in an SAP context: backup strategy, recovery scenarios, and HANA-specific administration tasks.

A failed backup is a Basis incident as much as a DBA one. These are the parts an SAP administrator is expected to know regardless of who owns the database.

Full and log backups are like saving a complete document plus a change-tracking log of every keystroke since - point-in-time recovery lets you rewind to exactly 2:47pm before the accidental delete, rather than only being able to restore to last night's save. HANA System Replication is like a live mirror of your screen on a backup laptop, ready to take over in seconds rather than reloading from a saved file.

Key Concepts

Backups come in layers, and the log backups are the ones that matter.

    full           a complete recoverable baseline
    incremental    what changed since the last backup
    differential   what changed since the last full
    log            the transaction log, every 15-30 minutes

Why log backups are the critical ones. A full backup restores you to last night. Log backups replay transactions forward from there, so you can stop at 14:32 — just before the bad update ran.

Without them the recovery point is the last full backup, and everything since is lost. With them it is minutes. That is the whole argument for frequent log backups, and for monitoring that they are actually succeeding.

Point-in-time recovery, in order: restore the full backup, apply the log backups in sequence, stop at the chosen moment. The rehearsal matters more than the procedure — an untested backup is a belief.

HANA specifics. Backups run from DBACOCKPIT or HANA Cockpit: data backups, log backups, and optionally storage snapshots, which use the storage layer to capture very large volumes almost instantly.

DBACOCKPIT

System replication is a different thing from backup. HANA System Replication continuously ships log changes to a standby system, usually at another site, so failover takes minutes and loses almost nothing.

    backup / restore   hours to recover, cheap
    system replication minutes to recover, a second system to pay for

They solve different problems. Replication covers a site or hardware failure; it does not protect you from a bad DELETE, because that replicates perfectly to the standby. Backups cover the mistake; replication covers the outage. Any serious system has both.

DELETE

Three pieces of HANA vocabulary worth having ready.Column store and row store. Column store is the default and is what makes analytical queries fast — compression and aggregation work down a column. Row store holds a small set of system and metadata tables.

Memory. HANA is in-memory, so used against allocated memory is the number to watch. Compression means the data in memory is much smaller than its uncompressed size, which is why sizing is done from measured compression rather than raw volume.

Delta merge. Writes go to a small, uncompressed delta store so they are fast. Periodically the delta is merged into the compressed main store.

The trade is visible in both directions: a table with a large unmerged delta reads more slowly, because queries must check both stores; and a merge is expensive, so merging too often costs write throughput. Merges are scheduled with that balance in mind, which is why delta merge appears in performance discussions about heavily written tables.

What the interviewer is probing.1. "What is the difference between RPO and RTO here?" Probing: whether you can define the target. Stalls: "Backup frequency." Moves up: RPO is how much data you can lose, driven by log backup interval; RTO is how long recovery may take, driven by backup size and method.

2. "Why are log backups the critical piece?" Probing: the mechanism. Stalls: "They are small." Moves up: point-in-time recovery needs an unbroken log chain — a full backup alone only restores to that instant.

3. "What must be monitored on HANA specifically?" Probing: the platform detail. Stalls: "Disk space." Moves up: memory consumption against the licence and physical limit, delta merge activity, and the log volume filling, which halts the database.

4. "How do you know a backup is good?" Probing: the discipline. Stalls: "It completed." Moves up: a test restore — an untested backup is a hypothesis, and backup logs report success for files that cannot be restored.