Lifecycle of a backup
Every stored object goes through a clearly defined lifecycle. The controlling factors are the retention period and — if enabled — the immutable, write-protected storage (WORN).
Retention period
Backups are kept for a retention period chosen by the customer. You set it per project. By default it is 30 days (see Limits).
Immutable, write-protected storage (WORN)
For projects configured accordingly, the principle WORN — "Write Once, Read Never" applies: an object is written exactly once and is then immutable during the retention period. During this time it can neither be overwritten nor deleted (object lock) — not even by privileged roles. This reliably protects backups against accidental or malicious deletion, e.g. in the course of ransomware incidents.
"Read Never" refers to the normal transfer path: an upload or write token cannot read existing backups. This way even a compromised write token comes to nothing — it can neither download nor alter existing backups.
How backups are read after all
Restoring is done with a separate token with read permission (role Read, see Security). It is issued separately from the write tokens and used exclusively for restores. Writing and reading are thus strictly separated: reading backups is a deliberate, traceable exception — not the normal case.
The states
stored ──▶ expired ──▶ deleted ──▶ purge
| State | Meaning |
|---|---|
stored (stored) | The object is stored and protected during the retention period. |
expired (expired) | The retention period has been reached; the object is marked for removal. |
deleted (deleted) | The object is marked as deleted and removed from the active inventory. |
purged (purge) | The associated data is irrevocably removed from storage. |
What this means in practice
- As long as an object is
stored, it can be restored with a read token (role Read, see Security). - With WORN active, no early deletion is possible within the retention period — not even by privileged roles.
- After
purge, the data is irrevocably removed.