Choosing between block storage and object storage is one of the most important design decisions in any backup environment. It affects not only your primary backup repository but also your archive tier and your off-site protection strategy. Each option brings advantages but also strict limitations that can change how your backups behave once immutability and retention policies are applied.

In this post, I will focus on the fine print of using object storage as a Veeam repository. We will look at what works well, what does not, and what you need to consider when designing your backup infrastructure.

Backups used to be seen as nothing more than a safety net, something you turned to when a server failed or a file was deleted. In today’s ransomware world, they have become a frontline defense. Attackers know that if they can wipe out or encrypt your backups, they have already won. This is why immutability is so important: it is the safeguard that ensures your recovery points cannot be tampered with no matter what.

With S3 Object Lock, Veeam makes immutable backups possible across public clouds like AWS and Wasabi, purpose-built appliances such as Object First and Cloudian, and even open-source platforms like MinIO. The promise is powerful because even if an attacker gains full administrative rights, the backup data remains untouchable.

The reality, however, is that using object storage as a Veeam repository is not simply a feature you turn on. Object storage behaves very differently from block storage. The limitations are not bugs; they are the natural outcome of combining dynamic backup processes with static WORM storage. If you ignore these rules, you risk higher costs, broken retention chains, and slower recoveries when you need them most.

This article explores these limitations in detail, explains how object storage differs from block storage, highlights vendor-specific quirks, and outlines best practices that can help you avoid mistakes and build a resilient design.

Backup Lifecycles vs. Immutability

On standard block storage such as NTFS, ReFS, or XFS, Veeam has complete flexibility in how it manages backup data. It can merge incrementals into synthetic fulls, transform chains into new formats, and delete expired restore points once retention rules are met. This level of control allows backup jobs to optimize storage space and ensures predictable retention management. Administrators know that when a restore point reaches the end of its lifecycle, it will be removed, freeing up capacity for new backups.

This flexibility changes once immutability is introduced. With a hardened Linux repository using XFS, immutability is enforced at the file system level. Restore points are locked for a defined period, and even a root user cannot alter or delete them until the lock expires. Veeam can still take advantage of XFS block cloning, which makes synthetic operations possible without breaking immutability, but the timing of deletions is no longer as flexible since files must remain untouched until their lock period has ended.

On object storage, the rules are stricter. The storage platform itself enforces immutability through S3 Object Lock. Once a backup object is written, it cannot be modified, and there is no equivalent to block cloning to enable transforms. For this reason, Veeam disables synthetic fulls and forever-forward incrementals when writing to immutable object repositories. Every new chain must be created as an Active Full, and old chains cannot be deleted until every restore point inside them has passed its immutability period.

The result is that backup lifecycle management behaves very differently depending on the storage type. Block storage offers flexibility and efficiency, while object storage enforces absolute protection at the cost of higher capacity usage and simpler, less flexible operations. Designing a resilient infrastructure requires understanding both models and anticipating how immutability will affect your retention and restore workflows.

To summarize the behavior on hardened block storage, when configured as a Veeam Hardened Repository (Linux + XFS immutability):

• Files are marked immutable for a defined retention period, enforced at the file system level.
• Even administrators with root privileges cannot delete or alter them until the lock expires.
• Synthetic fulls remain possible because Veeam leverages XFS block cloning (copy-on-write) instead of modifying existing blocks. This allows hardened repositories to combine immutability with space-efficient backup chains.

On object storage, immutability is enforced differently. The storage system itself applies S3 Object Lock, and once an object is written, it cannot be changed until the lock expires. Unlike XFS block cloning, object storage does not allow transforms or merges. For this reason, Veeam disables synthetic fulls and forever-forward incrementals on immutable object repositories; the only way forward is to create Active Fulls that generate new, independent chains.

Key Difference

• Hardened block repositories → immutability is enforced locally, and synthetic fulls are still possible.
• Object repositories → immutability is enforced by the storage platform, and synthetic fulls are not possible.

