Immutable Backup Sizing: Plan Capacity Without Guesswork

A backup can fall outside its retention policy and still take up space because its lock has not expired. Veeam’s hardened repository immutability guidance explains how a longer lock can delay deletion beyond job retention. Immutable backup sizing forecasts how much backup data remains physically allocated as retention and immutability rules affect when files or object blocks can be deleted. A full-backup size multiplied by retention days misses that distinction.

For an IT director approving capacity, the useful number is the forecast physical peak under the proposed setup. For the backup administrator, that number must lead back to measured output, retained files or blocks, and deletion rules. Both need the same worksheet, with assumptions clear enough to challenge before a purchase.

Start with a list of retained files or blocks, apply the rules of the chosen repository, then convert the physical forecast into usable capacity with a stated reserve. The process below covers image-level Veeam backups on file and S3 repositories. The worked figures illustrate the math only; they are not workload benchmarks or a capacity recommendation for any one of our configurations. When the setup changes, revise the forecast and show which inputs changed.

Immutable backup sizing starts with measured inputs

Protected data: Measure backup outputs before applying ratios

Record protected used data, full-backup output, and incremental output separately. Source disk sizes help describe the environment, but should not replace measured backup bytes. Veeam’s repository sizing guidance includes change rate, reduction, chain type, growth, and forecast period among sizing inputs; reduction assumptions depend on the environment.

If measured full backups already reflect compression and deduplication, keep those post-reduction figures throughout the calculation. Do not apply a second assumed reduction factor. That would count the same saving twice. Date each measurement and name the workloads and repository settings it covers. That lets a colleague check the starting point.

Table 1. Sizing worksheet inputs, evidence, and planning implications.

Change rate: Capture daily patterns and growth

Measure through the workload events that matter to your business, such as a database maintenance cycle or a bulk import. Keep normal output and peak output visible. An average alone hides the busy days. Show their size so the reviewer can check whether they fit within the reserve.

Record whether retention means days or restore-point count. Current Veeam Backup & Replication 13 new jobs use days; older jobs upgraded from restore-point-based configurations can retain their previous form, as explained in Veeam’s retention-policy documentation. Use consistent units, label TB or TiB, and measure separate workloads before combining them into a portfolio total.

Backup repository sizing depends on deletion eligibility

Veeam immutability retention: Track chain dependencies and expiry

Build a timeline for each full and its dependent increments. Forward incremental backup consists of full backups with dependent incremental backups. Forever forward incremental instead injects increments into a full, a mutable operation that should not be prescribed for locked hardened-repository files. Veeam backup methods.

For hardened repositories, Veeam requires forward incremental backup with active or synthetic fulls enabled. Locked files cannot be merged or deleted until their immutability expires. The requirement does not prescribe one universal weekly full schedule. Your selected cadence belongs in the capacity model.

For active image-level file chains, new restore points can extend protection from the last restore point. Inactive hardened file chains are not extended by new points in the active chain. Once a lock expires, a file can be deleted. Space may not be freed at that moment. Veeam hardened repository immutability.

Give each ledger row a file or block ID, date created, chain links, retention status, lock expiry, and actual deletion date. Use those rows to count what coexists at each full-backup boundary. Do not substitute a universal “retention days plus lock days” rule: that arithmetic hides the chain behavior you are trying to represent.

GFS retention: Count shared restore points once

Grandfather-father-son, or GFS, retention adds longer-lived full backups to the review. On hardened file repositories, a GFS full uses the longer of the repository immutability period and its GFS lifetime. Record this file-specific rule beside the full’s job retention settings. Hardened repository GFS behavior.

Count files or blocks, then track their policy labels. Veeam can assign a higher-level GFS flag to a full already carrying a lower-level flag. A full carrying monthly and yearly flags is one file. Its lock must still reflect the policy that applies. Do not assume that every scheduled monthly and yearly full overlaps. Assignment of GFS flags.

Our Air-Gapped Vault® technology combines repository isolation with immutable storage. Include the configured lock period and the date data becomes eligible for deletion in the sizing worksheet; isolation alone does not tell you when capacity can be reclaimed.

Immutable backup sizing changes with repository technology

Repository protocols: Verify shared-block behavior

Our storage systems provide iSCSI, NFS, and CIFS/SMB access. iSCSI presents block storage to a connected host, which controls the filesystem. NFS and CIFS/SMB present file shares. The protocol alone does not determine whether a Veeam repository can share blocks.

Veeam Fast Clone requirements describe XFS reflink for supported Linux repositories, ReFS block cloning for supported Windows repositories, and additional requirements for SMB shares. NFS can be configured as a repository, but its use alone does not establish Fast Clone support. Verify the selected target and repository configuration, then measure physical allocation after synthetic or GFS fulls. If shared-block behavior is not verified, size from measured usage without assuming those savings.

Table 2. Repository access methods and allocation measurements to validate.

S3 Object Lock retention: Include generation and version behavior

Build a separate model for object storage. Current Veeam 13 object-storage guidance specifies a 30-day block-generation period for Amazon S3 and other listed hosted repository types, and 10 days for other types. Blocks referenced by chains can have protection extended, including references from inactive chain parts; unused blocks are not extended. Veeam’s object-storage immutability rules distinguish lock modes. For non-GFS examples where it applies, entire-policy mode uses the longer job or minimum period plus generation. Minimum-only mode excludes job retention from the lock calculation, while job retention still determines required restore points. Entire-policy mode is unsupported for capacity-tier extents; object GFS follows separate rules, and backups created under prior versions retain their former deletion model.

