This example estimates stored backup data for a simple retained set. A retention policy describes recoverable points over time; it is not automatically a count of full backup files. Confirm the actual backup product's chain and deletion behaviour before buying storage.
1. Count the retained backups
Assume a stable 1,000 GB full backup, four independent retained fulls and 24 retained incrementals. Each incremental is assumed to contain 5% of the full size, or 50 GB. One illustrative schedule is four seven-point sets, each containing a full followed by six incrementals. That gives 28 recovery points. It does not prove that every rolling 28-day retention requirement fits exactly those files.
2. Calculate the stored-data estimate
Scroll the table sideways if any columns are hidden.
| Component | Calculation | Size |
|---|---|---|
| Full backups | 4 × 1,000 GB | 4,000 GB |
| Incrementals | 24 × 50 GB | 1,200 GB |
| Before compression | 4,000 + 1,200 | 5,200 GB |
| Assumed 2:1 compression | 5,200 ÷ 2 | 2,600 GB |
Open the Backup Storage Calculator worked examples. Choose “Try this example” for four fulls and 24 incrementals, review the loaded values and select Calculate. Then try the 1:1 example: without compression savings, the answer becomes 5,200 GB. These are decimal GB; use the Storage Unit Converter when comparing a binary GiB/TiB display.
3. Keep the oldest point recoverable
A retained incremental may need an older full and intervening increments. Do not delete that full simply because its date falls outside the desired recovery window. Some products manage recovery points with block references, synthetic fulls or incremental-forever storage, so file-count arithmetic may not match their repository usage. Ask the product to show the dependencies for the oldest retained point.
This calculator excludes deduplication and synthetic-full savings, growth of full backups, replicas, metadata, immutability overlap and failed-job retries. Measure the real changed-data and compression ratios over representative busy periods rather than assuming the example's 5% and 2:1 values.
4. Add capacity headroom and test recovery
Adding 20% to the 2,600 GB estimate gives 3,120 GB. Keeping 20% of a volume unused is different: 2,600 ÷ 0.8 = 3,250 GB before other overheads. Choose a documented headroom policy and account for the exclusions above; neither figure is a vendor sizing guarantee.
Check transfer time separately. In the Backup Window Calculator, 1,000 GB at 100 MB/s and 80% utilisation takes 12,500 seconds, or 3 hours 28 minutes 20 seconds. Discovery, snapshots and verification can add time. A successful backup job does not establish the restore time.
Restore an old recovery point and a recent one into a test environment, verify application consistency and record elapsed recovery time. Compare that evidence with your RTO and RPO objectives. RAID availability does not provide an independent recoverable copy.
Reference
Microsoft's backup guidance illustrates how product-specific retention and recovery requirements affect backup policy. The arithmetic above is a generic retained-set model, not an Azure repository estimator.