This distinction matters greatly for design. Both approaches provide ransomware-proof protection, but the trade-offs in storage efficiency, chain management, and recovery performance are very different. A successful architecture depends on understanding these differences and planning retention and capacity accordingly.

Key Limitations in Veeam v12.3

Understanding how immutability changes backup behavior is only the first step. The real challenge comes when you put this into practice with Veeam. While object storage brings powerful ransomware protection, it also introduces several significant limitations that do not exist in block-based repositories. These limitations are not bugs or missing features; they are the natural result of how object storage enforces immutability and how Veeam adapts its backup chains to respect those rules.

In the following sections, we will look at the most important limitations you will encounter when using object storage as a Veeam repository, explain why they exist, and discuss the operational impact they create for your backup and recovery strategy.

1. Synthetic Fulls and Transforms Disabled

• On standard block storage (NTFS, ReFS, XFS), Veeam can merge incrementals into synthetic fulls or use forever-forward incrementals. These features reduce the need to run full backups frequently, saving both space and bandwidth.

• On hardened block repositories (Linux + XFS immutability), synthetic fulls are still supported. Instead of modifying existing files, Veeam relies on XFS block cloning, a copy-on-write feature that lets synthetic fulls be created without breaking immutability. This allows admins to keep the efficiency of synthetic backups even while locking restore points against deletion.

• On object storage with immutability, however, synthetic fulls and transforms are impossible. Object Lock prevents any modification of existing objects, and there is no block-level cloning mechanism. For this reason, Veeam disables these features entirely. The only way to advance the chain is to run Active Fulls, which create completely new, independent sets of restore points.

Impact: More bandwidth and storage are consumed, especially for environments with frequent full backups. Recovery points are reliable and immutable, but less efficient than block-based chains.

2. Each Active Full = Independent Chain

• On block storage, Active Fulls can coexist with incrementals, and Veeam prunes expired restore points once retention is met. The new Active Full becomes the anchor, and the old chain can be removed quickly.

• On immutable block repositories, pruning still works as expected because XFS immutability applies at the file level. Once the immutability window expires, old files are deleted according to the retention policy.

• On object storage, every Active Full results in a completely independent backup chain. The previous chain (the old full plus its incrementals) cannot be deleted until all its restore points have passed their immutability period. This often means multiple chains overlap in storage, even if retention would normally allow the old chain to be deleted.

On block storage, backup chains can be trimmed or deleted as soon as retention rules allow, keeping storage growth predictable. On immutable object storage, older chains cannot be deleted until their lock expires. As new active fulls are created, the old chains remain in place, causing overlap and temporary spikes in capacity usage.

Impact: Storage consumption is significantly higher than on block repositories. For example, with monthly Active Fulls and 30-day immutability, enterprises will hold two complete full chains for nearly the entire month. Capacity planning must account for this overlap.

3. The Block Generation Effect

• On block storage, retention rules are precise. If you set 14 days, the 15-day-old restore point is deleted immediately.

• On object storage, immutability introduces what Veeam calls the Block Generation Effect. A backup chain is treated as a single logical unit, so older restore points cannot be deleted while newer ones in the same chain are still immutable. The immutability of the youngest restore point effectively extends the lock of the older ones.

• This does not break retention logic; you can still restore all valid points,  but it does delay space reclamation.

Impact: Admins often notice that object storage capacity does not free up on the expected day. Storage usage will run “hotter” than the math suggests, because chains remain intact until the last locked point expires. This effect must be factored into capacity models, or enterprises risk running out of space unexpectedly.

4. Immutability Cannot Be Shortened

• On block storage, files can be deleted as soon as retention rules expire, since the repository controls its own filesystem.

• On hardened Linux repositories, immutability is enforced by XFS at the OS level. Once a file is locked, it cannot be deleted until the lock expires, but synthetic operations are still possible thanks to block cloning.

