Backup Rotation Planner
Plan backup rotation capacity across daily through yearly retention tiers with binary units plus compression, growth and dedupe assumptions.{{ summaryTitle }}
{{ summaryLine }}
{{ primaryCopyAnnouncement }}
| Tier | Copies | Per copy | Net storage | Reach | Copy |
|---|---|---|---|---|---|
| {{ row.label }} | {{ row.copies }} | {{ row.perCopy }} | {{ row.net }} | {{ row.reach }} |
The chart renderer is unavailable. Exact tier values remain in the rotation plan.
Recovery review
Use these checks before turning the estimate into repository capacity.
{{ formatDuration(computation.values.coverage_horizon_days) }} reach- {{ step.status }}{{ step.label }}{{ step.note }}
Introduction:
A backup rotation policy decides which recovery points survive as copies age. Recent points are usually kept close together because accidental deletion, a bad deployment, or data corruption may be discovered quickly. Older points can be spaced farther apart when the purpose shifts toward long-running incident recovery, audit evidence, or archive retention.
Grandfather-father-son (GFS) is a common way to describe that tiered shape. Daily points form the short, dense recovery window. Weekly and monthly full backups extend the range with fewer copies, while yearly archives preserve selected long-term states. The labels describe retention cadence, not a universal backup format or a guarantee that every product builds its chains the same way.
- Recovery point
- A retained state that can be selected for restore.
- Full backup
- A whole-dataset copy used here for weekly, monthly, and yearly tiers.
- Incremental backup
- A change-focused copy used here for the daily tier.
- Coverage horizon
- The modeled age of the oldest retained point, not the frequency of recent recovery options.
Capacity depends on more than the copy count. Full and incremental data may compress differently. Deduplication may reduce stored blocks across many points. Protected data can grow during a long retention period, so older copies may be larger than today's baseline. These effects must be measured separately because a strong compression result does not automatically prove an equally strong deduplication result.
The largest planning mistake is treating estimated storage as recovery readiness. A compact repository can still fail if chains are broken, encryption keys are unavailable, immutable copies are unreachable, or restores take longer than the business can tolerate. Rotation design needs restore tests, ownership, monitoring, and a documented reason for every long-term tier.
A useful estimate therefore answers two questions at once: how much modeled capacity the retained points consume, and what recovery window those points actually provide. Vendor overhead, replication, delayed deletion, metadata, and safety reserve remain separate capacity decisions.
How to Use This Tool:
Begin with measured stored sizes when possible, then build the retention shape before adding reduction assumptions.
- Choose a Retention profile as a starting point or select Custom. Changing any tier after choosing a profile keeps the new values as a custom policy.
- Enter the typical Daily incremental size and Full backup size. Units are binary, so GB and TB inputs are interpreted as GiB- and TiB-sized quantities.
- Set the daily, weekly, monthly, and yearly retained counts. At least one tier must contain a recovery point; use zero for tiers the policy does not keep.
- Open Advanced and add monthly growth, separate compression ratios, and global dedupe savings only when measurements support them. Compare the estimate with neutral 1:1 compression and 0% dedupe before reserving capacity.
- Check Rotation plan for tier reach and per-copy size, then use Recovery review to identify sparse recent coverage, missing weekly bridges, or assumptions that need restore testing.
Interpreting Results:
Estimated repository footprint is the modeled total after compression, average-age growth, and global deduplication. It is not a storage quota recommendation. Add repository metadata, indexes, replicas, immutability holds, pruning delays, snapshots, and operational reserve outside the result.
- Coverage horizon reports the farthest tier reach. It does not mean every day inside that span has a restore point.
- Largest tier share shows where the capacity estimate is concentrated. Confirm that tier has a clear recovery or retention purpose.
- A short daily window beside long monthly or yearly retention can leave a gap for recently discovered mistakes. Validate both the dense rollback period and the handoff into older full backups.
- High dedupe savings deserve a second run at 0%. The difference is the capacity at risk if the repository does not achieve the assumed reduction.
Technical Details:
The capacity model treats daily points as compressed incrementals and the weekly, monthly, and yearly tiers as compressed full copies. Retention reach is approximated with one-day, seven-day, 30-day, and 365-day cadences. Growth is applied from the midpoint age of each tier so a tier with a longer reach receives a larger average-size adjustment.
Formula Core
Input sizes are converted to bytes with binary factors: MiB uses 10242, GiB uses 10243, and TiB uses 10244. Compression divides the entered size by its ratio.
For each tier, the effective base size is adjusted by the modeled growth at half of that tier's coverage age, multiplied by the retained copy count, then reduced by the global dedupe percentage.
| Symbol | Meaning | Unit or range |
|---|---|---|
| Bi | Entered full or incremental size after binary unit conversion. | Bytes |
| C | Applicable compression ratio. | Full 1 to 4; incremental 1 to 5 |
| Nt | Retained copies in tier t. | Count |
| dt | Tier coverage: count multiplied by 1, 7, 30, or 365 days. | Days |
| g | Monthly growth assumption. | 0% to 50% |
| D | Global dedupe savings applied after tier totals. | 0% to 80% |
Default GFS substitution
The 7-4-12-2 profile with 60 GiB incrementals, 500 GiB fulls, 1:1 compression, 0% growth, and 0% dedupe retains 25 points. The arithmetic totals about 9.2 TiB, reaches 730 days through the two yearly copies, and places about 63.7% of modeled storage in the monthly tier. Values retain full precision internally and are rounded only for display.
Limitations and Privacy Notes:
This is a deterministic capacity estimate, not a simulation of a specific backup product. It does not model chain dependencies, synthetic full behavior, changed-block tracking, metadata, replication, object-lock retention, legal holds, failed jobs, delayed pruning, or storage-tier pricing.
- The growth adjustment is a simple average-age planning heuristic, not a forecast.
- Compression and dedupe are independent assumptions and should come from repository measurements.
- Restore success and recovery time must be tested separately from capacity.
- Inputs and results stay in the browser; no backup data or files are uploaded.
References:
- Security Guidelines for Storage Infrastructure, National Institute of Standards and Technology, October 2020.
- Long-Term Retention Policy (GFS), Veeam Backup & Replication User Guide.