Example data table
| Scenario | Dataset (GiB) | Type | Change (%) | Bandwidth (Mbps) | Window (h) | Result |
|---|---|---|---|---|---|---|
| VM fleet, nightly | 2048 | Incremental | 8 | 500 | 6 | Fits with buffer |
| File shares, weekly | 8192 | Full | — | 1000 | 10 | May exceed window |
| Database, midweek | 1024 | Differential | 12 | 300 | 5 | Tune bandwidth |
Formula used
- Logical protected data (GiB) depends on backup type:
- Full: L = Dataset
- Incremental: L = Dataset × (DailyChange% / 100)
- Differential: L = min(Dataset, Dataset × (DailyChange% / 100) × DaysSinceFull)
- Transfer size (GiB) after reductions:
T = (L × (1 − Exclude%)) × (1 − Dedupe%) ÷ CompressionRatio
- Network throughput (MiB/s) from Mbps:
NetMiB/s ≈ (Mbps ÷ 8) × (1000 ÷ 1024)
- Parallel streams scaling with efficiency:
Scale = 1 + (Streams − 1) × StreamEfficiency%
- Bottleneck throughput before overhead:
Raw = min(NetMiB/s × Scale, StorageLimitMiB/s)
- Effective throughput with overhead penalties:
Effective = Raw × (1 − ProtocolOverhead%) × (1 − CPUOverhead%)
- Total duration with verification and post-processing:
Duration = (TransferMiB ÷ Effective) × (1 + Verify% + PostProcess%)
How to use this calculator
- Enter your dataset size and choose the backup type you run.
- For incremental or differential, set a realistic daily change rate.
- Add compression and dedupe estimates from recent job logs.
- Set sustained bandwidth and a storage write limit for your repository.
- Adjust overhead and verification to match your tooling and security needs.
- Click Calculate backup window to see duration, finish time, and buffer.
- If the plan overruns, use the required bandwidth and storage targets as a sizing guide.
Operational context for backup windows
Backup windows are constrained by three numbers: protected data, end‑to‑end throughput, and allowable time. In mid‑size cloud estates, datasets commonly range from 500 to 10,000 GiB per policy domain. A 2,048 GiB workload with an 8% daily change produces about 163.8 GiB of logical incremental data before reductions.
Transfer size drivers and reduction levers
Transfer size shrinks when exclusions, deduplication, and compression are tuned. Excluding 5% of non‑critical paths removes 102.4 GiB from a 2,048 GiB full run. A 15% dedupe benefit on the remaining set lowers bytes by another 15%. With a 1.8 compression ratio, the transfer payload is divided by 1.8, often cutting nightly traffic by 40–55%.
Throughput modeling and bottleneck detection
Throughput is usually limited by the slowest link: network or repository writes. 500 Mbps sustained bandwidth converts to roughly 61.0 MiB/s. With four streams at 55% efficiency, modeled scaling reaches about 162.7 MiB/s, but a 450 MiB/s repository ceiling will not constrain this case. Add 12% protocol and 10% CPU overhead, and effective throughput becomes about 128.7 MiB/s.
Verification, post-processing, and safety buffers
Verification and post‑processing must be reserved explicitly. Integrity scans, catalog updates, and replication can add 5–20% depending on tooling. In the default profile, 8% verification plus 4% post‑processing increases runtime by 12%. A 1.5 hour transfer can become 1.68 hours, which matters when change rates spike after patch cycles or large migrations.
Capacity planning actions from planner outputs
Use the planner to size capacity and set safer start times. If the plan overruns, the required bandwidth output gives a concrete target for network upgrades or throttling policy changes. When storage is flagged as the bottleneck, raising repository write throughput or adding cache tiers often yields faster wins than increasing streams alone. For differential jobs, remember that days since the last full backup multiplies the change rate. At 12% change and three days since full, the differential logical set is about 737.3 GiB before reductions, which can shift a job from “fits” to “overrun.” Track real job logs weekly, update overhead values after enabling encryption or immutability, and keep at least 20–30 minutes of buffer for retries. Document these assumptions in runbooks so teams can audit changes quickly later.
FAQs
1) What should I use for “daily change”?
Use measured change from recent backup reports or storage analytics. If unknown, start with 5–12% for mixed VM and file workloads, then refine weekly using job history.
2) Why does adding streams sometimes not help?
Parallelism helps only until another component saturates. If storage writes, CPU, or a gateway link is limiting, extra streams increase contention without raising effective throughput.
3) How do I estimate protocol and CPU overhead?
Compare observed throughput to raw link capacity and repository benchmarks. Encryption, WAN latency, and small files raise protocol overhead; compression, hashing, and indexing raise CPU overhead.
4) What does “required bandwidth to fit” mean?
It is the sustained bandwidth target needed to complete within the chosen window, assuming the same stream scaling and overhead. Treat it as a sizing goal, not a guaranteed outcome.
5) When should I prefer differential over incremental?
Differential can simplify restores because it needs the last full plus the latest differential. However, it grows each day since the last full, so ensure the window supports that growth.
6) Can this planner replace a real benchmark run?
No. Use it for first-pass sizing and change impact checks. Validate with pilot jobs, observe throttling and retries, and then update the inputs to match measured behavior.