Backups & Storage

Immutable and air-gapped backups

3-2-1 says keep an offsite copy, but a copy your everyday credentials can delete is a copy ransomware can delete. Immutability means one tier can't be overwritten or erased within a retention window — even with stolen keys — which is what makes a clean recovery point survive an attack.

Who this is for

Home operators who already keep an offsite backup and now want at least one copy that ransomware (or a stolen credential) cannot delete or overwrite — via cloud object-lock, a restic append-only repository, or an offline rotated drive with separate credentials.

Outcome

One backup tier that is immutable within a retention window — an S3/B2/Wasabi Object Lock copy in Compliance mode, a restic rest-server --append-only repo, and/or an air-gapped drive — backed by separate credentials so a source-side compromise can't reach it, giving you a clean restore point that survives an attack (the immutable '1' of 3-2-1-1-0).

Required inputs

An existing offsite/cloud backup target (S3-compatible such as AWS S3, Backblaze B2, or Wasabi) or a restic rest-server you control, plus the everyday backup credentials.
A second, separate set of credentials for the immutable/offsite tier (not the same account/keys your source uses day to day).
For air-gap: at least one external drive you can rotate and physically disconnect between backup runs, on a calendar.
A decision on retention length per tier (how many days/weeks the immutable window should hold), informed by your change rate and storage budget.

GuideFollow in order

Step-by-step procedure

Decide which immutability mechanism(s) you'll use

Do: Pick at least one: cloud object-lock (S3 Object Lock / B2 / Wasabi), a restic rest-server run with --append-only, or an offline rotated drive. Mature setups combine an immutable cloud copy with an offline drive.

Expected result: You have a chosen mechanism per copy and know which credential set each uses.

If not: If every copy still uses your day-to-day credentials and stays online, none of them is immutable — pick a mechanism before continuing.

Enable object-lock correctly on the cloud bucket

Do: Create (or configure) the bucket with versioning and Object Lock enabled, set a default retention, and choose Compliance mode for true WORM. Use a legal hold only when you need an open-ended hold with no expiry.

Expected result: New objects carry a retention date and cannot be deleted/overwritten before it — confirmed by a test delete being refused.

If not: If you can still delete a locked object, you're likely in Governance mode with bypass permission, or Object Lock/versioning isn't actually enabled — re-check the bucket settings.

Stand up an append-only repository (if using restic)

Do: Run the restic rest-server with --append-only and point the backup client at it. The client adds snapshots but cannot prune or forget; pruning is a separate operation run by the trusted backup host.

Expected result: A backup runs and adds a snapshot; a client-side forget/prune is refused by the server.

If not: If the client can prune the repo, --append-only isn't in effect — fix the server flag before trusting it as immutable.

Separate the backup tier's credentials

Do: Give the immutable/offsite tier its own account/keys, stored apart from the source's credentials, so a compromise of the source can't authenticate to or delete the backup.

Expected result: The source system has no credential that can delete the immutable copy.

If not: If the same keys that run on the source can also delete the backup, a source compromise reaches the backup — split the credentials.

Establish the air-gap rotation (if using offline drives)

Do: Back up to the drive, then physically disconnect it and store it; rotate on a calendar so a current offline copy always exists. Label drives and track the last-good date.

Expected result: At any time there's a recent offline copy that nothing on the network can reach.

If not: If the drive stays plugged in 'for convenience', it isn't air-gapped — set a rotation reminder and disconnect it between runs.

Verify the immutable copy actually restores

Do: Periodically restore from the immutable/offline tier to a scratch location and confirm files open — immutability is worthless if the copy doesn't restore.

Expected result: A test restore from the immutable copy succeeds and sample files open.

If not: If the restore fails, treat the tier as not yet trustworthy and fix it before relying on it.

Commands and settings paths

Confirm object-lock is enforcing (test delete is refused)

Attempt to delete a locked object before its retention expires (e.g. aws s3api delete-object on a Compliance-locked key).

