Size each backup destination from measured retained bytes and net growth, including versions and incomplete uploads, then reserve recovery space and provisioning lead time. Keep provider-run repository capacity separate from customer-controlled delivery storage. A retention count or protected-server size alone is insufficient.
This article is a source-researched, untested planning method, not a validated sizing calculator. No customer storage was inspected and no retention policy was changed. Amazon S3 provides the concrete versioning and lifecycle examples; other services and backup products require their own documented accounting.
Define what retention must preserve
Start with the recovery requirement: which workloads, which historical points, what granularity and which failures the copies must survive. Keeping recent points for operational recovery and older points for delayed discovery can create different storage patterns.
Identify complete recovery dependencies. A retained point may require shared data, an earlier base, later log segments, catalogue metadata or encryption material. The backup product’s supported retention engine must preserve the required set. An operator cannot safely delete an old-looking file merely because its date is outside a desired window.
Distinguish required retention from convenience copies and temporary exports. Assign each class an owner and a documented expiry decision. An abandoned test export and a legally required recovery set must not be treated as interchangeable “old data”.
Record whether retention is expressed as a number of recovery points, an age, calendar selections or a combination. A count-based policy and an age-based policy can consume different space when schedules fail, run more often or create additional manual points.
Separate logical protection from physical storage
Logical protected size describes the data or provisioned objects covered by the backup. Physical stored size describes what the repository actually consumes after the product’s representation, compression and deduplication. Those values are related but are not interchangeable.
NetLeverage’s current Backup & Recovery page describes compressed, deduplicated blocks and delivery to S3 or SFTP in zipped form. That is published product context, not a measured compression ratio or a guarantee that the delivered destination preserves the repository’s deduplication behaviour.
A delivered archive must be budgeted from its actual resulting size and destination behaviour. Do not apply the primary repository’s observed saving ratio automatically to exported zip files. The transformation and copy boundary can change what is stored.
Use supported repository reports for logical size, unique stored data, metadata and reclaimable space; record unavailable fields.
Collect a representative measurement series
Use existing repository reports or an approved scheduled collector with an owner and bounded retention. Record observations at consistent lifecycle points, such as after normal backup and supported retention processing. Comparing one measurement before cleanup with another after cleanup can misrepresent growth.
Capture total used capacity, available capacity, newly stored bytes where reported, deleted or reclaimed bytes, recovery-point count and workload changes. Also note delivery runs, maintenance, failed jobs and temporary staging demand.
Include representative workload cycles and exceptional periods, such as month-end imports, reseeds and missed cleanup, when setting reserve.
Record timestamps and units. Where the product reports cumulative counters, compare valid intervals and account for resets. Do not confuse a lifetime total of bytes processed with the space still retained.
Measure an S3 destination and work the decision
For a provider-run primary repository, request measured stored bytes, dependency accounting and capacity ownership from the provider. The customer can measure its delivered destination and recovery workstation; it cannot infer the provider's physical repository from ZIP sizes S3. Assign an owner to each worksheet.
For Amazon S3, inspect existing CloudWatch AWS/S3 daily BucketSizeBytes by bucket and StorageType. AWS includes current/noncurrent objects and incomplete multipart parts; use the documented storage-type breakdown without double-counting totals R1. These daily metrics are not an instantaneous filesystem reading.
Untested AWS CLI v2 read queries for an approved general-purpose bucket R2, R3, R4:
aws s3api list-object-versions --bucket example-recovery --prefix exports/ --output json
aws s3api list-multipart-uploads --bucket example-recovery --prefix exports/ --output json
aws s3api list-parts --bucket example-recovery --key exports/Example.zip --upload-id UPLOAD_ID --output json
Use existing permissions for the specific listing operations and account for request charges. Complete every page: sum Versions[].Size separately by IsLatest for current/noncurrent object payload; count delete markers separately. For each returned upload, sum Parts[].Size across all its pages. The upload listing alone provides no part-byte total. Record collection time and ongoing changes; a changing bucket is not an atomic snapshot. Payload sums need not equal billed storage, which can include class-specific overhead/minimums. Automate recurring collection with an owned report, runtime limit and failure status.
Synthetic worksheet, not a measured customer result. Assume a destination has a 10,000 GiB operational capacity/budget envelope: 6,000 retained payload + 800 noncurrent versions + 200 incomplete parts = 7,000 GiB used. Keep 1,000 GiB reserved for recovery; allocatable free space is 2,000 GiB. The separately measured net growth is 100 GiB/day, already including arrivals and removals.
| Decision | Calculation | Illustrative result |
|---|---|---|
| Time until reserve is reached | (10,000 − 7,000 − 1,000) / 100 | 20 days |
| Time until envelope is exhausted | (10,000 − 7,000) / 100 | 30 days |
| Start provisioning, with 7-day lead and 3-day margin | 20 − 7 − 3 | By day 10 |
| Extra 500 GiB arrival | (2,000 − 500) / 100 | Reserve in 15 days; act by day 5 |
Amazon S3 has no fixed bucket disk capacity: this example's envelope is an agreed cost/capacity threshold. From a 1 November 2026 baseline, day 10 is 11 November; the exceptional case moves action to 6 November. Zero/negative net growth cannot support this division-based forecast; use scenarios and remeasure after workload changes.
Build a model for each storage boundary
For independently stored archives, the simplest accounting is the sum of the retained archive sizes plus metadata and working requirements. Use actual observations for the archive sizes and the schedule’s retained set.
For a repository that shares blocks, model measured physical growth and supported reclamation behaviour. The net effect of removing a recovery point depends on whether other retained points still reference its data. Deleting a point does not necessarily release its displayed logical size.
An editorial accounting structure is:
required capacity = retained stored data
+ metadata and catalogue allowance
+ peak temporary working space
+ maintenance/recovery reserve
+ explicitly chosen growth uncertainty
Each term needs a source: measured values, product documentation or a clearly labelled assumption approved by the operator. This is a worksheet, not a vendor formula. Avoid counting temporary space twice when it is already included in a reported peak.
Make a separate worksheet for the delivered destination. Include archive count, measured sizes, object versions, incomplete transfers where relevant and the storage required to retrieve or extract a recovery set. A destination can hold the backup while the recovery workstation lacks room to use it.
Account for S3 versions explicitly
Amazon states that each stored object version is the entire object, not only the difference from the previous version S1. Replacing an archive under the same key in a versioned bucket can therefore retain more data than the current-object listing suggests.
Inspect versioning state and the intended key-naming strategy. A new key for every backup and repeated overwrites of one key have different listing and lifecycle consequences. Neither should be assumed from the delivery job’s friendly name.
A normal delete in a versioning-enabled bucket can create a delete marker while older versions remain. Amazon’s versioning documentation explains this behaviour. A key disappearing from a default listing is not evidence that all its stored versions were removed or that their capacity was reclaimed.
Do not infer that versioning establishes immutable backup protection. This article makes no claim about deletion resistance, administrative separation or retention-lock configuration. Those require their own evidenced controls and recovery assessment.
For an S3-compatible destination, confirm the provider’s semantics before applying Amazon’s rules. A compatible API surface does not itself establish identical lifecycle, billing or retention behaviour.
Where NewerNoncurrentVersions and NoncurrentDays are both configured, AWS requires both thresholds to be exceeded before the relevant noncurrent transition or expiration S2. Count and age are not interchangeable alternatives in that rule.
Review lifecycle and incomplete uploads
Enabling versioning on a bucket that previously relied on expiration changes permanent deletion behaviour: AWS says to add an appropriate noncurrent-expiration configuration to retain that behaviour S1. This requires a separately approved retention review, not automatic deletion.
Amazon’s lifecycle reference distinguishes current-object actions from noncurrent-version expiration. Noncurrent-version expiration permanently removes those versions, so it must agree with the required recovery history.
Review the rule’s scope, filters, age conditions and version conditions before proposing any change. A rule written for a broad prefix can affect more backups than the operator intended. The storage owner and recovery owner must review the same selected object population.
The source also states that ordinary object-expiration rules do not remove incomplete multipart uploads; a separate abort-incomplete-upload action addresses them S2. Include such uploads in the investigation when storage accounting does not match completed objects.
Do not activate a cleanup rule simply to meet the forecast. First identify whether the objects are complete recovery sets, shared dependencies or incomplete transfer state. This guide supplies no lifecycle JSON or deletion command because the correct scope depends on the actual retention contract.
After an approved lifecycle change, verify its observed effects and recovery consequences. A saved rule is desired configuration, not proof that the expected bytes have already been removed.
Forecast with visible uncertainty
Produce a normal-growth case and a documented exceptional case. The exceptional case might include a new full seed, a prolonged missed cleanup, a workload import or an additional delivered copy, but only include events applicable to the actual design.
Revisit growth assumptions after workload, encryption or compression changes.
Use the measured variation to decide when a capacity action must begin, taking account of provisioning lead time and the reserve required for safe operations. A forecast that alerts only when the repository is already full provides little operational value.
If observations are insufficient, present a range or identify the missing measurement. Precision in a spreadsheet is not evidence that the input is reliable. Keep any estimate clearly distinguished from observed bytes.
Validate retention through recovery
Select representative retained points across the intended policy, including a point that depends on older data. Retrieve and restore them through the supported process in an isolated environment. Verify the required application result and key access.
This does not prove every point, but it can expose a mismatch between the retention model and the actual recovery dependencies. A capacity reduction that breaks an intended recovery point fails acceptance even if the repository now has more free space.
Retain the model, measurement series, assumption owners and next review trigger. Update it after material workload, protection or destination changes. Ongoing collection belongs in ordinary automation with owned reports and failure alerts.
Limitations
This is an unvalidated planning worksheet, scoped to Amazon S3 accounting examples. Customer-visible delivery size cannot reveal provider deduplication or retention dependencies. Synthetic dates and growth rates are not a sizing promise or authority to delete data.
Acceptance checklist
- Storage boundaries, owners and measurement units explicit.
- Versions, incomplete uploads and recovery workspace included without double-counting.
- Representative net growth, exceptional arrivals and provisioning lead time recorded.
- Retention dependencies and a real recovery rehearsal checked before policy change.
Learning notes
- Logical protected size and physical retained size are different inputs.
- Delivered archives and destination versions need their own capacity budget.
- A retention policy is successful only when its intended recovery points remain usable.
Related reading: Verify a Backup Delivered to S3 or SFTP Before Recovery; SQL Point-in-Time Restore: Plan and Verify the Backup Chain; Windows Disk Full, VMware Space Free: Map the Layers.
Sources and review status
Sources accessed 30 October 2026. Exact displayed dates, scope and claim mapping are in the accompanying evidence file. Revised after independent review; independent recheck pending. All examples remain untested and no lab validation is claimed.
- Retaining multiple versions of objects with S3 Versioning - Amazon Simple Storage Service
- Lifecycle configuration elements - Amazon Simple Storage Service
- Cloud Backup & Recovery for Business Data | NetLeverage
Additional revision sources: