HANA runs in-memory, but durability still depends entirely on backup discipline — the persistence layer and the log area need to be backed up on purpose, on a schedule, the same as any other database.
The two backups HANA always needs
A data backup is a full copy of the persistence layer at a point in time. Log backups run continuously in the background and are what makes point-in-time recovery possible between data backups. Skip log backups and you can only ever restore to the last data backup, losing everything after it.
File-based vs Backint
File-based backups write straight to a filesystem path — simplest to set up, fine for small or dev systems. Backint is the integration interface most production landscapes actually use, letting a third-party backup tool (Commvault, NetBackup, and similar) manage HANA backups the same way it manages everything else in the landscape, with retention and offsite copy handled centrally.
Triggering a manual data backup
Through HANA Cockpit's Backup tile, or directly in SQL:
BACKUP DATA USING FILE ('backup_name')Checking backup health
Don't assume backups succeeded just because nothing paged you. Query the catalog directly:
SELECT * FROM M_BACKUP_CATALOG ORDER BY SYS_START_TIME DESC;
SELECT * FROM M_BACKUP_CATALOG_FILES WHERE BACKUP_ID = '<id>';Look specifically for gaps in log backups, not just failed data backups — a silent gap there is what turns a routine restore into a bigger data-loss event than anyone expected.
Point-in-time recovery, at a glance
Recovery replays the most recent data backup and then every log backup up to the timestamp you choose. In practice: stop the system (or the affected tenant in a multi-tenant setup), open the recovery wizard in HANA Cockpit or Studio, choose "recover to point in time," and select the timestamp. HANA handles replaying the chain of backups itself — you don't manually restore files.
Common pitfalls
- Log area filling up. Usually caused by log backups being disabled or the backup destination becoming unreachable — this is a classic cause of a HANA system hanging with no obvious error.
- Stale backup catalog pointers. After a storage migration, the catalog can still point at the old backup destination path. Verify it explicitly rather than assuming the migration updated everything.
- Forgetting SYSTEMDB in multi-tenant (MDC) systems. SYSTEMDB holds the catalog and tenant metadata — back it up alongside the tenant databases, not instead of them.
FAQ
How often should SAP HANA log backups run?
Continuously, in the background, by default — they're what makes point-in-time recovery possible. The setting to check is the backup destination and retention, not a schedule, since HANA writes log backups as segments fill rather than on a fixed timer.
What happens if the HANA log area fills up?
The database can hang or stop accepting writes, because it can't log new transactions. This is most often caused by log backups failing silently — an unreachable backup destination or Backint agent issue — rather than by transaction volume alone.
Can I restore an SAP HANA database to a specific point in time?
Yes — HANA's recovery process replays the most recent data backup plus the chain of log backups up to the timestamp you choose, through HANA Cockpit, Studio, or the command-line recovery tools.
No comments:
Post a Comment