# SAP HANA Backup Storage and Retention Calculator

> Source: https://netray.co/tools/sap-hana-backup-storage-retention-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate how much backup storage SAP HANA full, differential or incremental and log backups need for a given retention period, and how fast it grows.

## Category

sap

## Erp

SAP HANA

## Audience

- SAP Basis administrator
- HANA DBA
- Backup administrator

## Tool

**Kind:** calculator

**Inputs:**

#### Size of one full data backup

**Key:** full_size

**Type:** number

**Default:** 500

**Min:** 0

**Step:** 10

**Unit:** GB

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

#### Full data backups per week

**Key:** full_week

**Type:** select

**Default:** 1

**Options:**

##### 1 (weekly)

**Value:** 1

##### 2

**Value:** 2

##### 7 (daily)

**Value:** 7

#### Differential or incremental backups per week

**Key:** delta_week

**Type:** number

**Default:** 6

**Min:** 0

**Max:** 14

**Step:** 1

#### Average delta size

**Key:** delta_pct

**Type:** number

**Default:** 8

**Min:** 0

**Max:** 100

**Step:** 1

**Unit:** % of full

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

#### Log backup volume per day

**Key:** log_day

**Type:** number

**Default:** 40

**Min:** 0

**Step:** 1

**Unit:** GB

**Help:** Sum of BACKUP_SIZE for log backups per day from M_BACKUP_CATALOG_FILES.

#### Retention

**Key:** retention

**Type:** slider

**Default:** 30

**Min:** 7

**Max:** 90

**Step:** 1

**Unit:** days

#### Compression ratio

**Key:** ratio

**Type:** number

**Default:** 1

**Min:** 1

**Max:** 10

**Step:** 0.1

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

#### Copies kept

**Key:** copies

**Type:** number

**Default:** 1

**Min:** 1

**Max:** 4

**Step:** 1

**Help:** 2 if every backup is replicated to a second site.

**Outputs:**

#### Full backups retained

**Key:** fulls

**Expr:** ceil(retention / 7 * full_week) + 1

**Format:** integer

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

#### Full backup storage

**Key:** full_gb

**Expr:** fulls * full_size / ratio * copies

**Format:** number

**Description:** GB.

#### Delta backup storage

**Key:** delta_gb

**Expr:** delta_week * retention / 7 * full_size * delta_pct / 100 / ratio * copies

**Format:** number

**Description:** GB.

#### Log backup storage

**Key:** log_gb

**Expr:** log_day * retention / ratio * copies

**Format:** number

**Description:** GB.

#### Total backup storage

**Key:** total_gb

**Expr:** full_gb + delta_gb + log_gb

**Format:** number

**Primary:** true

**Description:** GB needed on the backup target.

#### Total backup storage (TB)

**Key:** total_tb

**Expr:** total_gb / 1024

**Format:** decimal

#### Added per extra retention day

**Key:** per_day

**Expr:** (full_size * full_week / 7 + full_size * delta_pct / 100 * delta_week / 7 + log_day) / ratio * copies

**Format:** number

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

**Chart:**

#### Total backup storage vs retention days

**Type:** line

**X:** retention

**From:** 7

**To:** 90

**Steps:** 28

**Series:**

- total_gb

**Disclaimer:** 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.

## Content

**Intro:** 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.

**Sections:**

#### How to use it

**Body:** 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.

**Bullets:**

- 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

**Body:** 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

**Body:** 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

**Body:** 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.

**Bullets:**

- 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

**Cta:** 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.

**Faq:**

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

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

sap hana size of backup catalog, sap hana administration guide, sap hana database administration guide, sap hana disk sizing, sap hana backup size, hana backup retention, m_backup_catalog_files

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json