Immutable Backups: How They Work & Stop Ransomware

Immutable backups are copies of your data that cannot be modified, deleted, or encrypted by anyone—including ransomware—for a set period. You configure a backup system to store data in a write-once, read-many (WORM) format, then set a retention window (e.g., 7 or 30 days). During that window, even an admin with full credentials cannot alter or remove the backup. This stops ransomware dead because the malware’s core tactic—encrypting your files and then demanding payment for the key—fails when it cannot touch the recovery copies. This guide explains how immutability works, why it’s a critical defense, and how to implement it without falling into common traps.

What You’ll Need

• A backup solution that supports immutability: cloud object storage (e.g., AWS S3 Object Lock, Azure Blob immutability, Wasabi, Backblaze B2) or an on-premises appliance with WORM support (e.g., certain NAS or tape systems).
• Access to the backup software’s administrative console (e.g., Veeam, Commvault, Acronis, or the cloud provider’s dashboard).
• An understanding of your data retention requirements (compliance, business needs) to set the lock period.
• Optional: multi-factor authentication (MFA) for all accounts that can change backup settings—this is a best practice.

Step-by-Step

1. Choose an immutable storage target. Decide between cloud object lock or on-premises WORM. Cloud is simpler to manage; on-prem gives you full control but requires hardware that supports immutability. For most small-to-medium setups, cloud object lock is the easiest.
2. Enable object lock on the storage bucket. In your cloud provider, create a new bucket (or enable object lock on an existing one). For AWS S3, enable “Object Lock� when creating the bucket; for Azure, set “Immutability policy� on a blob container. This is a one-time setting—once enabled, you cannot disable it.
3. Set the retention mode and period. Choose between “Compliance� and “Governance� mode. Compliance mode means no one, not even the root admin, can delete or overwrite the object until the retention period expires. Governance mode allows a user with special permissions to bypass the lock (useful for corrections, but less secure). Set the retention period—e.g., 30 days, 90 days, or 1 year—based on how long you need to recover from a ransomware attack. Longer is safer but uses more storage.
4. Configure your backup software to write to the immutable target. In your backup tool (e.g., Veeam), add the cloud bucket as a repository. Ensure the software supports object lock and is set to “make backups immutable� or “apply object lock.� This usually requires entering the bucket’s access key and secret.
5. Set the immutability period in the backup job. In the backup job settings, specify the number of days to keep backups immutable. This should match or exceed the retention period you set on the bucket. The backup software will apply a lock to each backup file it writes.
6. Test the immutability. After the first backup, try to delete or modify a backup file. Use the cloud console or an API call to attempt deletion. You should get an error like “AccessDenied� or “Object is protected by WORM.� If you can delete it, your configuration is wrong—fix it before relying on it.
7. Restrict administrative access. Use separate accounts for backup administration and storage administration. Do not share credentials. Enable MFA on all accounts that can change retention settings. The goal is to make it so that even a compromised admin account cannot alter the lock.
8. Monitor and alert. Set up monitoring for your backup jobs and storage. Alerts should fire if a backup fails, if storage usage spikes (indicating encryption), or if someone attempts to modify or delete an immutable object. Many backup tools have built-in alerts; your cloud provider can also send events.
9. Document your recovery procedure. Write down how to restore from the immutable backup, including the exact steps to access the cloud console, locate the backup, and restore to your environment. Test the restore at least once a year. Ransomware recovery is stressful; having a tested runbook reduces errors.

Common Mistakes

• Using governance mode and giving out the “bypassâ€� permission. If you grant a user the ability to override governance locks, that user becomes a target. Ransomware that compromises that account can release the locks and delete backups. Compliance mode is safer.
• Setting a retention period that’s too short. If you set 7 days and your ransomware goes undetected for 2 weeks, the older backups become mutable and can be deleted. Use a period longer than your expected detection time—30 days is a common minimum.
• Not testing the immutability. Many people assume it works because they enabled it. But misconfigured permissions or a bug can leave backups writable. Always test by attempting to delete a backup file.
• Keeping the same credentials for backup and storage. If the backup software’s credentials are stolen, the attacker can delete backups if they have write access. Use separate credentials and least-privilege.
• Forgetting that the backup software itself can be compromised. If the backup server is on the same network as production, ransomware can encrypt the backup index or the software’s configuration. Keep the backup server isolated and use a separate management network.

Tips

• Use a dedicated backup user with permissions only to write and read the backup bucket—no delete, no overwrite. This is the principle of least privilege.
• Enable versioning on the bucket as an extra layer. Even if an object is overwritten, you can restore the previous version. Combine with object lock for defense in depth.
• Store your cloud credentials in a secure vault, not in plain text on the backup server. Use environment variables or a secrets manager.
• Consider an air-gapped backup (offline copy) as a last resort. Immutability is strong, but a truly offline backup (e.g., a tape stored in a safe) is immune to network attacks.
• Keep a copy of your backup encryption keys separate from the backup data. If ransomware encrypts your key store, you still have the key to decrypt backups.

Troubleshooting

• Backup fails with “access deniedâ€� when writing to the cloud. Check that the bucket’s object lock is enabled and that your credentials have write permission. Also ensure the backup software supports the cloud provider’s API—some providers require a specific endpoint.
• You cannot delete a backup even after the retention period has passed. This can happen if the backup software extends the lock or if the object has a legal hold. Check the bucket’s object lock settings; you may need to wait a bit longer or remove a legal hold.
• You accidentally set a very long retention period and need to recover space. You cannot shorten the retention period for existing objects. You must wait until it expires, or create a new bucket with a shorter period and migrate new backups there. Plan carefully.
• The backup software does not show the immutability option. Verify that you are using a recent version that supports object lock. Some tools require a plugin or a specific repository type. Consult the software’s documentation.
• After a ransomware attack, you cannot restore because the backup index is encrypted. If the backup software’s catalog is compromised, you can still restore by using the cloud provider’s API to list objects and manually restore files. This is tedious but works. To avoid this, keep the backup server isolated and use a separate index backup.

Frequently Asked Questions

• Can ransomware delete immutable backups? No, not if they are truly immutable. The whole point is that even a compromised admin account cannot delete or modify them during the retention window. However, if the ransomware compromises the storage provider itself (extremely rare), it could—but that’s outside your control.
• What is the difference between immutable and just read-only? Read-only means you cannot write, but an admin can change permissions and then write. Immutable means the data is locked at the storage level; no permission change can alter it until the retention period ends.
• How long should I keep immutable backups? At least 30 days, but longer (90 days) is better for ransomware recovery. The longer the period, the more storage cost. Balance with your risk tolerance and compliance needs.
• Does immutability protect against insider threats? Yes, if you use compliance mode. Even a rogue admin cannot delete backups. However, they could stop new backups from being created, so monitor for gaps.
• Can I use immutable backups on my own hardware? Yes, some NAS devices and tape systems support WORM. Check your hardware’s specs. Cloud is often easier, but on-prem gives you physical control.
• Is immutability the same as versioning? No. Versioning keeps multiple versions of a file, but an attacker with write access can delete old versions. Immutability prevents deletion entirely. They complement each other.

Related

• Joplin vs Google Keep: Offline-First Notes Explained
• Java to Python: A Practical Developer’s Guide
• Access Google Music from Desktop: Full Guide