Veeam Azure Blob Immutable

Data is stored differently in object storage. Each block is an individual blob, so we just track the blobs required by newer restore points and manage the immutability updates and retention per blob as a result

The logic used in object storage is different from that of file storage or block storage.

You could find very detailled informations right here !

Short answer (high level)

• Forever Forward Incremental merging does NOT happen on immutable storage
• Azure Blob immutability prevents any merge or modification
• You end up with one full + daily incrementals, all kept as separate restore points until they age out
• Retention and immutability work together, not against each other

Let’s walk through your exact setup

Your settings

• Primary backup job
  • Mode: Forever Forward Incremental
  • Retention: 7 days
• Backup Copy job to Azure Blob
  • Immutability: 30 days

How Forever Forward Incremental normally works (non‑immutable)

On normal storage (non‑immutable):

1. Day 1 → Full backup
2. Day 2 → Incremental
3. Day 3 → Incremental
4. …
5. Day 8 → Oldest incremental is merged into the full
6. Result:
   • Full backup is rewritten daily
   • Only one full + N incrementals exist on disk

⚠️ This requires modifying the full backup file

What changes with immutable Azure Blob

Key rule of immutability

Nothing can be modified or deleted until the immutability period expires

Because of this:

• Veeam CANNOT merge incrementals into a full
• Forever Forward logic is suspended on immutable storage

What actually happens on Azure Blob

Timeline example (immutability = 30 days)

Important points

• Only one full is created initially
• No daily full merges occur
• Restore chain is Full + many incrementals
• Files are deleted only after 30 days, not earlier

What about the 7‑day retention on the primary job?

This causes confusion, so here’s the rule:

Backup Copy retention and immutability override the source job behavior

• The source job keeps 7 days
• The backup copy job builds its own independent restore chain
• Azure Blob keeps data for at least 30 days, regardless of source retention

So even if:

• Primary job deletes Day 8 locally
• Azure Blob copy keeps it until immutability expires

Do you get new full backups later?

Eventually, yes — but not because of merging

A new full will occur only when:

• The backup chain becomes too long OR
• Health check (if enabled) OR
• Synthetic/full policy in the Backup Copy job
• Or manual action

Until then:

• You have 1 full + lots of incrementals

This is expected and supported behavior

Restore performance impact

• Restores may need to process many incrementals
• Azure Blob restores are slower than block storage
• This is normal for immutable object storage

✅ Best practice: keep Azure Blob for compliance / ransomware recovery

✅ Use primary repo for fast operational restores

Final direct answer to your question

If immutable is set to 30 days, is there only one full for the first day and the rest incrementals for 29 days, with no merging?

✅ Yes — exactly

• One full backup
• Daily incrementals
• No merging
• No modification
• Data deleted only after 30 days

hi ​@Jason Orchard-ingram micro 

Thank for your great explanation. So if the immutable period set to 30 day this mean :

• Day 1 : Full Backup
• Day 2 : Incremental
• Day 3 to 30 : Incremental
• Day 31 : Full Backup deleted and change to incremental?