How Veeam v13 Changes Object Storage Immutability Load

Veeam says its latest release makes 8x fewer retention calls to immutable object storage. The most detailed public lab test, published in July 2026, measured an 83 percent drop on one virtual machine. That works out to about 5.9x. Both figures can be accurate, yet neither one sizes an object target.

Veeam v13 moves immutability from the backup chain to the restore point. Each data block gets its lock set once, when it is written, so the chain no longer needs repeated extensions. According to the Veeam community lab test of v13 retention calls, that change removes a large share of lock-extension traffic. It does not remove the versioning, listing and block generation work that still lands on the repository. This article separates what is measured from what is claimed, shows where the load moves, and ends with a checklist for evaluating an on-premises appliance.

What Restore-Point-Based Immutability Changes in Veeam v13

Restore-point-based immutability in Veeam v13 means that each block of a restore point gets its own retain-until date when it is written. That date is not extended again while newer restore points reuse the block. Veeam deletes the block from the repository only after its own immutability period ends. The practical effect is fewer lock-extension requests per backup cycle.

Under Veeam Backup & Replication 12, immutability was extended across the backup chain. Older blocks kept getting new retain-until dates for as long as newer restore points referenced them. Veeam knowledge base article KB4470 describes this as by design. It explains that block generations extended immutability in intervals. That produced periodic spikes of lock-retention calls every 10 or 30 days, depending on the storage vendor.

Falko Banaszak, an independent Veeam practitioner, calls the resulting space overhang storage creep in his original write-up of the v13 immutability change. He sums up the new model this way: “Each data block gets its lock calculated and set once, exactly when it is written, and after that the lock is rarely touched again.”

The mechanism underneath has not changed. According to the Veeam guide on how immutability works with object storage, Veeam relies on Object Lock and object versioning for AWS-compatible S3 object storage repositories. Every restore point holds both unique and inherited blocks. Veeam assigns the immutability period to each of them. The target must support versioning, so version listing and version-aware deletes remain part of every repository design. Veeam v13 changes how often the lock is touched, not what the target has to provide.

The scope is narrower than the headline suggests. Banaszak states that the per-block model applies to direct to object repositories. Veeam 13.1 shipped on 30 July 2026, according to the Veeam 13.1 product update announcement. A Veeam forum thread on retention and immutability that continued after that release reports that the capacity tier of a scale-out backup repository still follows the older additive behavior. Treat that as a community and staff-thread report, not a documented guarantee. Confirm it against the release notes for your build before you plan capacity around it.

Where the Veeam v13 API Load Actually Goes

The most useful public measurement comes from Banaszak. He compared Veeam Backup & Replication 12.3.2.4465 with Veeam v13 build 13.0.1.180. He backed up a single Linux virtual machine to an immutable object repository over one weekend. The test used 30-day retention, 30-day immutability and 1 MB storage optimization blocks. He counted requests from the storage audit logs.

On the weekend incrementals, PutObjectRetention calls fell from 1,770 to 299, a reduction of 83 percent. ListBucketObjectVersions calls fell from 14,501 to 6,813, a reduction of 53 percent. The active full backup told a different story. PutObjectRetention moved only from 15 to 12, while ListObjects fell from 39 to 5 and GetObject fell from 189 to 74. Banaszak is explicit that this was one VM over one weekend, not a full 30-day run at scale. Read every figure here with that limit attached.

Set these numbers against the vendor claims that Banaszak quotes on the same page. Veeam states 8x fewer PutObjectRetention calls, 3x fewer ListBucket calls, more than 2x fewer total API calls and 40 percent less object storage space. The lab shows 5.9x on retention calls. That falls short of 8x but points the same way. The list-versions drop is 2.1x against a claimed 3x for list calls, and the active full is only 1.25x on retention. The vendor figures describe design intent at scale, while the lab figures describe one small workload. Together they show why a single multiplier cannot drive a purchase.

Two bar charts comparing Veeam 12 and Veeam v13 request counts: PutObjectRetention 1,770 versus 299 and ListBucketObjectVersions 14,501 versus 6,813.

What does this mean for an on-premises target? Retention traffic falls. The lock-extension spike that earlier releases produced every 10 or 30 days shrinks. Listing and version calls remain, and they are the heavier read-side work. Request rate still scales with block count. Each node must handle a steady flow of small requests, not a handful of large ones. A repository sized only on ingest throughput will miss that.

Block Generation and Versioning Overhead on Veeam v13 Targets

Block generation is the second source of load that v13 does not remove. The Veeam guide to block generation sets the default at 30 days for Amazon S3, IBM Cloud, Google Cloud and 11:11 Cloud. For all other object storage, the default is 10 days. Block generation adds to the immutability period you configure. A policy of 30 days becomes an effective 40 days on a typical on-premises target. In the words of the Veeam community author known as eblack, “A 30 day setting is an effective 40 with the 10 day generation,” as explained in the community analysis of block generation overhead.

The table applies that rule to common policy windows with a 10-day generation period, and the result is the date when space returns to the pool.

Two timelines on a 40-day scale: 30-day immutability plus 10 days of block generation, and 14 usable days within a 30-day lock plus 10 days.

The effect on capacity is direct. Freed space arrives later than the retention policy suggests. Size the target for the effective window, not the policy window. The Veeam considerations and limitations page gives a range of 1 to 999 days. It warns that setting immutability longer than the job retention policy results in extra charges. It adds that data in a bucket must be managed solely by Veeam, so lifecycle rules are not supported.

