Planning Backup Storage and Retention

Use an understandable capacity model and recovery goals to size a backup repository before rollout.

Start with recovery goals

Backup plans should begin with two operational requirements: recovery point objective (RPO) and recovery time objective (RTO). RPO describes how much data you can afford to lose, measured in time. RTO describes how long an outage can last before recovery must be completed. Those goals influence schedules, storage, offsite replication, and restore testing.

A simple full-plus-incremental model

For a starting estimate, assume one full backup plus one incremental backup for each following retained day. If the protected dataset is 800 GB, daily changed data is 20 GB, and 30 days are retained, one chain needs 800 + (29 × 20) = 1,380 GB before metadata or extra storage headroom. Add a margin for application-specific overhead and repository operations.

This model becomes inaccurate when backup software periodically creates additional full backups, uses synthetic fulls, deduplicates data, compresses certain file types, or retains long-term monthly and yearly points. Verify the actual retention policy and repository architecture.

Use the 3-2-1 rule as a starting point

The 3-2-1 approach is a useful mental model: keep three copies of important data, use at least two types of storage, and maintain at least one offsite copy. For ransomware resilience, many teams also employ immutable or offline backup copies that production credentials cannot easily modify.

How to avoid underestimating capacity

Measure daily changes using actual backup jobs instead of guessing. Account for growth, retention overlaps during full backup cycles, unexpected large changes, index and metadata overhead, and the fact that multiple restore points may remain locked or held beyond their normal expiry. If your backup provider bills for cloud egress or API activity, capacity alone is not the entire cost.

Verify recovery, not only backup completion

A green job status says a task completed; it does not prove a production service can be recovered on time. Schedule sample file restores, full VM recovery tests, and documented exercises with application owners. Ensure encryption keys, service credentials, and any recovery runbooks remain accessible during an outage.

The browser-based estimator below gives a quick capacity baseline, while the data-transfer calculator can help approximate offsite copy windows and restoration duration under stated throughput assumptions.