Immutability and ransomware resistance

Backups have an awkward property: whatever writes them can usually also delete them. Ransomware knows this, and modern strains look for backups first. The defence is to make the storage itself refuse to forget - so that even a destination with full credentials cannot truly destroy what is already there.

What Nyx Backup supports today

Versioning-based immutability, on Backblaze B2.

With it enabled, the provider keeps prior versions of any object that is overwritten or deleted. A deletion becomes a marker rather than an erasure, and the previous version is still there to be recovered. A lifecycle rule prunes those retained versions after a period you set - 30 days by default.

Turn it on per endpoint in the backup set’s storage settings.

What it protects against, and what it does not

It protects against the destination’s own credentials being abused: ransomware on the machine, an attacker with your keys, or an honest mistake that deletes a bucket’s contents. In each case the objects can be recovered from their prior versions.

It is not a substitute for keeping more than one copy. Versioning lives inside one provider account - it survives deletion, not account closure, billing failure, or a provider outage. Nyx makes a second set to a different provider straightforward, and separate sets can share a destination safely, so the cost of a second copy is mostly storage.

Note also that versioning changes what deletion means for your housekeeping too: retention pruning and garbage collection will appear to delete packs while the provider retains them, so storage falls more slowly than the app reports until the version-prune window passes. That is the feature working, not a bug.

Other providers

Object Lock - the stronger, write-once form of this, where even the account owner cannot delete within a retention window - is not yet implemented. It is planned; this page will say so plainly when it ships, and until then no other provider is offered an immutability setting rather than one that quietly does nothing.

If you need write-once storage today, the practical route is to configure a lifecycle or Object Lock policy directly at your provider, on a bucket used only by Nyx. Nyx writes into a namespaced folder per machine and per set, so a bucket-level policy applies cleanly.

Related

• Parity protection guards against data being damaged rather than deleted.
• Scheduled integrity checks tell you whether what is stored is still readable.