Backup Storage Calculator for Self-Hosted Data

Table of Contents

• How the estimate works
• Why full copies and retained change are separate
• How to measure the change rate
• Compression and deduplication caveats
• How 3-2-1 changes purchasing
• Worked default example
• Validation and restore testing
• When the estimate is unsafe
• Next steps
• Frequently asked questions

How the estimate works

The calculator estimates retained backup capacity, then adds room for growth and uncertainty. It separates source and changed data because a target must hold a full copy and history for earlier recovery points.

The basic model is:

Full-copy storage = protected data × full backup copies × stored-size factor

Retained changed data = protected data × daily changed data × incremental retention × stored-size factor

Backup storage before headroom = full-copy storage + retained changed data

Planning capacity = backup storage before headroom × (1 + headroom)

Protected data is the source footprint; full backup copies are complete sets on the target. Daily changed data and incremental retention describe history. The stored-size factor estimates compression and deduplication; headroom covers uncertainty.

This is a planning estimate, not a promise. It excludes the primary copy and assumes retained increments do not compound. Actual use varies with deduplication, churn, metadata, snapshots, immutability, filesystem overhead, and billing rules.

Why full copies and retained change are separate

Full copies answer how many complete sets remain available if damaged, deleted, or unavailable. Retained changed data answers how much information restores an earlier state during retention.

Combining them into one percentage can understate capacity. Applications may rewrite large files, databases may update frequently, and media workflows may create versions, while an archive may change slowly but still need more than one full copy. More full copies increase the baseline; longer retention or higher change rate increases history. The factor reduces both, although not always uniformly.

How to measure the change rate

Use a user-entered assumption based on the protected system, not a generic figure. Review backup-job reports, filesystem growth, version history, database logs, or object-storage activity. Separate new from rewritten data when possible; a small edit can create a large delta if an application rewrites the object.

Measure what the backup system would retain, not only net growth. Files can be created and deleted while churn remains high; exports, thumbnails, caches, logs, and transaction files may create traffic without lasting growth. For seasonal workloads, use a conservative busy-period assumption, then replace it with observed usage.

Compression and deduplication caveats

The stored-size factor is a user-entered assumption. In the default example, 70% means retained content is estimated at 0.70 of uncompressed size, applied to full-copy storage and retained changed data.

Do not treat this factor as universal. Photos, videos, encrypted archives, compressed database pages, and already-compressed backups may reduce little. Deduplication depends on block size, retention layout, encryption, file versions, and repeated-content recognition.

Snapshots need attention: they may share blocks at first, then use more space as blocks change. A system may count them in the same pool, reserve space, or bill them separately. Metadata, indexes, checksums, catalogs, and immutable retention can exceed the calculation. Use observed size when possible; otherwise enter a cautious factor and retain headroom.

How 3-2-1 changes purchasing

Capacity is one part of a backup design. CISA's 3-2-1 guidance calls for three copies total, two media types, and one offsite copy. The calculator's full backup copies describe one target, not proof the plan meets the guidance.

When purchasing, map every copy to a destination and failure boundary. A local target enables fast restores; an offsite target addresses site-wide incidents. Shared host, credentials, network, power, or administrator account can make both fail together.

The offsite copy may need its own capacity, retention, transfer, and billing review. Cloud storage can charge for stored data, requests, retrieval, egress, or retained versions. A local disk is not automatically a different medium or location.

Recovery objectives also affect design. NIST SP 800-34 Rev. 1 includes backups in recovery planning, including recovery time and recovery point considerations. Raw capacity is not enough if restoration takes too long or retained points miss the requirement.

Worked default example

The default inputs are 500 GB of protected data, 2 full backup copies, 2% daily changed data, 30 days of incremental retention, a 70% stored-size factor, and 20% headroom.

Calculation	Formula	Result
Full-copy storage	500 × 2 × 0.70	700 GB
Retained changed data	500 × 0.02 × 30 × 0.70	210 GB
Before headroom	700 + 210	910 GB
Planning capacity	910 × 1.20	1,092 GB

1.09 TB is the decimal result; plan around it under these inputs. Headroom absorbs uncertainty and growth; platforms may consume more or still fail to restore workloads.

The calculation excludes the primary copy and assumes retained increments do not compound: each retained day is the stated daily changed portion of the protected dataset after applying the stored-size factor. Additional fulls, synthetic fulls, snapshots, immutable versions, or application-specific logs must be evaluated separately and added to purchasing requirements.

Validation and restore testing

Validate against the backup system's storage report. Compare logical protected data with physical target usage after representative full and incremental jobs. Check for catalogs, snapshots, indexes, retention locks, deleted-but-retained versions, and decimal versus binary units.

Restore a representative file, a directory with permissions, and an application or database through the expected path. Confirm data opens, ownership and timestamps are appropriate, and keys, credentials, and configuration are available. Test item-level and complete service recovery when supported. Record recovery time, verify the retention window, and test the offsite copy separately; a local restore does not prove the remote path works.

When the estimate is unsafe

Treat the estimate as unsafe when a major input is unknown, optimistic, or detached from implementation. A 70% factor is unsafe for mostly encrypted or already-compressed content without measurement. A 2% daily change assumption is unsafe when databases, virtual-machine images, mail stores, or media libraries are rewritten in large blocks.

The model is unsafe when retention is more complex than its inputs: GFS-style schedules, periodic full backups, immutable retention, snapshots, transaction logs, replication journals, and provider-side versioning can add storage. Quotas, thin provisioning, filesystem reserve, and billing limits can constrain capacity before nominal size.

Do not rely on this result as the sole plan for regulated, high-impact, or rapidly changing systems. Separate critical datasets and identify recovery point and recovery time needs. If losing newest changes is unacceptable, make daily change and retention reflect that need rather than a convenient default.

Next steps

Use the result as a purchasing starting point, then connect it to the services you run. The Immich backup guide helps with photo and video workflows, where media and metadata may differ. For a file platform, review Nextcloud with Docker Compose and include files, database, configuration, and secrets that must travel together.

Browse the file storage category and self-hosted guides for related decisions and maintenance. Before buying, record each copy's location, medium, retention, access path, and restore test. Recalculate when the dataset, change assumption, retention period, or stored-size evidence changes.

Frequently asked questions

Does the primary copy count as a backup copy?

No. The calculator excludes the primary copy and sizes retained backup data. The working dataset is the source, not an independent backup. Count it in the full 3-2-1 arrangement, but do not subtract it from returned backup-target capacity.

Are snapshots backups?

Not automatically. A snapshot may recover an accidental edit or deletion, but can share storage, host, credentials, and failure boundary with primary data. Verify that it is copied to an independent, offsite destination with matching retention.

How much headroom should I use?

Tie headroom to expected growth and uncertainty. The default example uses 20%. Increase it when change rate or stored-size factor is poorly measured, retention may expand, or the target carries snapshots, metadata, or immutable versions. Replace it with observed usage as the system matures.

Does the calculator guarantee restore success?

No. It estimates capacity under stated assumptions. Restore success also depends on recovery points, integrity, application consistency, keys, permissions, network access, and a practiced procedure. Validate these with regular restore tests, including the offsite copy and complete service path when required.