SAP Backup

• Data backups: full (and delta/incremental) snapshots of the in-memory data persisted to disk.
• Log backups: continuous backups of the redo log, essential for point-in-time recovery.
• Configuration: so the system can be reconstructed.

Worth adding: storage snapshots are a third mechanism alongside file and Backint backups. They are fast because the storage system does the work, and they need coordination with HANA so the snapshot is consistent. Where they are used, they usually complement rather than replace conventional backups, because a snapshot on the same storage array shares that array's failure modes.

Data backups capture a point in time; log backups capture every change since. Together they let you recover to any moment (point-in-time recovery), for example just before a corruption. Frequent log backups mean minimal data loss, aligning to your RPO.

Backups only matter in relation to what you are recovering from, and there are three distinct situations.

The system crashed. No backup is needed. HANA restarts from the last savepoint and replays the redo log from the log volume, and nothing committed is lost. People frequently expect to restore a backup here and should not.

A volume was lost or corrupted. Now you restore the most recent data backup and roll forward using log backups to the last committed transaction. The data backup gets you close; the log backups get you to the end. Without log backups you lose everything since the last data backup, which is the reason logs matter as much as they do.

Somebody made a mistake. A table dropped, a mass update run against the wrong selection. Here you want point in time recovery: restore and roll forward to a moment just before the error. That is only possible with a continuous chain of log backups, and it is the scenario replication does not help with, because a deletion replicates faithfully.

The third case is why replication and backup are not alternatives. Replication protects against a system failing. Backup protects against something being done wrong, and only backup can go backwards.

Backups are performed via the HANA cockpit, SQL, or (commonly) integrated with enterprise backup tools through Backint. They should be automated, monitored for success, stored securely/offsite, and their retention managed.

Two mechanics worth knowing. Log backup mode should be normal rather than overwrite: overwrite mode discards logs and makes point in time recovery impossible. And the log backup interval defines how much you can lose, because anything not yet backed up is only in the log volume. An interval of fifteen minutes means at most fifteen minutes of exposure.

Retention then decides how far back you can go, and it is a storage cost against a recovery window. Deleting old backups is a deliberate housekeeping job, and a catalog that grows forever eventually becomes its own problem.

Where a third-party backup tool is used, it connects through the Backint interface rather than writing files, so the tool manages retention and catalog entries on its own terms. Knowing which mechanism a system uses matters when a recovery is needed, because the restore is driven from a different place in each case.

Two hours on a non-production system, and it is the only way to know a backup works.

1. Take a full data backup and note the backup ID from the catalog.
2. Confirm log backups are running and check the interval.
3. Post something identifiable, and note the time.
4. Post something else you intend to lose, and note that time too.
5. Recover the system to a point in time between the two.
6. Verify: the first change is present, the second is not, and the system starts cleanly.

Step six is the whole exercise. A backup that has never been restored is an assumption, and the first time you find out is not the moment to discover that log backups were in the wrong mode. See the HANA architecture for how persistence works underneath.

As always, a backup is only proven by a successful restore. Regularly test HANA restores in a non-production environment to validate the backups and the recovery procedure.

A schedule for this is worth agreeing rather than intending. Quarterly for a full recovery rehearsal, and a restore into a sandbox whenever a refresh is needed anyway, which gives you the practice for free. Recording how long it took is as valuable as whether it worked, because the recovery time is what the business is actually promised.

Every backup design comes down to two numbers, agreed with the business rather than chosen technically.

Recovery point objective is how much data the business can afford to lose, measured in time. It sets the log backup interval directly: an interval of fifteen minutes means up to fifteen minutes of exposure.

Recovery time objective is how long the business can be down. It shapes everything else: whether replication is needed, whether the secondary preloads data, where backups are stored and how fast that storage reads.

The mistake is deciding these implicitly. A daily full backup and hourly logs is a common default and it is a promise of up to an hour lost and several hours to recover. If the business believes it is protected to the minute, somebody has agreed to something nobody designed for.

Write both numbers down, design to them, then rehearse and measure whether the design meets them. The measurement is the part that turns a strategy into a commitment.

A recoverable system is more than a recoverable database, and the rest is frequently forgotten until it is needed.

Configuration files for the instance and the database hold parameters, and a restored database on a wrongly configured instance does not come up as it was.

Encryption keys matter absolutely. Where data volume encryption is used, a backup without its keys is unrecoverable, and storing the keys with the backup defeats the encryption. Key management is part of the backup design rather than adjacent to it.

The file system. Interfaces write files, and jobs read them. A recovered database with an empty directory is a partially recovered system.

Certificates and connections. A restored system needs its trust relationships rebuilt, and a system copy in particular needs its interfaces repointed before it is started, or it will talk to production.

The check that catches all of this is rehearsing a recovery into a clean environment rather than restoring over an existing one, because restoring over the top quietly reuses everything you forgot to back up.

• The database (data and, crucially, logs), the authoritative state.
• The file system components (kernel, profiles, interfaces).
• Configuration and documentation needed to reconstruct the system.

• Backing up data but not logs, no point-in-time recovery.
• Never testing a restore.
• Unmonitored backups that silently fail.

• Log backup mode set to overwrite. Backups run, look healthy, and point in time recovery is impossible.
• Backups written to the same storage as the data. One failure takes both.
• No backup of the secondary in a replication setup. See HANA security and HANA performance, and the installation-time backup setup for where this is configured.

• Encryption keys stored with the backups. It defeats the encryption, and storing them nowhere makes the backup useless. Key management is part of the design.

Scheduling a backup is straightforward, and proving a recovery within the time the business was promised is the part you do in the course.

The two numbers to establish before any of this is designed are how much data the business can lose and how long it can be down. Everything else, the log interval, the replication mode, the storage, follows from those.