Blob Storage: Configuring Immutable Backups with TrueNas and Azure — Managing Time-Based Retention

Question

Blob Storage: Configuring Immutable Backups with TrueNas and Azure — Managing Time-Based Retention

AnthonyLiwen-4936 20

I am attempting to configure Azure Blob Storage as the destination for SQL backup files written by TrueNAS Cloud Sync, with the goal of keeping these backups undeletable for 60 days. I tried using a time-based retention and that works for incremental SQL backups, but I'm facing issues where the copy process fails when copying full SQL backups. It fails because of the immutable time-based retention policy on the blobs

Allan Solomon Mejia 10,545 Reputation points

2026-10-20T15:19:05.11+00:00
Hi @AnthonyLiwen-4936

Thanks for sharing the details.

Based on your description, this looks like a possible conflict between Azure Blob Storage's time-based immutability policy and how TrueNAS Cloud Sync uploads your full SQL backup files.

Azure Blob Storage supports Write Once, Read Many (WORM) protection. Once a blob is protected by an applicable immutability policy, operations that modify or delete the protected data can be blocked until the retention period expires.

This could explain why your incremental backups complete successfully while the full backup transfers fail.

1. Check how TrueNAS Cloud Sync handles full backups

First, verify whether your full SQL backups use the same destination blob name during each backup cycle.

For example:

SQL-Full-Backup.bak - reused for every full backup.

SQL-Full-Backup-20261020.bak - a unique name for each backup.

If TrueNAS attempts to overwrite an existing immutable blob, Azure Storage may reject the operation.

Using a unique filename for each backup can avoid overwrite conflicts, provided the upload method itself is compatible with the immutability configuration.

2. Review the Azure Storage error

Please check the TrueNAS Cloud Sync task logs for the exact Azure Storage error returned when the full backup fails.

In particular, look for errors such as:

BlobImmutableDueToPolicy

BlobImmutableDueToLegalHold

HTTP 409 (Conflict)

These would help establish whether the failure is caused by an immutability restriction.

Also, check whether the transfer fails at the beginning, during upload, or when TrueNAS attempts to finalize or replace the destination blob.

3. Review your immutability configuration

Azure supports different immutability configurations, including version-level immutability.

With version-level immutability, new blob versions can be created while previously protected versions remain immutable, subject to the supported operations and policy configuration.

This may be worth evaluating if your backup workflow requires updates to existing blob names.

However, version-level immutability doesn't guarantee compatibility with every TrueNAS Cloud Sync upload operation.

Before changing your configuration, verify the exact storage operations TrueNAS performs and whether they are supported under the selected immutability policy.

4. Recommended approach for 60-day immutable backups

For your requirement, I recommend:

Configure SQL backups to generate uniquely named files.

Upload completed backup files, not files SQL Server is still writing.

Verify that TrueNAS Cloud Sync can upload new blobs without overwriting existing protected blobs.

Apply the required 60-day immutability protection using an Azure-supported policy configuration.

Validate the complete workflow with a test backup and restore before using it for production.

If you are using a locked immutability policy, remember that its retention period cannot simply be shortened or removed. Test the workflow carefully before locking the policy.

Could you confirm three things?

Are you using a container-level or version-level immutability policy?

Does TrueNAS Cloud Sync use COPY, SYNC, or MOVE, and do your full backups reuse the same filenames?

What is the exact error message in the TrueNAS Cloud Sync task log when a full backup fails?

With those details, we can determine whether the problem is an overwrite conflict, an unsupported upload operation, or another storage restriction. Hope this helps!

References:

Immutable storage for Azure Blob Storage

Configure time-based retention policies

Supported operations with immutable storage

Azure Blob Storage error codes

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.
Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-10-20T17:54:11.2133333+00:00
Hi @AnthonyLiwen-4936

As Allan Solomon Mejia requested could you confirm three things?

Are you using a container-level or version-level immutability policy?

Does TrueNAS Cloud Sync use COPY, SYNC, or MOVE, and do your full backups reuse the same filenames?

What is the exact error message in the TrueNAS Cloud Sync task log when a full backup fails?
AnthonyLiwen-4936 20 Reputation points

2026-10-21T12:25:23.0266667+00:00
From TrueNas, this is how their cloud sync task operates:

TrueNAS Cloud Sync uses rclone to transfer files to Azure Blob Storage. For files larger than 100 MiB, the Azure backend uses staged (chunked) uploads. It stages the data using Put Block operations and then finalizes the upload using Put Block List.

All backup data names are unique. We are using container-level immutability.

We have it working with SYNC, but it's recommended to use COPY. So we are trying to get it working with COPY

The error is "BlobImmutableDueToPolicy"

I'm not sure version-level immutability will work because these files do not have different versions. Once the file is uploaded, that's it. It does not edited anymore. It is a backup file that is rarely accessed.
Allan Solomon Mejia 10,545 Reputation points

2026-10-21T20:10:35.5433333+00:00

Please see my answer below.

2 answers

Your answer

Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-10-20T17:54:11.2133333+00:00

Hi @AnthonyLiwen-4936

As Allan Solomon Mejia requested could you confirm three things?

Are you using a container-level or version-level immutability policy?

Does TrueNAS Cloud Sync use COPY, SYNC, or MOVE, and do your full backups reuse the same filenames?

