Azure Blob Immutability + Kopia = make me stress

Dear all, hello!

We would like to use Kopia to perform third-party backup of some data out of our Datacenter to have backups on the second location, and as this second location we decided to use Azure Blob Storage in Cold mode. Please note we want to store things for at least 90 days, there is no need to delete earlier, but also to keep longer. I need to make sure data in Azure cannot be destroyed in case of something or ransomware, this is why I am here. For now I am confused :slight_smile:

After some tests Kopia appeared to be the most suitable solution over the rest and scripted around azcopy and we would like to deploy it ASAP. It does it’s job perfectly in the test environment for us.

The problem is, while I was successful in setting up repository on the normal “cold storage”, I don’t have confidence while I am doing it with immutability on the Azure side enabled. I did read the documentation under “ransomware protection”, but, I am afraid Kopia will be not able to perform maintenance, correctly delete items, and that unused blocks will remain after they exceed retention period and we will overpay for storage.

I would like to kindly ask you what to setup on Azure and what to setup at Kopia in order to be immutable and ensure everything works properly.

Let me outline what do I have currently.

My Azure counterpart created a new Storage Account with immutability policy on it and versioning on the container level (if I am not mistaken, I am an AWS guy :slight_smile: ). We want to avoid Kopia deleting stuff before 90 days not to receive the removal penalty from the cold storage. Also, I am afraid to wreck repository with the Azure lifecycling and immutability. Please note I understand that there is Kopia retention and Azure WROM and retention. :slight_smile:

Kopia runs like this:

kopia repository create azure
–container=
–storage-account=
–sas-token=
–retention-mode COMPLIANCE
–retention-period 90d
–enable-actions

kopia maintenance set --extend-object-locks true
kopia maintenance set --full-interval 89d

Kopia authenticates via SAS token.

The reason actually I decided to go on the forum is that on out last config I got this:
Repository created
Setting policy...
Setting policy for censor@censor:
- setting "number of annual backups to keep" to 3.
- setting "number of monthly backups to keep" to 24.
- setting "number of weekly backups to keep" to 4.
- setting "number of daily backups to keep" to 90.
- setting "number of hourly backups to keep" to 48.
- setting "number of latest backups to keep" to 10.
- setting compression algorithm to zstd
- setting before-snapshot-root (essential) action command to "powershell.exe" with arguments "-NonInteractive" "-ExecutionPolicy" "Bypass
" "-File" "X:\Censor\Censor\kopia-before.ps1" and timeout 5m0s
- setting after-snapshot-root (essential) action command to "powershell.exe" with arguments "-NonInteractive" "-ExecutionPolicy" "Bypass"
"-File" "X:\Censor\Censor\kopia-after.ps1" and timeout 5m0s
Issue deleting blob delete marker: DELETE ``https://censored.blob.core.windows.net/``Censor``/se7df0331cf27a43759b0ba478f245b53
-s9f42cb59b0f921bf140
--------------------------------------------------------------------------------
RESPONSE 403: 403 The specified operation is not allowed on version.
ERROR CODE: OperationNotAllowedOnAutomaticSnapshot
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8"?><Error><Code>OperationNotAllowedOnAutomaticSnapshot</Code><Message>The specified operation is not
allowed on version.
RequestId:6f12d290-301e-0027-53fc-d3ea53000000
Time:2026-04-24T15:09:18.1104380Z</Message></Error>
--------------------------------------------------------------------------------
System.Management.Automation.RemoteException
Running full maintenance...
GC found 0 unused contents (0 B)
GC found 0 unused contents that are too recent to delete (0 B)
GC found 0 in-use contents (0 B)
GC found 2 in-use system-contents (1.2 KB)
GC undeleted 0 contents (0 B)
Compacting an eligible uncompacted epoch...
Advancing epoch markers...
Attempting to compact a range of epoch indexes ...
Cleaning up unneeded epoch markers...
Cleaning up old index blobs which have already been compacted...
Cleaned up 0 logs.
Finished full maintenance.
Object Lock extension maintenance enabled.
Issue deleting blob delete marker: DELETE ``https://censor.blob.core.windows.net/censor/s2be7555d1049729d95a5eb031abc897a
-s07ccf068a8f6a448140
--------------------------------------------------------------------------------
RESPONSE 403: 403 The specified operation is not allowed on version.
ERROR CODE: OperationNotAllowedOnAutomaticSnapshot
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8"?><Error><Code>OperationNotAllowedOnAutomaticSnapshot</Code><Message>The specified operation is not
allowed on version.
RequestId:93979fac-301e-0005-20fc-d38465000000
Time:2026-04-24T15:09:19.2874550Z</Message></Error>
--------------------------------------------------------------------------------
System.Management.Automation.RemoteException
Interval for full maintenance set to 2136h0m0s.
Issue deleting blob delete marker: DELETE ``https://``censor``.blob.core.windows.net``/``censor``/sb06cacf5c260ab5487c7c67ef4e7c16f
-s865dc6797e694a87140
--------------------------------------------------------------------------------
RESPONSE 403: 403 The specified operation is not allowed on version.
ERROR CODE: OperationNotAllowedOnAutomaticSnapshot
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8"?><Error><Code>OperationNotAllowedOnAutomaticSnapshot</Code><Message>The specified operation is not
allowed on version.
RequestId:d1dc7e9f-501e-001e-0cfc-d3aaf7000000
Time:2026-04-24T15:09:20.0679336Z</Message></Error>
--------------------------------------------------------------------------------
System.Management.Automation.RemoteException
So, question:

  • do we do it right in general and should we ignore the errors since objects will be cleaned by lifecycle? Or is it unable to mark things for deletion and everything will go wrong with a time?
  • what must be used on Azure side and which rights it should have in order to work correctly?
  • what else do I need to do if we need to store for 90 days and then replace the stuff with the new backups?
  • or is it easier just not to use Azure immutability and lifecycle and just replicate the Blob Storage to the 2nd one in another account?

Why I stress the most is to test everything take time even if we use short test durations of 1-2 days.

Will greatly appreciate any input!
BR

And have you seen Azure mentioned there? AFAIK it is not supported - at least not yet.

Yes?

Ouuups. My wrong. You are 100% right. I should check it first. The last time I looked there it was not there:) Originally it was only AWS and B2. I see that now GCS and Azure are also supported.

Still the question how to setup it… I am currently waging to the option to use Kopia with a normal repo and do the object replication to the isolated one…