What is an immutable backup?
An immutable backup is a backup copy that cannot be overwritten, changed or deleted until a set retention date has passed. The storage enforces the rule, so a delete request fails even when it comes from the backup software or from an administrator with valid credentials, to the extent the retention mode in force allows.
Storage that refuses the delete request
Ransomware operators know that working backups let a victim decline to pay, so they go after them first, usually with a stolen administrator login. Through the backup console or the storage interface they delete restore points, shorten retention or wipe the repository using ordinary functions. Immutability takes that decision away from logins and hands it to the storage. Three mechanisms are common:
- Object storage with S3 Object Lock: each object version carries a retention mode and a retain-until date, and the storage rejects deletion before that date.
- Hardened Linux repositories: backup files carry an immutable file system attribute on a server with tightly restricted local accounts, as in the Veeam Hardened Repository.
- WORM and offline media: write-once tape, or tape ejected from the library, which nothing on the network can reach.
Governance, compliance and legal hold
| Setting | Who can remove the protection early | What it protects against |
|---|---|---|
| Governance mode | Any identity holding s3:BypassGovernanceRetention that sends x-amz-bypass-governance-retention:true | Mistakes, and software deleting data ahead of schedule |
| Compliance mode | Nobody, including the account root, until the retain-until date | Every account, for the length of the retention period |
| Legal hold | Any identity permitted to remove legal holds; the hold has no end date | Loss of specific data during an investigation or dispute |
Object Lock works only on a versioned bucket. In both modes retention runs out, and after the retain-until date an object can be deleted like any other, so immutability protects a backup for a window and never forever.
Lock periods measured against dwell time
Attackers often sit in a network for days or weeks before they encrypt anything. When they have been inside longer than the lock period, the restore points from before their arrival may already have expired, and what remains locked is a faithful copy of a compromised environment.
Backup chains stretch locks beyond the headline number. An incremental is usable only while the full it depends on survives, so with a weekly full and a 14-day lock, the full stays locked until the last incremental built on it expires, roughly 20 days in all. Backup software that supports Object Lock works out those dates, and the extra days appear on the capacity report.
Mistakes get locked too. Data written in compliance mode with an overlong retention occupies capacity until its date, with no early cleanup. Immutability also keeps whatever was written, including files ransomware had already encrypted before the job ran, so picking a clean restore point, often inside a clean room recovery, remains part of the work. For insurance questionnaires and audits, the word immutable on its own says little; the mode and the lock length are the answer.
ARTESCA and immutable backup
Both Object Lock modes are available on ARTESCA buckets, together with retention periods and legal holds, and per-bucket S3 Lifecycle rules remove data once its retention ends.
Scality ties a payment to compliance mode through the ARTESCA Cyber Guarantee. If data on ARTESCA is encrypted or deleted in an external cyberattack, Scality pays $100,000 once. The terms cover deployments with 50 TB or more licensed in production, on ARTESCA 4.1.3 or later and a supported release, operated under Scality's recommended security practices, with the affected data under Object Lock in compliance mode and the incident reported in writing within 48 hours. Governance-mode data does not qualify. Nor do four situations: exfiltration that leaves data unencrypted and undeleted, credentials compromised outside ARTESCA, shared credentials, and unauthorized acts by approved personnel.
Related terms
- S3 Object Lock: the S3 feature that applies retention modes and dates to object versions.
- WORM (write once, read many): storage that accepts data once and refuses later changes.
- Backup tampering: deliberate alteration or deletion of backup data or settings.
- Logical air gap: isolation of backup copies through access controls and immutability.
- Retention policy design: how long backups are kept and how lock periods are set.