What is the exact error message in the TrueNAS Cloud Sync task log when a full backup fails?
AnthonyLiwen-4936 20 Reputation points

2026-10-21T12:25:23.0266667+00:00

From TrueNas, this is how their cloud sync task operates:

TrueNAS Cloud Sync uses rclone to transfer files to Azure Blob Storage. For files larger than 100 MiB, the Azure backend uses staged (chunked) uploads. It stages the data using Put Block operations and then finalizes the upload using Put Block List.

All backup data names are unique. We are using container-level immutability.

We have it working with SYNC, but it's recommended to use COPY. So we are trying to get it working with COPY

The error is "BlobImmutableDueToPolicy"

I'm not sure version-level immutability will work because these files do not have different versions. Once the file is uploaded, that's it. It does not edited anymore. It is a backup file that is rarely accessed.
Allan Solomon Mejia 10,545 Reputation points

2026-10-21T20:10:35.5433333+00:00

Please see my answer below.

Answer 1

Hi @AnthonyLiwen-4936

Thanks for clarifying how TrueNAS Cloud Sync handles the uploads. That additional information helps narrow down the issue considerably.

Since your backup filenames are unique and Azure returns BlobImmutableDueToPolicy, I agree that filename reuse is unlikely to be the cause.

The important detail is that TrueNAS uses rclone to perform chunked block-blob uploads for larger files, while your destination container has an active container-level time-based retention policy.

1. Why the full backups may fail

The container-level immutability allows new blobs to be created but prevents modification or overwriting of existing protected blobs.

For larger uploads, rclone may use Azure Blob Storage's block-upload operations, including Put Block and Put Block List.

The failure may occur when rclone attempts to finalize the block blob or perform a subsequent operation that Azure considers a modification of immutable content.

However, we should confirm the specific failed REST operation before concluding that Put Block List itself is unsupported for your scenario.

2. Will switching from SYNC to COPY resolve it?

Switching to COPY is worth testing because it avoids the destination-deletion behavior associated with synchronization.

However, COPY doesn't necessarily change the underlying block-upload mechanism used by rclone.

Therefore, it may prevent deletion-related errors but might not resolve BlobImmutableDueToPolicy during large-file uploads.

3. Recommended controlled test

I suggest testing with a separate, non-production container before changing the existing retention policy.

Create a test container with the same container-level immutability configuration.

Upload a small backup file using TrueNAS Cloud Sync COPY.

Upload a larger file that triggers chunked block-blob uploads.

Compare the results and capture the exact Azure Storage error for the failed operation.

If the smaller upload succeeds but the larger upload fails, that would provide useful evidence of a compatibility issue involving the upload sequence.

For further confirmation, Azure Storage diagnostic logs can identify the failed REST operation, response status, and storage error code.

4. Alternative approach for immutable SQL backups

Since your SQL backup files are completed before upload and don't require subsequent modification, you could also evaluate a two-stage workflow:

TrueNAS → Azure Blob staging container → Immutable backup container

The staging container would allow TrueNAS to complete its upload operations without an active immutability restriction.

After successful upload, a separate Azure-supported copy operation could place the completed backup into the immutable destination.

This would need to be tested with your storage account configuration, particularly the copy operation's behavior under container-level immutability.

It would also require validating that the destination backup is complete and readable before deleting the staging copy.

5. About protected append writes

The allowProtectedAppendWritesAll option for certain block-blob append scenarios.

However, this setting doesn't universally permit modifications to immutable block blobs, and it isn't a guaranteed solution for rclone's upload workflow.

I don't recommend enabling it without first confirming that it supports the failed operation.

References:

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. Thank you.

Answer 2

This behavior is consistent with TrueNAS attempting to replace, rename or delete a blob that is already protected by the time-based immutability policy.

Once the policy applies, Azure Blob Storage must reject operations that modify or delete protected content. A full backup commonly reuses the same destination filename, while incremental backups often create new files; that difference would explain why one workflow succeeds and the other fails.

Recommended approach:

Configure the SQL backup process to produce a unique, timestamped name for every full backup.
Ensure TrueNAS uploads only completed backup files rather than files still being written.
Configure Cloud Sync so it creates a new blob and does not overwrite, rename or delete the previous destination blob.
Check the TrueNAS log for the exact Azure response, especially HTTP 409 or errors such as BlobImmutableDueToPolicy.
Test both backup and restore before locking the policy.

If the workflow must reuse a logical filename, evaluate version-level immutability with blob versioning. A new version may be created while older protected versions remain immutable, but this works only if the operations issued by TrueNAS are supported under the selected policy. It will not make an overwrite/delete-style synchronization operation automatically compatible.

Another design is to upload to a staging container and copy each completed file—under a unique name—to the immutable destination. Note that the staging period is not WORM-protected, so this is appropriate only if that gap meets the recovery and compliance requirements.

Also remember that a locked retention policy cannot be shortened or removed. Test with an unlocked policy and representative full-backup files first.

References:

AnthonyLiwen-4936 20 Reputation points

2026-10-21T12:22:15.8266667+00:00

All SQL backups have unique names, it's the database name + time the backup was performed so name convention is not the issue.

TrueNas is only moving completed files

There is not an option for the cloud sync task to do any of this. It simply copies or syncs using rclone. It does not touch already completed blobs. The issue is getting full SQL backups to the blob storage

The exact error message is BlobImmutableDueToPolicy - on new Full SQL Backups