Hello
Support Case: 07675579.
We came across a critical limitation while testing Veeam Backup for Microsoft 365 with immutable object storage.
We have not yet tested whether this also affects buckets used by Veeam Backup & Replication, but we assume it does.
In our test setup, we manually deleted a bucket used by Veeam.
The goal was to simulate a situation where an attacker gains administrative rights and then tries to delete or encrypt files, like in a ransomware attack.
What happened:
- The backup data was still present (protected by versioning and immutability)
- Veeam Software marked the repository as Invalid
- It is no longer possible to restore data via the Explorer
- Re-attaching the repository fails also
What Veeam support told us:
- The configuration/metadata files from Veeam are not protected by immutability
- If they are lost, the repository becomes unusable
- There is no way to restore access without help from Support or R&D
- This behavior is “by design” and considered unsupported
Why this is a major concern:
Even though the backup data is technically still there, it becomes inaccessible to the customer.
This creates a single point of failure — not in the data, but in a few unprotected files.
In a real-world scenario, this would mean:
- Delays in recovery during a ransomware attack (because we have to wait for a fix from the R&D)
- Dependency on support for disaster recovery (Veeam Support also mentioned the Storage Provider has to help first!?)
- Immutability that does not actually guarantee accessibility
We believe Veeam should urgently improve this behavior!
What is your view on this?
Best regards,
Sascha
Support Case: 07675579.
We came across a critical limitation while testing Veeam Backup for Microsoft 365 with immutable object storage.
We have not yet tested whether this also affects buckets used by Veeam Backup & Replication, but we assume it does.
In our test setup, we manually deleted a bucket used by Veeam.
The goal was to simulate a situation where an attacker gains administrative rights and then tries to delete or encrypt files, like in a ransomware attack.
What happened:
- The backup data was still present (protected by versioning and immutability)
- Veeam Software marked the repository as Invalid
- It is no longer possible to restore data via the Explorer
- Re-attaching the repository fails also
What Veeam support told us:
- The configuration/metadata files from Veeam are not protected by immutability
- If they are lost, the repository becomes unusable
- There is no way to restore access without help from Support or R&D
- This behavior is “by design” and considered unsupported
Why this is a major concern:
Even though the backup data is technically still there, it becomes inaccessible to the customer.
This creates a single point of failure — not in the data, but in a few unprotected files.
In a real-world scenario, this would mean:
- Delays in recovery during a ransomware attack (because we have to wait for a fix from the R&D)
- Dependency on support for disaster recovery (Veeam Support also mentioned the Storage Provider has to help first!?)
- Immutability that does not actually guarantee accessibility
We believe Veeam should urgently improve this behavior!
What is your view on this?
Best regards,
Sascha
Statistics: Posted by SaschaRTG152 — May 08, 2025 9:31 am
