An immutable backup storage is crucial when safeguarding critical business data from deletion, modifications, and cyberattacks. With Azure Blob Storage, IT administrators and MSPs can set up Write Once, Read Many (WORM) protection with time-based locks for such data.

This guide provides step-by-step instructions for configuring immutable (WORM-protected) backup storage in Azure Blob using time-based retention policies.

Looking for a simple visual guide? Watch “How to Set Up Immutable Backup Storage Using Azure Blob with Time-Based Locks” for more details.

Setting up an immutable storage backup using different methods

Setting up an immutable storage backup is a three-step process. While the first step of the process is rather straightforward, steps 2 and 3 can be done using Azure CLI, PowerShell, or the AzCopy tool.

Prerequisites:

Before proceeding, make sure you have the following requirements:

• An active Azure subscription with access to create storage accounts
• A contributor or Storage Blob Data Owner role
• PowerShell Az module or Azure CLI
• Azure Resource Provider: Microsoft.Storage must be registered.

Tip: Endpoint tagging, GPO/Registry tracking, and audit requirements are optional, yet valuable resources. You can set these up using available supporting methods.

Step 1: Create a storage account with Immutable Blob Support

Users need to create a storage account with version-level immutability support first before they can host and configure immutable containers.

To create the appropriate account, do the following steps:

1. Open the Azure Portal and go to Storage accounts > Create.
2. Configure the following options:
   • Performance: Standard
   • Redundancy: Locally-redundant or Geo-redundant
   • Enable Hierarchical namespace: Optional (for Azure Data Lake)
3. Under Advanced > Data protection, modify the following:
   • Enable version-level immutability support.
   • Enable Blob soft delete (optional for added protection).

Important: Failure to enable both settings can lead to problems upon enforcement. Read more about this in the Things to look out for section.

4. Finish the setup and provision the storage account.

Step 2: Create an immutable container with a time-based lock

To create an immutable container, you can use either Azure CLI or PowerShell.

Method A: Azure CLI

Azure CLI is a cross-platform command-line tool that allows users to connect to Azure and execute commands affecting Azure resources.

📌 Use Cases: Azure CLI is ideal for:

• Cross-platform environments
• DevOps pipelines
• Task automation via shell scripts
• IT administrators managing Azure resources remotely or via SSH terminals

Run this command:

az storage container create \
–name secure-backups \
–account-name mystorageaccount \
–auth-mode loginaz storage container immutability-policy set \
–account-name mystorageaccount \
–container-name secure-backups \
–period 30 \
–allow-protected-append-write true
Enable time-based lock:
az storage container legal-hold set \
–account-name mystorageaccount \
–container-name secure-backups \
–tags “WORM-Protection”

The policy prevents deletion or overwriting for the specified number of days.

Method B: PowerShell

📌 Use Cases: PowerShell is ideal for IT admins and MSPs managing Windows endpoints.

Open PowerShell as an administrator and execute this command:

Step 3: Upload backup data to the locked container

Once a user has configured an immutable container, they can now upload their data to the protected container. This is necessary to complete the backup process. To upload data, they can use Azure CLI or AzCopy.

Option A: Azure CLI

📌 Use Cases: Use Azure CLI for small-scale uploads and cross-platform environments.

az storage blob upload \
–account-name mystorageaccount \
–container-name secure-backups \
–name daily-backup-2025-07-01.bak \
–file “C:\Backups\2025-07-01.bak” \
–auth-mode login

Option B: AzCopy Tool

AzCopy is a command-line utility that can copy blobs or files to and from a storage account.

📌 Use Cases: AzCopy Tool is best for:

• Large-scale or high-speed data transfers to Azure Blob Storage
• Automated backup jobs, disaster recovery setups, or initial bulk uploads
• Uploading via SAS token instead of full Azure login

Run this command in AzCopy:

AzCopy.exe copy “C:\Backups” “https://mystorageaccount.blob.core.windows.net/secure-backups?<SAS>” –recursive

Things to look out for

Supplementary methods to enhance your backup storage strategy

Once you’ve set up an immutable backup storage, you can opt to enhance your backup storage strategy and security using the methods below:

How to verify and audit immutability settings

Verifying and auditing immutability settings are valuable for IT teams that need documentation to ensure backup data is immutable and properly retained. The methods below are also useful for detecting misconfigurations before they impact compliance.

