How Much Cloud Backup Storage Does Your Business Need?

Backup storage is rarely equal to the size of your data. Retention multiplies it, compression and deduplication shrink it, and growth changes it every month. This guide gives you a practical method to estimate how much cloud backup storage you need, with a worked example you can adapt.

The five variables

1. Source size (S): how much data you protect today, after exclusions such as caches and temporary files.
2. Daily change rate (c): the share of data that is new or modified each day.
3. Retention: how many restore points you keep and for how long.
4. Reduction ratio (r): how much compression and deduplication reduce stored size (stored = original × r).
5. Growth (g): how fast the source grows per year.

Step 1: measure the source

Measure, do not guess. On Linux:

# File data, excluding virtual file systems
du -sh --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run /

# Size of each MySQL/MariaDB schema in GB
mysql -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1e9,1) AS gb
          FROM information_schema.tables GROUP BY table_schema;"

# PostgreSQL database sizes
psql -c "SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database;"

# Docker volumes
docker system df -v

Note that a logical database dump is usually smaller than the on-disk size, because indexes are rebuilt during restore rather than stored.

Step 2: estimate the daily change rate

Typical change rates range from under 1% per day for file servers with mostly static documents to 5% or more for busy databases and log-heavy systems. The best source is your own history: the size of incremental backups you already run, or the growth of binary logs and WAL over a day.

Step 3: understand reduction

• Compression: text, SQL dumps and logs often compress to 20–40% of their size. Images, videos, archives and encrypted files barely compress at all.
• Deduplication: systems such as Proxmox Backup Server store identical chunks once, across backups and across machines. Many VMs with the same operating system deduplicate well.
• Encryption: compression must happen before encryption; encrypted data does not compress.

Without measurements, a conservative assumption for mixed data is r = 0.6 (stored size is 60% of the original), and r = 0.3 for database dumps.

Step 4: model retention

Retention determines how many versions you store. Two common models give very different results:

• Periodic full + incrementals: each retained full backup stores the whole dataset again.
• Incremental forever with deduplication: you store one full baseline plus the unique changes of every retained restore point.

A practical formula for incremental-forever systems:

Storage ≈ S × r                          (baseline)
        + daily_points × S × c × r       (daily restore points)
        + monthly_points × S × m × r     (older monthly points)

where m is the unique change accumulated over a month. It is usually much lower
than 30 × c, because the same blocks change repeatedly. Measure it, or start
with about 10% of S.

Worked example

A company protects three Linux servers, one MySQL database and a Docker host. These numbers are illustrative assumptions, not measurements from a real customer.

Incremental forever with deduplication:

• Baseline: 400 × 0.6 = 240 GB
• Daily points: 30 × 12 × 0.6 = 216 GB
• Monthly points: 11 × 40 × 0.6 = 264 GB
• Total today: 240 + 216 + 264 = 720 GB
• With 20% growth after one year: 720 × 1.2 ≈ 864 GB
• With 20% headroom for spikes and restore tests: 864 × 1.2 ≈ 1.04 TB

Weekly full + daily incrementals, four weeks retention, no deduplication:

• Five full backups: 5 × 240 = 1,200 GB
• About 28 incrementals: 28 × 7.2 ≈ 202 GB
• Total: ≈ 1.4 TB for only one month of history

The comparison shows why the backup method matters as much as the data size: incremental-forever storage keeps a full year of history in less space than one month of weekly fulls.

Step 5: multiply by the number of copies

If you keep copies in two regions, each copy uses its own storage. In the example, a multi-region setup needs about 2 × 1.04 ≈ 2.1 TB. Local copies on your own hardware do not consume cloud capacity, but they need their own disks.

Step 6: review regularly

Estimates drift. Review actual usage monthly during the first quarter, then quarterly. Watch for:

• new servers or databases added without updating the plan;
• retention changes requested by compliance;
• log directories or caches accidentally included;
• applications that rewrite large files daily (for example, some VM images or archives), which defeat incremental backups.

Reducing storage without reducing safety

• Exclude caches, temporary files, package caches and rebuildable artifacts.
• Back up databases with dumps or physical backups instead of copying data files plus dumps.
• Use tiered retention: many recent points, fewer old ones.
• Do not back up Docker images you can pull again; see Docker backup best practices.
• Prefer deduplicating backup systems for virtual machines, such as Proxmox Backup Server.

Next steps

1. Measure S with the commands above.
2. Measure c from one week of incremental backups or log growth.
3. Choose a retention policy that matches your recovery objectives and compliance requirements.
4. Apply the formula, add growth and headroom, then multiply by the number of copies.

Compare the result with the Backnix storage plans, which range from 100 GB to 10 TB, and read about multi-region storage if you need copies in more than one region.

References

• Proxmox Backup Server: technical overview (chunks and deduplication)
• PostgreSQL documentation: database object size functions
• Docker documentation: docker system df

Topics: Capacity planningCloud storageRetention