If you manage an SAP HANA database, the backup strategy you set up today determines how fast you recover from tomorrow’s crisis. I’ve seen too many teams discover their backup configuration is wrong — only when they actually need to restore. Don’t be that team.
This SAP HANA backup and recovery guide covers everything a Basis administrator needs: backup types, configuration, automation, monitoring, recovery procedures, and the essential SAP Notes that keep it all working.
Table of Contents
Understanding SAP HANA Backup Types
SAP HANA offers three fundamental backup types. Knowing when to use each is the foundation of a reliable backup strategy.
| Backup Type | What It Captures | Recovery Time | Frequency |
|---|---|---|---|
| Complete Data Backup | Full snapshot of all data and catalog | Slowest | Daily or weekly |
| Incremental Backup | Changes since last full or incremental | Medium | Every 4-24 hours |
| Delta Backup | Changes since the last backup (any type) | Fastest | Every 1-4 hours |
Configuration Best Practices
Backup Location
Configure the backup location via the HANA Studio or SQL:
ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('backup', 'basepath_backup') = '/hana/shared/backup'
WITH RECONFIGURE;
Backup Compression
Always enable compression — it reduces storage by 50-70% without significant performance impact. Configure via global.ini parameter backup_compression = true.
Backup Scheduling
Use SAP HANA Cockpit or the HANA Database Explorer to schedule automated backups. A typical schedule for production:
- Complete backup: Daily at 01:00
- Incremental backup: Every 4 hours
- Log backup: Every 5 minutes (critical for point-in-time recovery)
Monitoring Backup Health
Run these checks weekly:
- BACKUP CATALOG — Verify last successful backup timestamp
- BACKUP VALIDATE CHECK — Validate backup integrity without restoring
- M_BACKUP_PROGRESS — Monitor in-progress backups
- M_BACKUP_CATALOG — Review backup history and sizes
SAP Note 1642148 is the central reference for backup and recovery — bookmark it.
Recovery Procedures
Point-in-Time Recovery (PITR)
RECOVER DATA USING BACKUP ('/hana/shared/backup/DATA_BACKUP_001')
UNTIL TIMESTAMP '2026-06-15 14:30:00';
Recovery to a Different System
Useful for system refreshes: take a backup from production and recover into your QA or DEV system. Ensure the target system has equal or greater memory and CPU allocation.
Essential SAP Notes for HANA Backup
| SAP Note | Purpose |
|---|---|
| 1642148 | SAP HANA Backup & Recovery — central FAQ reference |
| 2039883 | Database and storage snapshots |
| 2165547 | Backup & recovery in system replication landscapes |
| 1999880 | System replication and backup interaction |
| 2057595 | High availability configuration |
Common Pitfalls
- Silent backup failures: The most dangerous scenario. Always configure backup notification to alert the Basis team on failure. A backup that fails silently might go unnoticed for days.
- Insufficient storage: HANA backups require 2-3x the database size in free space. Monitor disk usage on your backup volume.
- Old backups not purged: Configure retention policies in the backup tool. Without this, you’ll run out of space and backups will fail.
- Log backup not configured: Without log backups, point-in-time recovery is impossible. You can only recover to the last full backup.
Automation & Monitoring
For automated backup monitoring, use SAP Cloud ALM or SAP Solution Manager to monitor backup status. Set up alerts for:
- Backup failures (BACKUP_FAILURE alert)
- Backup duration exceeding thresholds
- Log area full (Alert 36)
- Backup storage space low
Conclusion
A reliable SAP HANA backup strategy is three things: configured correctly, monitored actively, and tested regularly. Schedule a restore test at least quarterly — ideally monthly. The 30 minutes it takes to validate a restore can save you days of downtime when a real incident happens. Bookmark SAP Note 1642148, set up your backup notifications, and never assume backups are working — verify them.
