Infrastructure estimates
Estimate storage for full and incremental backups
Tools to use
Source size multiplied by generations can omit incremental files; adding a full source size every day can overstate them. Define what a generation means, which full and incremental files remain together, and where in the cycle you measure storage.
Weekly fulls, daily increments, two full generations
source: 100 GB
full interval: 168 hours
increment interval: 24 hours
retained full generations: 2
change per increment: 10%
compressed size: 100%
copies: 1
phase since latest full: 0 hoursThe result is 260 GB: two fulls total 200 GB, and six increments in the older chain total 60 GB. Each increment is 10% of 100 GB, or 10 GB. The model does not create an increment at a full-backup timestamp, so a weekly cycle has one full and six increments, not seven increments.
Two generations here does not mean only two restore points. Two fulls plus six increments make eight modeled backup points. A product that uses 'generations' to mean total restore points cannot have that setting copied directly into the full-generation field. Check what is retained.
The same two generations reach 320 GB later in the cycle
Change the observation phase from zero to 144 hours after the latest full. Six new increments have accumulated: two fulls, twelve increments, 320 GB. Identical retention settings produce different usage at different phases. The value immediately after a full is not necessarily the cycle's maximum.
The phase must be an incremental-interval multiple before the next full: 0, 24, 48, 72, 96, 120, or 144 hours here. The next full starts another cycle. Temporary files and overlap before old-chain deletion are not simulated, so operational headroom remains a separate estimate.
An older full can be needed by an in-window increment
In period mode, retain 168 hours and observe at phase 144. With the latest full at time zero, the oldest desired point is -24 hours. Recovering that increment requires the full at -168 hours and its subsequent chain. The model retains those dependencies, yielding two fulls and twelve increments, 320 GB.
Deleting every file older than seven days can break recovery dependencies. Products may use consolidation or synthetic fulls with different retention rules; this tool models periodic fulls and increments, not every implementation. Do not use the estimate as instructions for manual deletion.
Ten percent change is assumed per increment
Each increment is source size multiplied by change rate: 10 GB every time for 100 GB at 10%. This is not compounded daily growth of the source. Repeated modifications to the same data mean change volume is not the same as net new data added over a week.
Changing the increment interval from 24 to 12 hours does not automatically halve 10% to 5%. The entered rate applies to each new interval. Measure or state the interval-specific change assumption; increased frequency neither guarantees unchanged total size nor universal proportional growth.
Apply compression and copies to the whole retained chain
For the 260 GB case, compressed size 50% gives 130 GB; two copies return it to 260 GB. This field uses a percentage, so enter 50 here, unlike the log tool's ratio 0.5. The model applies one ratio to fulls and increments and does not infer deduplication or shared-block savings.
Entering an already compressed source size and applying the same compression again underestimates storage. Align the stage represented by source size, change volume, and compressed-size percentage. Where a product distinguishes logical and physical size, identify which value you are using.
Enough capacity does not establish recoverability
The model assumes scheduled backups succeed and required chains remain available. It does not test missing or corrupted files, lost keys, failed runs, or required configuration. After estimating capacity, validate restoration and recovery duration in the actual backup system.
Keep full count, increment count, observation phase, and retention mode with the total. Expanding a vague 'two generations' into an explicit retained chain makes the estimate explainable.
Check dependencies before deleting an old full backup
Deleting a full backup merely because it predates the retention window can make retained incrementals unusable. A delta chain needs its base. This model includes the full backup needed by retained increments, so a larger result than 'daily amount times days' may be necessary rather than wasteful. Distinguish retained restore points from all files needed to reconstruct them.
The same retention settings hold different numbers of increments just after a full backup and just before the next one. The 260GB and 320GB examples show why one snapshot can understate peak storage. Synthetic fulls, deduplication and shared compressed blocks may follow different product-specific storage models. Use measurements to refine assumptions rather than claiming this chain model reproduces every product.
More replicas require more space, but copies exposed to the same failure may not provide the intended protection. This calculation does not test placement, permission separation or restore procedures. Capacity, recoverability, recovery time and retained points need separate verification. A storage estimate alone is not a completed backup design.