Azure immutable storage with Veeam: why it is mission critical for backup

The hard part of backup is not getting data out. It is keeping that data somewhere that cannot be destroyed by the same person, process, or attacker that would also want to destroy your production systems. Every modern ransomware playbook includes a step to find and delete backups before the encryption ever starts. If the attacker reaches your backup repository with valid credentials, your backup software will cooperatively delete everything you thought would save you.

Immutability is the answer to that problem. A backup that cannot be deleted or modified – not by an admin, not by the backup service account, not by a compromised credential – survives the attack even when the rest of your infrastructure does not. Azure Immutable Blob Storage combined with Veeam Backup and Replication is one of the more common and better-proven implementations of that pattern for small and mid-sized businesses. This article walks through what it actually is, how Veeam uses it, what “mission critical” means here in practical terms, and the configuration gotchas that quietly break the protection you think you have. (For the broader question of whether to use Azure or AWS in the first place, see Azure vs AWS for small business.)

What Azure Immutable Blob Storage actually is

Azure Immutable Blob Storage is a feature of Azure Blob Storage that enforces a write-once-read-many (WORM) policy on blobs. Once a blob is written with an immutability policy applied, it cannot be modified or deleted until the policy expires or is explicitly removed through a privileged, auditable process.

Azure offers two forms of immutability, and the distinction matters for backup.

Time-based retention

A blob is locked for a defined period, measured in days. During that period, the blob cannot be deleted or overwritten. Delete calls from the Azure API return an error. Even storage account owners cannot remove the data while the lock is in effect. When the retention period expires, the blob becomes deletable normally.

For backup, time-based retention is the default choice. You set a retention window – 30 days, 90 days, a year – that matches your recovery requirements, and every backup written into the container is protected for that period.

Legal hold

A blob is locked indefinitely with a named tag, typically for litigation or regulatory discovery. The lock has no expiration; it is released by a user with the correct permissions removing the tag. Legal hold is rarely used for routine backup, but some environments apply it on top of time-based retention for specific data.

Version-level immutability, scoped to the container

Azure supports immutability at two scopes: container-level policies that apply uniformly to every blob, and version-level policies that apply per blob version. Veeam uses version-level immutability, but with a specific configuration that catches a lot of teams out the first time they set it up.

The storage account must have blob versioning enabled with “keep all versions.” Version-level immutability support, however, must be disabled at the storage account level – enabling it there creates default immutability policies that Veeam does not support. Instead, version-level immutability support is enabled at the container level when you create the container (under the Advanced section). Veeam then applies per-version immutability policies on each backup file it writes into that container.

The other hard requirement: immutability can only be enabled when the container is first created. You cannot retrofit immutability onto an existing container that already holds Veeam backups. If you want to add immutability to an environment that has been running without it, you create a new container with the correct settings and migrate forward.

Unlocked vs locked policies

A critical distinction that catches teams out: Azure supports both unlocked and locked immutability policies.

• Unlocked policies can be shortened or removed by a user with the correct permissions. They are useful for testing the feature, but they do not protect against a compromised admin account.
• Locked policies cannot be shortened or removed. They can only be extended. Even a Global Administrator in the Azure tenant cannot remove a locked immutability policy before it expires.

If your Azure immutability is “enabled” but the policy is unlocked, your backups are not actually ransomware-proof. A sophisticated attacker with tenant admin credentials can simply remove the policy and then delete the data. Locking the policy is the step that turns it from a compliance feature into a security control.

How Veeam uses Azure immutable storage

Veeam Backup and Replication supports Azure immutability through the Capacity Tier of a Scale-out Backup Repository (SOBR). Understanding the architecture makes the rest of the configuration decisions clearer.

The Scale-out Backup Repository model

A Scale-out Backup Repository in Veeam has up to three tiers:

• Performance Tier. Local or near-local storage where new backups land and recent restores are served from. Typically a NAS, SAN, or a Veeam hardened Linux repository.
• Capacity Tier. Cloud object storage for longer retention and offsite protection. This is where Azure Blob Storage fits in.
• Archive Tier. Deep archive for very long retention, using Azure Archive, AWS Glacier, or similar. Optional.

Backups are written first to the Performance Tier, then copied or moved to the Capacity Tier according to the policy you configure. The copy mode sends a copy of every new backup to Azure while keeping it on the Performance Tier for fast restore. The move mode migrates older backups to Azure once they age past a threshold. For ransomware resilience, copy mode is standard: you always have a cloud copy even if the local repository is destroyed.

Immutability configuration in Veeam

When you add an Azure Blob Storage object as a Capacity Tier repository in Veeam, there is a checkbox: “Make recent backups immutable for X days.” Checking that box tells Veeam to apply a version-level immutability policy to every backup file it writes to the container, with the retention you specify.

Veeam translates this into Azure API calls that set the immutability policy on each blob version at write time. The backup repository service account needs specific permissions on the storage account: the ability to create blobs, read them back, and set immutability policies. It does not need, and should not have, the permission to delete or override existing policies.