Where: From a machine with the backup tier's credentials

Expected: The delete is refused because the retention period hasn't expired.

Failure means: If the delete succeeds, you're in Governance with bypass, or Object Lock/versioning isn't enabled.

Safe next step: Re-enable versioning + Object Lock and set Compliance mode, then retest.

Confirm restic append-only blocks client pruning

restic forget --prune (run from the backup client against the --append-only server)

Where: From the backup client

Expected: The server refuses the prune/forget from the client.

Failure means: If it prunes, the rest-server isn't running with --append-only.

Safe next step: Restart rest-server with --append-only; prune only from the trusted host.

Test-restore from the immutable copy

Restore a few files from the immutable/offline tier to a scratch folder and open them.

Where: On a clean machine

Expected: Files restore and open correctly.

Failure means: A failed restore means the immutable copy isn't trustworthy yet.

Safe next step: Fix the backup/restore path before relying on the tier.

Evidence to record

Which copy is immutable and by what mechanism (object-lock mode, append-only, or offline), and its retention window.
The separate credential/account used for the immutable tier and where those keys are stored.
The result and date of a test delete being refused (proof of immutability) and of a test restore succeeding.
For air-gapped drives: the rotation schedule and the last-good offline backup date.

Common mistakes

Treating an offsite copy your everyday credentials can delete as 'immutable' — it isn't.
Using Governance mode (or a key with bypass permission) and assuming it's ransomware-proof.
Leaving the 'air-gapped' drive permanently plugged in, so it's reachable during an attack.
Never restoring from the immutable copy, so you discover at recovery time that it doesn't work.

Stop points

Stop before relying on a copy as immutable until a test delete is actually refused within its retention window.
Stop and reconsider retention length before choosing Compliance mode — you can't shorten it until it expires, even as root.

Last reviewed

2026-06-03

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

AWS: S3 Object Lock (Governance vs Compliance)Used for the two retention modes — Governance (admins with bypass can delete) vs Compliance (no one, including root, can delete before expiry) — plus retention period vs legal hold and the versioning prerequisite.Backblaze: B2 Object Lock documentationUsed for Backblaze B2 Object Lock — free with B2, supports Compliance/Governance/Legal Hold modes; the 2026 path to genuine immutability for home backups.Wasabi: S3 Object Lock (immutable storage)Used for Wasabi's S3-compatible Object Lock immutability with per-object/per-bucket retention.restic docs: Removing snapshots (forget) and append-onlyUsed for the GFS keep-* flags (--keep-daily/-weekly/-monthly/-yearly), keeping the most-recent-in-slot, and the append-only repo + --keep-within pruning caveat.

FAQ

Governance or Compliance mode for S3 Object Lock?

For ransomware resilience, Compliance — in Compliance mode no user, not even the root account, can delete or shorten retention before it expires, so a stolen admin key can't wipe it. The trade-off is that you can't undo a mistake (like an over-long retention) until it expires. Governance mode is recoverable by an admin, which also means it's defeatable by a compromised admin key. The bucket needs versioning and Object Lock enabled. See AWS S3 Object Lock.

How is restic 'append-only' different from just having a backup?

An ordinary backup repo accepts delete/prune commands from the client — so malware with your backup credentials can tell it to erase history. A restic rest-server run with --append-only accepts new data but refuses prune/forget from the client, so the backup host owns deletion. Pruning is then done as a separate trusted operation. It's the difference between 'I have a backup' and 'a compromised client can't destroy my backup'. New to the discipline? See a backup you've actually restored.

Is a NAS snapshot enough on its own?

A snapshot on the same pool protects against accidental delete and in-place encryption, but it lives on the box that got hit — and modern ransomware targets snapshots. Use immutable snapshots where your NAS supports them (a protection window even an admin can't shorten), and replicate or back up off the box to an immutable/offline tier. If you've been hit, work the ransomware recovery runbook.