• On object storage, Object Lock ensures that once a retention period is applied, it cannot be reduced or overridden, not even by a root administrator. Locks can be extended (e.g., via PowerShell to go beyond the 90-day UI limit) but never shortened.

Impact: Misconfiguration can be costly. An accidental 3-year immutability window applied to large datasets guarantees three years of storage spend. Enterprises must align immutability with compliance requirements and test policies in staging environments before committing to production.

5. Performance and Latency Differences

• On block storage, latency is minimal (1–2 ms). This allows fast synthetic operations, smooth incremental merges, and high-speed restores. Instant Recovery and file-level recoveries are generally fast and predictable.

• On object storage, latency is far higher (10–40 ms typical), especially with cloud-based repositories (AWS S3, Wasabi). Every read and write operation must traverse HTTP APIs, which adds overhead. Random read performance is particularly affected, which impacts Instant Recovery directly from object storage.

• Some on-prem appliances (Object First, Cloudian) mitigate this problem with caching layers (NVMe or SSD). This can improve restore performance, but it does not remove the inherent difference in how object storage is accessed.

Impact: While backups may perform adequately, restores from object storage,  especially in a disaster recovery scenario, are slower than from block repositories. Enterprises should plan for staging areas on fast block storage when quick recovery is required.

6. Governance vs. Compliance Mode

• On block storage, immutability depends on repository configuration (Linux hardened repos with XFS flags). Security is strong, but if the repository OS is compromised, there is still some dependency on system integrity.

• On object storage, immutability comes in two modes:
  • Governance Mode: Privileged users can reduce or remove locks.
  • Compliance Mode: Locks cannot be shortened or removed, even by administrators.

• AWS S3, Wasabi, and Cloudian support compliance mode.
• MinIO and some lower-end appliances often only support governance mode.

Impact: Compliance mode is mandatory for true ransomware protection. Governance mode may satisfy some regulatory requirements, but leaves a gap; a compromised admin account could still unlock and delete backup data. Enterprises must validate vendor capabilities before committing to object storage.

Vendor-Specific Considerations

Not all object storage platforms behave the same way. While the limitations we’ve covered so far apply broadly to any S3-compatible target, each vendor brings its own quirks in pricing, performance, and immutability enforcement. Understanding these differences is critical. A design that works smoothly on AWS may behave very differently on Wasabi, Cloudian, or MinIO. Before committing, it’s worth looking at how the major vendors stack up in practice.

• AWS S3
  Mature, reliable compliance lock. The downside is cost; recovery traffic incurs egress charges, which can spike during disaster recovery. Enterprises must budget for this as part of their design.

• Wasabi
  Attractive flat-rate pricing ($6/TB), but the 90-day minimum storage policy means you pay for three months even if retention is only 30 days. This can conflict with short retention designs.

• Object First
  Purpose-built for Veeam, with built-in immutability and local cache. This avoids many of the performance pitfalls of cloud object storage. Limitation: It’s an appliance, so flexibility is tied to hardware availability.

• Cloudian HyperStore
  Good fit for petabyte-scale deployments. Fully supports compliance mode. However, admins must carefully tune chain segmentation and metadata settings to avoid inefficiency with many small incrementals.

• MinIO
  Popular open-source option for on-prem object storage. Flexibility is its strength, but immutability is typically governance-only, leaving a gap in ransomware defense compared to compliance-capable vendors.

Best Practices for Object Storage Repositories

By now, it’s clear that using object storage as a Veeam repository comes with both strengths and limitations. The difference between success and frustration usually comes down to how you design around those rules. Best practices are not optional here; they’re the guardrails that keep costs under control, ensure retention works as intended, and guarantee that restores will perform when you need them most.

Design Retention First

On block storage, you can adjust retention relatively freely. On object storage, immutability locks are unbreakable once set. Plan immutability windows, retention policies, and Active Full schedules before creating any jobs.

Size for Overlap and Growth