What gets protected and for how long

Immutability in Veeam applies to backup files (VBK, VIB, VBM). Veeam automatically extends the immutability window on dependent incremental files when the chain grows, so the integrity of a backup chain is preserved. A 30-day immutability window does not mean backups are deleted after 30 days; it means they cannot be deleted until at least 30 days have passed. Your retention policy determines when backups age out; immutability determines the minimum time they cannot be touched.

The common configuration for small and mid-sized businesses is a 14 to 30 day immutability window on the Capacity Tier, with retention on the Performance Tier tuned to operational needs. For environments with stricter ransomware dwell time concerns, 60 to 90 day immutability is reasonable.

Why this is mission critical

“Mission critical” is a term that gets used loosely. In this context it means: the business does not survive in a recognizable form if this specific protection fails during a specific category of incident. Three scenarios drive that.

Targeted ransomware

Modern ransomware operators do not encrypt blindly. They establish persistence, elevate privileges, find the backup system, and destroy backups before triggering encryption. The Conti playbook that leaked in 2022 included explicit steps to identify Veeam servers, stop Veeam services, and delete backup repositories before encryption. Other groups use the same pattern.

Without immutability, an attacker who reaches the Veeam server with administrative access can log into the console, delete the repositories, and then encrypt production. When the business checks its backups, there is nothing to restore from.

With locked Azure immutability, the same attacker runs the same script, the Azure API returns “policy violation” on every delete attempt, and the backups remain. The attacker can encrypt production, but the organization can rebuild because the cloud copy is untouchable within the retention window.

This is the single largest value Azure immutability provides. Everything else is a bonus.

Insider threat and credential compromise

Immutability protects against more than external ransomware. A departing employee with lingering access, a misused service account, or a compromised help desk credential can all cause the same kind of data destruction as a ransomware operator. Immutable storage means no single credential, no matter how privileged, can destroy the offsite copy before the retention period expires.

This matters for smaller businesses specifically because smaller environments often have fewer administrators, less separation of duties, and more shared credentials. The principle of least privilege is harder to enforce when one person handles backup, email, networking, and user management. Immutability provides a structural control that does not depend on perfect credential hygiene.

Operational error

The third scenario is mundane but real. Someone deletes the wrong job. A script runs with incorrect parameters. A cleanup process intended for dev data hits the production container. Without immutability, a single bad command can destroy months of backup. With immutability, the same command fails and the data remains.

This scenario is how immutability most often justifies itself for businesses that never experience a ransomware attack. The backup policy was going to be fine until the day it wasn’t, and the protection that was there for the rare catastrophic event also caught the common, low-drama mistake.

How Azure immutability fits into the 3-2-1 rule

The 3-2-1 backup rule calls for three copies of data, on two different media, with one offsite. Azure immutable blob storage is the “one offsite” for a Veeam deployment that uses a local hardened repository or appliance as the primary backup target. It satisfies the offsite requirement and adds the ransomware-resilience layer that the rule alone does not require but increasingly needs.

Some variations of the rule – sometimes called 3-2-1-1-0 – explicitly add “one immutable copy” and “zero errors on restore tests.” That framing matches how modern backup architecture actually needs to work. Immutable cloud storage is the cheap, durable way to satisfy the immutable-copy requirement without building a dedicated on-premises hardened repository.

Common misconfigurations that break the protection

Immutability is effective only if it is configured correctly. The most common ways the protection silently fails:

The immutability policy is unlocked

The single most common mistake. The container has an immutability policy, but it is an unlocked policy. Azure allows unlocked policies to be shortened or removed. An attacker with tenant admin credentials – exactly the credentials a successful ransomware operator will obtain – can remove the policy and then delete the data.

Locking the policy is a deliberate, one-way action. Once locked, it cannot be unlocked. This causes hesitation during setup, which is why unlocked policies persist. Plan the retention period carefully, then lock.

Retention is too short

A 7-day immutability window sounds reasonable until you learn that ransomware dwell time – the period between initial compromise and encryption – averages several weeks for targeted attacks. If the attacker is in the network for 30 days before executing, and your immutability is 7 days, the attacker can simply wait for old backups to age out before triggering the event. Retention of at least 30 days is the floor. 60 to 90 days is safer.

Versioning is not enabled, or is misconfigured

Veeam’s version-level immutability requires blob versioning to be enabled on the storage account with the “keep all versions” option. If versioning is off, the immutability policy may appear to apply, but the protection is incomplete. Verify versioning is explicitly enabled on the storage account before trusting the configuration.

Version-level immutability enabled at the wrong scope

It is intuitive to enable version-level immutability support at the storage account level and assume that covers every container inside it. Veeam does not work that way. Enabling version-level immutability support at the storage account level creates default immutability policies that Veeam explicitly does not support, and it can prevent Veeam from processing the container correctly. The correct configuration is version-level immutability support disabled at the storage account level and enabled at the container level when the container is created.

