


Immutable backups give you a read-only copy of your primary datastore. Once enabled, every finished backup group on your primary datastore is synced automatically to a separate immutable datastore that you cannot write to directly.
Because the sync uses read-only credentials and runs with the remove-vanished flag disabled, backups deleted on your primary datastore are not removed from the immutable copy automatically. This is intentional: it is what keeps the immutable datastore useful as ransomware and mistake protection. If your primary datastore is compromised or a backup is deleted by accident, the copy on the immutable datastore stays intact.
The credentials issued for the immutable datastore cannot delete or prune backups. Pruning and deletion are only possible from the dashboard settings for that datastore, and any such change is subject to the change timeout above.
Prune schedules and retention settings on the immutable datastore are fully decoupled from your primary datastore. This lets you keep long-term retention on the immutable copy (for example, months of history) without carrying that same retention cost on your primary datastore.
Because remove-vanished is disabled, deleting a VM or backup group on your primary datastore does not remove it from the immutable datastore. If you have decommissioned a VM and want its backups removed from the immutable datastore as well, open the immutable backup settings of the datastore, click Schedule Deletion under Decommission VM and select the backup group. The backup group is removed once the change timeout has passed.
An immutable datastore can itself be geo-replicated. This gives you the same immutable, read-only datastore held in multiple locations at once, each location issuing its own separate read-only credentials. A compromise of the credentials for one location does not expose the copies held elsewhere, and you retain the same protection (change timeout, no delete/prune access) at every location.