Block storage frees space predictably when restore points expire. Object storage does not, chains overlap, and block generation extends retention. Always size repositories for multiple chains in coexistence and delayed space reclamation.

Use SOBR Copy Mode

If combining a performance tier with object capacity, always use Copy mode. This ensures new backups are immediately written to immutable storage. Move mode delays protection until performance tier retention expires, leaving a vulnerability window.

Monitor with Veeam ONE and Capacity Reports

Do not rely on simple daily change rate math. Object storage retention behavior means usage patterns are more complex. Veeam ONE and built-in reporting understand the Block Generation effect and give realistic capacity projections.

Never Touch Bucket-Level Policies

Do not set global lifecycle rules or bucket-level object lock. Veeam needs granular, per-object control. Bucket-level policies will interfere with retention and can break restore chains.

Validate Compliance Mode

Always confirm with your vendor whether object lock is compliance-grade or governance-only. Governance may meet some retention requirements, but it is not safe against ransomware.

Mini Runbook: Restoring from Immutable Object Storage

When ransomware strikes, immutable storage guarantees that your backup data cannot be deleted or encrypted. Those restore points will still be there when everything else feels compromised. However, the recovery workflow is not identical to what you might be used to with block storage. The latency and behavior of object repositories mean you need to think differently about how restores are tested, how Instant Recovery performs, and how data is rehydrated back into production. Treat this runbook as a reminder that immutability protects the existence of your backups, but it does not automatically make recovery fast or straightforward.

1. Detect Infection – Use Veeam’s Malware Scan to identify clean backups.
2. Validate – Test recovery points with SureBackup in an isolated environment.
3. Instant Recovery – Be prepared for slower performance from object storage. If necessary, rehydrate critical workloads onto local block storage first.
4. Full Recovery – For large jobs, consider restoring into a staging repository (faster block storage) and then migrating VMs back into production.

Looking Ahead: Veeam v13

Everything described here applies to Veeam v12.3. Veeam has announced that v13 will expand object storage functionality, potentially reducing the need for Active Fulls and improving performance. Immutability principles will not change — WORM storage cannot be relaxed — but some operational pain points may ease.

When v13 is released, review the release notes to see whether these limitations still apply to your design. For now, plan based on today’s hard rules.

Conclusion

Object storage as a Veeam repository delivers a mix of scale, flexibility, and ransomware protection that traditional block storage often lacks. The appeal is obvious: you get virtually unlimited capacity, built-in immutability, and the ability to choose from cloud or appliance vendors depending on your strategy. For many organizations, it feels like the natural evolution of backup infrastructure.

But it’s not without trade-offs. The biggest challenges come from the loss of synthetic fulls and transforms, the less predictable timing of retention enforcement, and the performance gap when restoring directly from object storage. These are not small details — they can completely change how you size your repositories, how you design recovery workflows, and how much you end up spending over time.

The lesson is clear: object storage has its own rules, and success comes from respecting them rather than trying to bend them. Retention and immutability windows must be planned together, capacity must be sized generously, and restores must be tested from the actual storage you plan to rely on during a crisis. Perhaps most importantly, you must validate that your chosen vendor truly supports compliance-mode immutability, because that single detail decides whether ransomware protection is absolute or only partial.

What I’ve seen in practice is that teams who approach object storage as “just block storage in the cloud” usually run into frustration — runaway costs, slower recovery, or unexpected retention behavior. Teams that embrace its nature, however, end up with a far more resilient platform. Object storage, when designed properly, isn’t just a backup target; it becomes a hardened foundation for your entire ransomware defense strategy. And while Veeam v13 may ease some of today’s operational limitations, the principle won’t change: immutability is not a feature to turn on, it’s a discipline to design around.

Share this article if you think it is worth sharing. If you have any questions or comments, comment here, or contact me on Twitter(yes for me is not X but still Twitter).

©2025 ProVirtualzone. All Rights Reserved