Sizing immutable object storage for Veeam is not the same as sizing a disk repository. On object storage Veeam keeps data for longer than the retention you set, it cannot clear anything early, and the backup method you choose can triple the capacity you need. This guide sets out the Veeam rules that decide it, then works through an example on an Object First Ootbi appliance.
View the data behind this chart
| 7-day lock | 14-day lock | 30-day lock | 60-day lock | 90-day lock | |
|---|---|---|---|---|---|
| Forever-forward | 44 TB | 44 TB | 44 TB | 62 TB | 80 TB |
| Weekly active fulls | 144 TB | 144 TB | 144 TB | 242 TB | 360 TB |
Why immutable object storage holds more than your retention
Two Veeam behaviours add capacity on top of the restore points you think you are keeping. The first is the immutability period itself: if it is longer than the job retention, Veeam keeps the data until the lock expires. The second is block generation. To avoid extending locks on every incremental, Veeam adds a block generation period to the immutability expiry of the data that starts each generation: 30 days for Amazon S3, IBM Cloud, Google Cloud and 11:11 Cloud, and 10 days for every other object storage type, which includes S3-compatible appliances such as Ootbi.
Within one generation, every incremental shares the expiry of the full backup that started it, so a block written on day 9 is locked until the same date as one written on day 1. Every restore point is locked for at least the immutability period; the first in a generation gets up to the full extra days. Blocks that newer restore points still use are moved into new generations and stay locked. Nothing about this is a fault; it is how Veeam keeps object-storage locking efficient. But it means space is freed later than a disk repository would free it.
Veeam’s actual-retention rule
Veeam’s v13 documentation offers two ways to set immutability on an object storage repository. If immutability follows the job retention, the actual retention is the longer of the job retention and the minimum immutability period, plus the block generation period. If the repository is set to the minimum immutability period only, job retention is ignored and data is kept for that period plus block generation. Veeam works three scenarios with a 7-day immutability and 10 days of block generation: 13 days of job retention keeps data for 23 days; 3 days of job retention keeps it for 17; and the immutability-only setting keeps it for 17.
Two exceptions matter. Restore points with GFS flags, VeeamZIP backups and exported backups take the repository’s immutability period, whatever their own retention says, so a yearly GFS point is locked for the immutability period and then kept by its GFS policy. And an object storage repository used as a Scale-Out Backup Repository capacity extent is switched to the minimum-immutability rule.
- •Immutability following job retention: actual retention = max(job retention, immutability period) + block generation.
- •Minimum immutability only: immutability period + block generation; job retention ignored.
- •Block generation on S3-compatible storage such as Ootbi: 10 days.
- •Following a 30-day job, a 30-day lock keeps data for up to about 40 days, and a 90-day lock for up to about 100.
The backup method decides most of the capacity
On object storage Veeam reuses blocks it has already written for synthetic full backups and for merges, so a synthetic full costs only the blocks that changed. Active full backups and incrementals do not reuse blocks: an active full writes every block again. On an immutable target that new full cannot be cleared until its lock expires, so every active full in the retention window sits there in full.
This is why Object First’s setup checklist tells Ootbi customers to use forever-forward incremental and to disable active fulls on cloned jobs. It is the single largest sizing lever, and the one most often missed when a job is pointed at a new repository with its old settings.
A worked example
Our arithmetic, with every assumption stated. A full backup that takes 20 TB on disk after Veeam’s own compression, 0.6 TB of changed data written each night, daily restore points kept for 30 days, and a 30-day immutability period that follows the job retention. By the rule above, data is held for up to about 40 days.
With forever-forward incremental, the repository holds roughly one full plus 40 days of changed blocks: 20 + 40 × 0.6 = about 44 TB. With weekly active fulls instead, about six fulls are held at any time across those 40 days, plus the same incrementals: 6 × 20 + 24 = about 144 TB. Same data, same retention, more than three times the storage.
These are deliberately rough, and conservative in places: they count an incremental on every one of the 40 days, apply the full 10 days of block generation to every block, and round fulls up. A forward chain can also hold one extra full while it waits for its newest restore point to age out. Figures are decimal TB; Veeam reports sizes in binary units, which read about 10% larger for the same data. Take your own full size and nightly change from existing Veeam job statistics rather than from a rule of thumb.
View the data behind this chart
| 1 × 144 TB | 2 × 72 TB | 1 × 216 TB | |
|---|---|---|---|
| Usable capacity | 144 TB | 144 TB | 216 TB |
| Full in year 3 | About 53% | About 53% | About 35% |
| Rated ingest | 1 GB/s | 2 GB/s | 1 GB/s |
| Instant Recovery VMs | 20 | 40 | 20 |
| Rack space | 2U | 4U | 2U |
| Power, backing up | 490 W | 980 W | 490 W |
When the lock is longer than the retention
Longer immutability is a sensible response to attackers who sit undetected for weeks. It changes the arithmetic, because the lock now sets the retention. In the same example with 30 days of job retention, raising immutability to 60 days holds data for about 70 days, and 90 days of immutability holds it for about 100.
With forever-forward incremental that adds the extra days of changes: about 62 TB at 60 days and 80 TB at 90 days. With weekly active fulls it multiplies the fulls: about 242 TB and 360 TB. The chart compares the two methods across lock lengths, all with the same 30-day job retention.
From stored terabytes to Ootbi nodes
Two more allowances turn the stored figure into hardware. Growth: at 20% a year, the 44 TB example becomes about 53 TB after one year and 76 TB after three. And headroom, because a repository that runs full fails backups; we size to stay under about 80% full at the end of the planning period, which puts this example at about 95 TB usable.
On Ootbi that points at a single 144 TB node, about 53% full in year three, or two 72 TB nodes clustered for the same capacity with twice the rated ingest and Instant Recovery capacity. A 72 TB node alone would fill up within three years; a 216 TB node buys room for a longer lock. Object First rates the 18 to 216 TB models at up to 1 GB/s each, so at best the 20 TB first full takes about 5.6 hours on one node and a 0.6 TB nightly incremental about 10 minutes, assuming Veeam’s proxies keep up.
Size the offsite copy separately. If it goes to tape or a cloud vault with its own retention, it has its own sizing; see tape library sizing for the tape side.
Before you buy
Measure the inputs from Veeam rather than guessing them: the on-disk size of your latest full, the average nightly increment, and how much both have grown in a year. Decide the immutability period from how quickly you would detect an intrusion, then size for the longer of that and your retention, plus up to 10 days. Check every job that will target the new repository for active fulls. And once it is running, Veeam’s SOSAPI capacity reporting, which Ootbi supports, shows the real usage in the Veeam console, so you can see whether the plan holds.