Immutable Backup: What It Protects and What It Does Not

What immutable means

Immutable storage follows a write-once, read-many model: once backup data is written, it cannot be modified or deleted until a set retention period ends. Common implementations include:

• Object storage with object lock, such as Amazon S3 Object Lock or immutable Azure Blob Storage, and S3-compatible storage that supports it.
• Hardened Linux backup repositories that use immutable file attributes.
• Backup appliances with retention locks.
• Offline media such as tape or removable disks stored disconnected from the network.

Check the mode carefully. Amazon S3 Object Lock, for example, has a governance mode that privileged users can override and a compliance mode that nobody, including the root user, can shorten during the retention period.

What it protects against

• Ransomware encrypting or deleting backup files.
• Accidental or malicious deletion by an administrator account.
• Attackers using stolen backup console credentials to purge restore points within the lock period.

What it does not protect against

• Data theft. Attackers can still read and copy backup data they can reach. Encrypt backups and restrict read access.
• Infected backups. If malware was present before it was detected, restore points may contain it.
• Short retention. If attackers were inside longer than your retention period, every locked copy may be compromised.
• Stopped jobs. Immutability protects data already written; attackers can disable future backups.
• Lost keys. Encrypted backups are useless if the only copy of the encryption key sits on a compromised system.
• Site loss. A locked copy in the same room as production burns or floods with it.
• Untested procedures. A backup that cannot be restored in time does not meet the recovery objective.

Design principles

• Follow the 3-2-1 rule: three copies of data, on two different types of media, with one copy off-site. Many teams add one immutable or offline copy and a goal of zero restore errors.
• Keep backup administration separate from everyday domain administrator accounts, and require MFA.
• Place backup infrastructure on its own network segment with restricted access.
• Store encryption keys separately from the backup system, with documented emergency access.
• Alert on failed jobs, deleted restore points and configuration changes.

Choosing retention periods

Retention has to balance three things: enough history to find a clean restore point after a late-discovered incident, storage cost, and legal obligations. Personal data inside backups is still personal data under the Data Privacy Act, so keep it only as long as your retention policy justifies. A common structure is short-term daily restore points under lock, plus weekly and monthly copies kept longer.

Protect the backup platform itself

• Patch backup software promptly; vulnerabilities in backup products have been exploited in real attacks.
• Limit administrative access to named people with dedicated accounts.
• Log administrative actions to a system the backup administrators cannot change.
• Keep an out-of-band way to reach the backup platform when the main network is down.

Recovery readiness

1. Prepare an isolated recovery environment where restored systems can be checked before reconnecting.
2. Document the restore order, starting with identity and core infrastructure.
3. Scan restore points for malware before bringing them online.
4. Restore critical systems on a regular schedule and time the process.
5. Compare restore times with recovery objectives and fix the gaps.

Questions to ask a backup vendor or provider

• Can anyone, including your staff and ours, delete locked backups before retention ends?
• How is immutability implemented, and how can we verify it?
• Where are copies stored, and who can access them?
• How are encryption keys managed and recovered?
• How quickly can our full data set be restored?
• How are we alerted when jobs stop running?