A ransomware-resistant backup cannot be easily altered or deleted by the same identities and systems that manage production. It also has sufficient history, independent monitoring, documented clean-room recovery, and proven restoration performance. “Immutable” storage helps, but a backup that cannot restore the business is not resilient.
Separate the control planes
Use distinct backup administration accounts, phishing-resistant authentication, dedicated management paths, and minimal standing privilege. Production administrators should not automatically be able to erase all recovery copies.
Keep offline or logically isolated copies and enforce retention that an ordinary compromised account cannot shorten. Protect encryption keys and catalogs; attackers may target them instead of backup files.
Preserve enough history
Attackers can remain hidden before encryption. If every retained copy contains persistence or corrupted data, the backup is complete but unsafe. Set retention from realistic detection time and business requirements, not only storage cost.
Test recovery, not backup jobs
Exercise identity systems, networking, applications, dependencies, and data integrity in a clean environment. Measure recovery time and acceptable data loss. Confirm who can declare a disaster, obtain credentials, communicate out of band, and prioritize systems.
Monitor destructive actions
Alert on disabled jobs, changed retention, deleted snapshots, new backup administrators, failed replication, mass restore or export, and unusual access to vaults. Send critical alerts outside the environment they protect.
The bottom line
Resilience comes from independence plus proof. Isolate backup authority, retain clean history, watch for sabotage, and demonstrate that people can restore essential services under incident conditions.