Retention and immutability also interact in a way that surprises operators. In a Veeam forum thread opened in March 2026, a user with 14-day job retention and 30-day immutability found 40 days of backups stored. The console showed only 14 usable restore points. Stephen Firmes, a Veeam Solutions Architect, replied: “If your goal is to be able to restore jobs up to 30 days after the backup, you should set the job retention to 30 days.” Matching retention to the real restore window avoids paying for locked data that no one can restore.

Treat the exact numbers with care, because Veeam documentation does not agree with itself. Eblack found different values on different pages of the same user guide, writing about “the same user guide, different answers, and a 20 day spread between the documented values.” Veeam also states that from v13 the improved handling of immutability-related calls makes manual block generation adjustment unnecessary. The block generation page still describes the older chain-wide behavior. Verify the period in the repository wizard and the release notes for your build. Until you have confirmed it, size for the larger of the plausible values.

Target Block Size on HDD Erasure-Coded Object Stores

Veeam splits each restore point into blocks. It sends every block to the repository as an object. The block size chosen in the job settings therefore sets the object count. The lab test above used 1 MB blocks. Banaszak’s 2024 sizing article for object storage with Veeam is older background, but its mechanics still hold. A larger block reduces the quantity of blocks and the API calls, at the cost of larger incrementals.

For an on-premises appliance, the target block size matters more than it does for a hyperscale cloud. Smaller blocks mean more objects. More objects mean more requests, more metadata and more versions to list. One engineering point follows, offered here as reasoning and not as a measured result. Erasure coding spreads each object across several drives. On hard disk drive (HDD) media, every request then touches multiple spindles. That adds per-request overhead that a flash-based store largely hides.

That leaves an honest gap. No public best-practice figure for the target block size on HDD erasure-coded object stores was found while preparing this article. Veeam v13 lowers the retention-call rate, but it does not change how many objects a given block size creates. The sensible path is to benchmark with your own job settings. Run representative jobs at two or three block sizes. Record sustained request rates, backup duration and restore time. Ask any vendor to run the same test, using your block size, rather than quoting peak object-put numbers.

Where StoneFly Fits for Veeam v13 Object Storage Targets

Some teams want a Veeam repository that arrives validated, with immutability and air gapping built in, instead of assembling those pieces themselves. StoneFly DR365V addresses that need. It is a Veeam Ready backup and disaster recovery appliance that has been tested by Veeam and validated for Veeam Ready Object and Veeam Ready Object with Immutability. That validation covers the applicable DR365V object-storage repositories. It carries no version number, so it should not be read as a statement about Veeam v13 specifically.

Within the appliance, the AWS-compatible S3 object tier offers immutable Object Lock for repositories. It includes object-level retention, protection against overwrite and deletion, and WORM policies. StoneFly also offers Air-Gapped Vault®, its patented automated air-gapped and immutable storage technology, as a protection that is separate from object immutability. Object Lock protects stored objects from modification during the retention period. An air gap detaches the repository, controller or node from the network until an authorized backup or restore needs it. The two controls answer different failure modes, and a design can use both. For more on the retention side, see the StoneFly guide to Object Lock for compliance.

For teams that want a standalone target, StoneFly Object Storage is an on-premises object storage appliance. Applications reach it through an AWS-compatible S3 REST API. It is available as a high availability pair, and Scale Out clusters begin with three nodes. Each added node contributes compute, memory, network and capacity, and Scale Out supports erasure coding. HDD and flash media options are available, so you can match the media to the request profile you measure in your own tests. The answers on request rate and block size come from testing, not from a data sheet.

Appliance Selection Checklist for Veeam v13 Targets

Use these six checks with any object appliance vendor, including the one you already run. They turn the findings above into questions with verifiable answers.

1. API request rate. Ask for the sustained PutObjectRetention, list-versions and get rates per node under your own job count, not peak object-put numbers. Retention calls fall under Veeam v13, but list and get traffic still scales with block count.
2. Versioning and block generation overhead. Size capacity for the effective lock window, which is the immutability policy plus the generation period. Confirm the period in the repository wizard, because the Veeam block generation guide and community reports do not describe identical values.
3. Restore throughput. Measure restore speed from the target under concurrent restores, not backup ingest. A restore under pressure is the event the repository was bought for.
4. Node count and failure behavior. Ask what fails and rebuilds at the node and drive level on an erasure-coded set. Ask for the minimum node count in the vendor design, and how the cluster behaves during a rebuild while backups continue.
5. Block size behavior on HDD. Request a test run at your target block size on the exact media you will buy. If the vendor has no data for HDD erasure-coded sets, treat that as an unknown to be measured.
6. Object Lock mode support and air-gap options. Confirm which modes the repository supports and how it works with the job retention policy. Ask how an air-gapped copy is created and restored, and keep it separate from object immutability in your design documents.

Align the job retention with the restore window you actually need, as the Veeam staff reply above recommends. Keep immutability no longer than that retention. A file-level approach to the same discipline is covered in the StoneFly guide to immutable file-level WORM.

Conclusion: Plan Veeam v13 Around the Whole Lock Window

Veeam v13 lowers the retention-call load on an immutable object target. The best public lab test shows an 83 percent drop on one VM, against a vendor design claim of 8x. It does not remove object versioning, list traffic or block generation overhead. It also leaves the question of block size on HDD erasure-coded stores without a public answer. The lock window you pay for is the policy plus the generation period. The restore points you can use are set by job retention, not by immutability.

Sizing a target for Veeam v13 therefore means testing it with your own jobs. Measure sustained request rates and restore throughput, and plan capacity for the full effective window. Run the checklist above against the object storage you operate today. To discuss a Veeam object target for your environment, contact StoneFly to review a Veeam object target design, or read the guide to Object Lock for compliance first and bring your measurements to the conversation.