On Amazon S3, Object Lock protects object versions. When a new version is written under the same key, the locked older version stays in place. Check how the chosen compatible backend handles this. Amazon S3 Storage Lens reports locked bytes and counts you can check against the forecast.

Do not apply lifecycle cleanup rules to Veeam backup buckets; Veeam documents lifecycle and tiering rules as unsupported. Object repository guidance. Veeam 13 guidance also no longer recommends changing block-generation settings.

Calculate backup storage capacity with explicit assumptions

Retained files: Build a transparent baseline calculation

Assume an example ledger contains five full files at 12 TB each and 30 incremental files at 0.36 TB each. All figures use decimal TB and already reflect data reduction. Assume independent full allocations, no shared extents, no additional GFS artifacts or lock extensions, and no metadata or operational overhead.

The fulls total 5 × 12 = 60 TB. The increments total 30 × 0.36 = 10.8 TB. Together, the retained-file baseline is 70.8 TB. These assumed counts do not predict what a 35-day schedule retains. A real timeline must establish how many fulls and increments remain under its configured policy.

This ledger is deliberately limited to unshared files. Do not carry its total into an XFS, ReFS, or object-storage forecast without validating physical allocation. Supported cloning changes the relationship between file size and allocated space.

Capacity sensitivity: Show the cost of longer retention

Change one input at a time to see which one needs a closer look. Each row below is an independent illustrative scenario, not steps in an expansion plan.

Table 3. Independent illustrative retained-file scenarios in decimal TB.

Ten additional increments add 3.6 TB under these assumptions. An additional full adds 12 TB. A longer lock could keep both fulls and increments; the first sensitivity row is not a ten-day immutability forecast. Use it to test an input, then rebuild the timeline for the proposed change.

How DR365V supports backup storage capacity planning

File and S3 repositories: Match configuration to retention policy

When planning capacity for DR365V, start with the repository model you’ve built. DR365V is our Veeam Ready air-gapped and immutable backup and disaster recovery solution. It integrates Veeam with unified block and file storage, AWS-compatible S3 object storage, repository isolation, and recovery capabilities. Available repository types and usable capacity depend on the selected configuration.

Bring the retained-file and block worksheet to the sizing discussion. It should identify measured full and incremental output, the forecast period, lock settings, GFS requirements, expected growth, and the chosen free-space threshold. Ask which capacity figure the proposal quotes: raw disk, usable repository space, or a workload estimate that assumes data reduction.

We recommend confirming the backend layout and modeled disk usage for the selected configuration. If sizing assumes shared blocks, verify that behavior with a pilot and compare actual allocated bytes with logical file sizes. Filesystem, Fast Clone support, and data reduction depend on configuration and workload.

Air-Gapped Vault®: Validate recovery alongside repository capacity

Our DR365V configurations support Veeam job-level repository attachment for air-gapping and an isolated, on-demand sandbox for recovery tests. Use these capabilities to shape the test plan: which jobs attach the target, where will restored workloads run, and how much space will those tests use? They do not change when a file or block lock expires or guarantee a recovery time.

Treat DR365V as the backup and recovery system being sized. State which retained backup bytes, restore resources, and reserves the quote covers. Make those limits clear. Agree on what the acceptance test must show. Compare the quoted capacity with the workload the system must support.

Plan backup storage capacity for peaks and recovery

Repository headroom: Allow for growth and full-backup overlap

Once you have checked physical usage, separate retained-data growth from extra space needed for operations. Veeam’s sizing guidance calls for future growth and full-backup overlap, and cautions that estimators cannot guarantee actual usage. Repository storage guidance. An illustrative 20% increase turns the 70.8 TB baseline into 84.96 TB. If 84.96 TB is the checked forecast physical peak, extra space for operations is zero, and the design requires 20% free space, required usable capacity is 84.96 ÷ 0.8 = 106.2 TB. These percentages are planning choices, not recommended universal reserves or a DR365V specification.

The general planning relationship is:

Required usable capacity ≥ (forecast physical peak + additional operational allowance) ÷ (1 − desired free-space fraction)

Add space only for operations outside the modeled peak. Do not count full overlap in the timeline and again in the allowance. That adds the same bytes twice. Confirm RAID or erasure coding, spares, and system or filesystem reserves separately when turning usable capacity into a raw disk requirement.

Recovery operations: Budget scratch space and concurrency

Record where restore scratch space and test workloads will run. Check whether a planned migration needs more allocation than the source: copying clone-backed files can require more space, and ReFS sharing depends on same-volume operation.

Check speed as well as capacity. Health checks add read I/O; object repositories also require consideration of API calls and throughput. Test the jobs that must run at once against your backup window and recovery goals. A capacity worksheet cannot show that those jobs finish on time.

Validate immutable backup sizing before buying capacity

Capacity review: Compare the forecast with real reclamation

Run a pilot that includes scheduled fulls, relevant lock expiry, and the GFS cycles represented in the design. Compare ledger counts, physical usage, and the dates when space was freed. Find the cause of any mismatch before using the model to approve expansion; file-chain and object-block behavior differ. Hardened repository immutability, object block generation.

Keep the worksheet under monthly review and revisit it when workloads, policies, or backend settings change. Keep the measured inputs with the forecast so the next person can explain why the estimate moved. If the recovery design includes an isolated copy, include its retained data, lock period, and test capacity in the review.

Conclusion

Immutable backup sizing starts with measured backup output and follows each retained file or object block through its lock and deletion date. Validate the forecast against physical usage in a pilot, then add a clearly stated operating reserve. Use that evidence to compare repository capacity and recovery requirements before approving a configuration.