SAPFree calculatorPDF, Excel, Word exportSAP HANAAll SAP HANA and Basis tools

SAP HANA Backup Storage and Retention Calculator

This calculator estimates the storage SAP HANA backups consume on the target for a chosen retention window: complete data backups, differential or incremental backups and log backups. Feed it real sizes from M_BACKUP_CATALOG_FILES and it shows how storage grows as retention is extended.

Your numbers

Size of one full data backup

Sum of BACKUP_SIZE in M_BACKUP_CATALOG_FILES for your latest complete data backup.

Full data backups per week

Differential or incremental backups per week

Average delta size

% of full

Incremental backups are usually smaller than differentials, which grow until the next full.

Log backup volume per day

Sum of BACKUP_SIZE for log backups per day from M_BACKUP_CATALOG_FILES.

Retention

30 days

Compression ratio

1.0 = uncompressed. Enter the ratio your backint tool or storage achieves, measured, not promised.

Copies kept

2 if every backup is replicated to a second site.

Your results

Total backup storage

5,228.57

GB needed on the backup target.

Full backups retained

One extra full is kept so the oldest retained point stays recoverable.

Full backup storage

3,000

GB.

Delta backup storage

1,028.57

GB.

Log backup storage

1,200

GB.

Total backup storage (TB)

5.106

Added per extra retention day

145.71

GB per day of extra retention; multiply by 30 for a monthly growth hint.

Estimate only. Actual backup sizes depend on used pages, change rate and the backup tool. Measure from M_BACKUP_CATALOG_FILES over at least two weeks.

Save results:

Total backup storage vs retention days

Sweeps Retention from 7 to 90, holding your other inputs fixed.

Get your HANA backup plan reviewed

Send your backup schedule and a week of catalog totals and we will check retention, recovery chain and target sizing.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Take the size of your last complete data backup and your average daily log backup volume from the backup catalog. A query such as SELECT C.ENTRY_TYPE_NAME, SUM(F.BACKUP_SIZE)/1024/1024/1024 AS GB FROM M_BACKUP_CATALOG C JOIN M_BACKUP_CATALOG_FILES F ON C.BACKUP_ID = F.BACKUP_ID WHERE C.SYS_START_TIME > ADD_DAYS(CURRENT_TIMESTAMP, -7) GROUP BY C.ENTRY_TYPE_NAME gives a week of totals by type. Enter your schedule, the retention your recovery policy requires and the compression ratio you have actually measured. Set copies to 2 if backups are replicated to a second site. The chart sweeps retention from 7 to 90 days.

ENTRY_TYPE_NAME separates complete, differential, incremental and log backups
Use a full week of log backups: weekday and month-end volumes differ
Run the query in each tenant and in SYSTEMDB if they are backed up separately

What a recovery actually needs

The SAP HANA Administration Guide defines a differential backup as the data changed since the last complete data backup, and an incremental backup as the data changed since the last data backup of any type. A point-in-time recovery needs one complete data backup, then either the latest differential since it or every incremental since it, then all log backups up to the target time. Losing a single log backup in the chain stops the recovery at that point. That is why the calculator keeps one extra full: the oldest point inside your window must still have its full and its log chain. Log backups only run when log_mode is normal and automatic log backup is enabled; with log_mode overwrite there is no point-in-time recovery at all.

Worked example

A 500 GB full runs weekly with 6 incrementals averaging 8 percent and 40 GB of log backups a day, kept for 30 days, uncompressed, one copy. Fulls retained: ceil(30/7 x 1) + 1 = 6, so 3,000 GB. Deltas: 6 x 30/7 x 500 x 0.08 = about 1,029 GB. Logs: 40 x 30 = 1,200 GB. Total about 5,229 GB, or 5.1 TB. Each extra day of retention adds roughly 146 GB. Doubling log volume during month-end close moves the total far more than changing the delta percentage, which is why the log input deserves the most care.

Keep the backup catalog clean

The backup catalog itself is backed up with every log backup, so a catalog that holds years of entries grows and slows backups. Remove old entries with BACKUP CATALOG DELETE ALL BEFORE BACKUP_ID <id>; adding COMPLETE also deletes the physical backup files at file and backint destinations, so use it only when your retention tool does not do that already. Check the catalog size in M_BACKUP_CATALOG_FILES on the rows where SOURCE_TYPE_NAME = 'catalog'. Backup encryption and compression options depend on the HANA revision and the backint tool; confirm what your revision supports in its administration guide before relying on a compression ratio.

Housekeep the catalog on the same schedule as the backup files
Never delete log backups that a retained full still depends on
Test a restore to a sandbox tenant at least quarterly

Frequently Asked Questions

How do I check the size of the SAP HANA backup catalog?

Query M_BACKUP_CATALOG_FILES where SOURCE_TYPE_NAME = 'catalog' and look at BACKUP_SIZE (bytes) of the most recent rows. A catalog backup that keeps growing month after month usually means old entries were never removed with BACKUP CATALOG DELETE.

Is a differential or incremental backup smaller?

An incremental contains changes since the last data backup of any type, so each one is small. A differential contains everything changed since the last full, so it grows through the week. Differentials make recovery simpler (full plus one differential), incrementals save space but need the whole chain.

Does SAP HANA compress backups?

Many backint tools and dedupe storage compress backups, and newer HANA 2.0 revisions offer native backup compression options. The availability and parameters depend on your revision, so check the administration guide for your SPS. Enter only a ratio you have measured on your own backups.

Why is my log backup volume so high?

Log backup volume equals redo generated: mass updates, data loads, archiving runs, table redistributions and month-end jobs all add redo. Long-running batch jobs and reorganisations show up as spikes. Compare daily sums of log backup BACKUP_SIZE with your job schedule to find the cause.

If you want backup sizes, failures and catalog growth answered in plain English from your HANA monitoring views on your own servers, we can build that.

Talk to an Expert Explore More Free Tools