Soft delete is enabled

This is the one most people get wrong on the first try. Azure Blob soft delete retains deleted blobs for a configurable period and sounds like an obvious additional safety layer. It is not compatible with Veeam immutability – Veeam does not support soft delete for blobs on the storage account used for an immutable backup container. Soft delete for blobs must be disabled on the storage account. Immutability replaces soft delete in this architecture; the backup files cannot be deleted in the first place, so the soft-delete retention window adds nothing but incompatibility.

Lifecycle management policies are configured on the container

Azure lifecycle management can automatically transition or delete blobs based on age. It must not be configured on a container that Veeam uses for immutable backup. A lifecycle rule that deletes aged blobs will conflict with Veeam’s retention logic and can corrupt backup chains. Leave lifecycle management off for the backup container.

The backup service account has excessive permissions

Veeam needs permission to write blobs and apply immutability policies. It does not need permission to delete storage accounts, modify tenant-level policies, or remove immutability locks. Over-scoping the service account creates the exact attack path immutability was meant to close. Use a scoped role assignment on the storage account specifically, not a subscription-wide Contributor role.

The Azure account shares credentials with production

If the Azure tenant that hosts the immutable backup uses the same Active Directory federation as the domain the attacker compromised, credential pivoting becomes trivial. A best-practice deployment puts the backup storage account in a separate Azure tenant, or at least behind a separate admin account with MFA enforced independently of the production admin accounts, and with no federated access from compromised domains.

Nobody verifies the configuration after changes

Azure and Veeam both evolve. A storage account migration, a Veeam upgrade, a policy refactor – any of these can silently disable immutability if someone is not paying attention. Immutability status should be checked during every restore test and during scheduled quarterly reviews. “We turned it on two years ago” is not a current statement of protection.

How to verify immutability is actually working

Trust the configuration only after you have proven it works. The verification is straightforward.

1. In Azure, confirm the policy is locked. Open the storage account, navigate to the container Veeam writes to, check the immutability policy, and confirm the policy state is “Locked” – not “Unlocked.”
2. Confirm blob versioning is enabled on the storage account with “keep all versions,” and confirm that soft delete for blobs is disabled and that version-level immutability support is disabled at the storage account level (it belongs on the container).
3. In Veeam, confirm the Capacity Tier shows immutability enabled with the configured retention window. The SOBR properties page lists the immutability setting.
4. Test a deletion. Pick a recent backup file in the Azure container and attempt to delete it through the Azure portal using a privileged account. The delete should fail with an immutability policy error. If the delete succeeds, the protection is not working.
5. Test a restore. A backup that cannot be restored is not a backup, regardless of where it is stored. Run a periodic restore from the Capacity Tier specifically, not just from the Performance Tier, to confirm the cloud copy is complete and readable.

Document the results of each check. For compliance-driven environments, this documentation is often required. For everyone else, it is the difference between assuming you are protected and knowing you are.

Where Azure immutable storage fits in a managed backup service

This level of configuration – Azure tenant setup, service account scoping, versioning, soft delete, locked immutability policies, Veeam SOBR configuration, periodic verification – is why managed backup services exist. The individual pieces are not complicated, but the combination needs to be right, stay right through personnel changes and software upgrades, and be provable to auditors and insurers.

Cyber insurance underwriters have started asking specifically about immutable backup. A cyber insurance questionnaire that asks “Do you maintain immutable offsite backups?” is not satisfied by “we back up to the cloud.” The expected answer is “Yes, Azure Immutable Blob Storage with version-level immutability locked at 60 days, integrated through Veeam Scale-out Backup Repository, verified quarterly.” The gap between those two answers often determines whether a policy is written and at what premium.

How Sequentur deploys this

For clients on our managed backup service, the standard architecture uses a local Veeam hardened repository or backup appliance as the Performance Tier, with Azure Blob Storage as the Capacity Tier carrying locked version-level immutability. Retention on the immutable tier is set to 30 or 60 days depending on client risk profile. Blob versioning is enabled on the storage account with “keep all versions”; soft delete for blobs is disabled, since it is incompatible with Veeam’s immutability model; version-level immutability support is enabled on the container rather than the storage account; and no lifecycle management policies are configured on the container. The Azure tenant hosting the backup storage is separated from the client’s production Azure or Microsoft 365 tenant, with its own admin accounts and MFA enforcement.

Veeam service accounts are scoped to the specific storage account with the minimum permissions needed to write backups and apply immutability policies. We verify the immutability state during every quarterly review and pull test restores from the Capacity Tier specifically, not just from the local repository, so we know the cloud copy is usable.

If you are running Veeam today and are not sure whether your Azure storage is truly immutable – or if you are on a different backup stack and wondering what it would take to add this protection – we are happy to review your current setup and tell you honestly where the gaps are. You can reach us through our contact page to start that conversation.