Estimate the repository capacity your backups need from your source data, daily change, retention, long term restore points, immutability and growth. It is a planning estimate to start the conversation, not a vendor sizing tool.
Updated 12 October 2026
C4C is an independent consultancy and a Veeam and Object First partner. We design backup repositories that can survive ransomware, then help you buy and build them. Immutable backup for Veeam.
Enter the data you protect and the policy you run, or the one you plan to run.
The data protected today.
Short term and long term restore points.
These change the answer more than most people expect.
Replace these with your own figures.
Get a formatted PDF of these results by email, to keep or share with your team. We send it once and do not add you to any list.
Prefer email? Write to hello@c4cgroup.co.uk.
The estimate starts with the active backup chain: one full backup of your source data plus the daily changes for the longer of your short term retention or your immutability period, because restore points under immutability cannot be deleted early. If you run weekly periodic fulls, it adds the previous chain, because Veeam keeps it on disk until all of its restore points expire (Veeam). It then adds your weekly, monthly and yearly restore points: as full copies without block cloning, or, with block cloning, as only the data changed since the previous retained point, capped at a full backup. That last step is our cautious planning approximation: because the same blocks often change more than once, real use is usually lower, and Veeam does not publish a percentage for it.
The logical total is divided by your data reduction ratio to give the repository needed today. Growth is compounded over the years you plan for, and the headroom percentage is added on top as working space.
Veeam’s own sizing guidance names the inputs that matter: backup frequency, retention, daily change rate, yearly growth and the forecast period (Veeam Best Practice Guide). Six details catch people out:
For final sizing Veeam points to its own calculator, and says real life can differ from any estimate (Veeam).
Object First lists Ootbi appliance capacities of 18, 36, 72, 144, 216 and 432 TB, and says a four node cluster can provide up to 1.7 PB of usable storage (Object First, Object First). The smaller Ootbi Mini runs from 8 to 24 TB per node, up to 96 TB usable across four nodes. Object First also offers its own backup storage calculator for Veeam data. C4C is an Object First and Veeam partner and can size and supply it.
Start with the data you protect and its daily change rate, then add up what your policy keeps: the active chain for the longer of your retention or immutability period, any overlap from periodic fulls, and your weekly, monthly and yearly restore points. Apply a realistic data reduction ratio, allow for growth over the life of the repository, and leave working headroom. Then confirm with the backup vendor’s own sizing tools.
Restore points, if your jobs run more than once a day. Each run creates a restore point, so a job that runs four times a day for 30 days keeps far more restore points than one that runs daily. Size on the number of restore points your schedule actually creates.
Immutable restore points cannot be deleted until their immutability period ends, so the repository holds them for at least that long. Veeam extends immutability across the active chain on a hardened Linux repository, and adds a block generation period on object storage, so immutable data can hold capacity for longer than the retention setting alone suggests.
Only without block cloning. Without it, Veeam writes a new full and keeps the previous one until retention removes it. With ReFS or XFS Fast Clone, the synthetic full references existing blocks and copies only what has changed, which uses far less space.
Grandfather, father, son: keeping weekly, monthly and yearly restore points alongside daily ones, so you can recover from points further back in time. Veeam does not count GFS flagged fulls against short term retention, so they add capacity on top. Block cloning reduces their real cost considerably.
Veeam’s own guidance says a 2 to 5 percent daily change rate is typical in medium and enterprise environments, but database servers can reach 30 to 50 percent, and backup data usually reduces at 2:1 or better, with 3:1 common. These are planning assumptions: measure your own change and reduction where you can.
No. It is a planning estimate to frame the decision and the budget. Final sizing should use the backup vendor’s own tools with your measured change rates and schedule. Veeam itself says real life can differ from any sizing estimate.