To verify and audit immutability settings, users can choose between Azure CLI, PowerShell, or Azure Portal. Execute the appropriate commands based on your choice of tool:

Azure CLI

az storage container show \
–name secure-backups \
–account-name mystorageaccount \
–query properties.immutabilityPolicy

PowerShell

Get-AzStorageContainerImmutabilityPolicy -Context
$ctx -ContainerName “secure-backups”

Azure Portal

1. Go to Container > Access control (IAM)
2. Check the Immutability policy, retention date, and append status.

How to validate local backup with Registry Editor

Users can track endpoints that contain backups through registry modifications. To do so, open Registry Editor and follow these steps:

1. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Org\ImmutableBackup
2. Modify the following keys:
   • LastBackupDate (String) = “2025-07-01T22:00:00Z”
   • ContainerURI (String) = “https://mystorageaccount.blob.core.windows.net/secure-backups”

When used in custom scripts or reporting tools, these keys validate policy compliance per device.

How to enforce backup source protection with a group policy

If your backups are created on endpoints before being sent to Azure, then preventing of local tampering is crucial. Group policies prevent users from deleting, modifying, or tampering with backup files before immutability kicks in.

To enable backup source protection:

1. Open the Local Group Policy Editor.
2. Go to Computer Configuration > Administrative Templates > Windows Components > Windows Backup
3. Enable Turn off the ability to delete backup files.
4. Require the Volume Shadow Copy Service for backup.
5. Apply to all relevant endpoints to prevent accidental deletion before backup data is pushed to the immutable container.

How to use CMD and CLI for operational validation

Validate container access and file integrity:

dir \\mystorageaccount.file.core.windows.net\secure-backups

Check AzCopy access:

AzCopy.exe login
AzCopy.exe jobs list

Verify blob immutability policy (via REST):

curl -X GET https://<account>.blob.core.windows.net/<container>?restype=container&comp=immutabilitypolicy

Additional considerations when dealing with immutable backup storage

Data in immutable storage is critical and should be handled with care to prevent data loss. Here are additional considerations to keep in mind:

Should you use a legal hold or a time-based lock?

A legal hold prevents deletion or modification of backup data indefinitely, whereas a time-based lock prevents deletion or modification for a specified duration. The correct lock helps with stopping premature data deletion, storage bloat, and compliance violations.

Can you modify immutable backup storage?

Immutable containers cannot be renamed or deleted until all locks expire. Planning your retention periods and legal holds is crucial to avoid unnecessary storage costs and cluttered environments.

Can you upload backup files after lock enforcement?

Once a container is locked, users can no longer modify or delete blobs. Always upload your backup first, verify completion, and then commit immutability. Partial or interrupted uploads can become inaccessible or invalid with early lock enforcement.

Do I need GRS or RA-GRS for my immutable backup?

Immutable data is often crucial business information, which is why having a geo-redundant storage (GRS) or read-only GRS (RA-GRS) is highly beneficial. Both provide Azure storage replication options in case of a regional storage failure.

Troubleshooting common issues

Policy not applying

If time-based or legal hold policies are not applying as expected, ensure that version-level immutability is enabled for the appropriate storage account.

Blob upload fails

Blob uploads can fail for several reasons, including incorrect connection strings, invalid SAS tokens, and large file sizes. To resolve this, confirm user permissions and use the append blob where appropriate.

AzCopy errors

If you encounter AzCopy issues, check that container permissions match the blob type and the SAS token validity. You can also check Microsoft Feature’s guide for specific AzCopy issues.

Cannot delete the container

If you can’t delete a container, confirm whether an active time-based lock or legal hold is enabled. Users can’t delete or modify containers with a policy enabled.

NinjaOne services to protect your immutable backup storage

NinjaOne services support IT teams and MSPs with automating, auditing, and validating immutable storage workflows across large environments. Here are some ways NinjaOne can help:

Secure your backup files using immutable backup storage

Immutable storage protects your backup files from ransomware, internal threats, and data loss for a specific period. The three-step process of setting up an immutable backup storage is simple and flexible. IT administrators and MSPs can choose the best options for their organization with this guide.

Related topics:

• What is Cloud Storage?
• Top 10 Cloud Backup Solutions
• What Is Immutable Backup?
• True Stories of Devastating Data Loss (And Tips for Recovery)
• Data Protection Methods for IT & MSP Teams