Immutable Backups: What They Are and Why They Matter

A Pensacola accounting firm was hit by ransomware on a Tuesday afternoon. The attacker had been in their network for three days, studying their backup system. When they triggered the encryption, the ransomware also deleted all backups — including the most recent clean backup from the night before.

The firm paid $85,000 to recover their data. They had backups. The backups were reachable by the attacker.

Immutable backups are designed to prevent this exact scenario.

What "Immutable" Actually Means

An immutable backup is a backup that cannot be deleted or modified for a set period of time — usually 30 to 90 days.

Even if:

• An attacker has your admin credentials
• A ransomware program runs with administrative privileges
• A disgruntled employee decides to destroy evidence
• You accidentally run a delete command

The immutable backup remains intact. It was written once, locked, and cannot be changed or removed until the lock expires.

How It Works Technically

Object locking (cloud):

Cloud storage services like AWS S3, Backblaze B2, and Azure Blob Storage support "object locking" or "immutability modes." When you upload a backup to an object-locked bucket:

• The service itself enforces a retention period
• Not even the account owner can delete the objects until the retention period expires
• This is enforced at the storage platform level, not the backup software level

WORM storage (local):

WORM = Write Once, Read Many. Hardware and software solutions that write data once and prevent any subsequent modification or deletion. Common in enterprise compliance storage.

Backup software immutability:

Enterprise backup platforms (Veeam, Rubrik, Cohesity) have built-in immutability features. They mark backups as immutable at the software level, preventing deletion through the normal backup management interface.

Why This Matters for Ransomware

Ransomware attacks increasingly target backups directly.

The modern ransomware playbook:

1. Gain access to the network (phishing, credential theft, exploit)
2. Move laterally, escalate privileges, study the environment
3. Identify backup systems and credentials
4. Delete or corrupt backups before triggering encryption
5. Trigger encryption on production systems
6. Demand ransom

With immutable backups:

Step 4 fails. The backups are locked. The attacker can delete everything else but can't touch the immutable backups. When encryption hits, you restore from immutable backups and skip the ransom payment.

The Gulf Coast Connection

The Pensacola accounting firm was a real case. The $85,000 included $40,000 in professional recovery fees (partial recovery — they lost about 20% of data permanently), $30,000 in downtime costs, and $15,000 in new security measures.

Immutable backups would have prevented this. Cost: $100-200/month additional for object-locked cloud storage.

What It Costs

AWS S3 Object Locking:

• Storage cost: Same as regular S3 — $0.023/GB/month (Standard tier)
• Object Locking: No additional cost, just a bucket setting
• Example: 500GB of immutable backups = ~$12/month

Backblaze B2 with Object Locking:

• Storage: $0.006/GB/month (cheapest cloud storage with native object locking)
• Example: 500GB of immutable backups = ~$3/month

Veeam Backup & Replication:

• Community Edition: Free (limited features)
• Essentials: ~$600/year for 6 sockets
• Enterprise: ~$4,000+/year
• Immutability features available in Essentials tier and above

Synology NAS with Write-Protected Snapshots:

• Synology Snapshot Replication: Included with most models
• Snapshots can be write-protected for immutability-like protection
• Requires compatible backup software (Active Backup Suite, Veeam, etc.)

Managed backup services with immutability:

• Datto SaaS Protection: $5-10/user/month
• Intronis (Barracuda): $3-8/user/month
• Typically adds $50-100/month to standard managed backup pricing

What Can Go Wrong

Immutability is configured for too short a period. 7-day immutability sounds secure. But ransomware can sit dormant in your network for weeks before triggering. If the immutability window closes before the attack, the attacker can still delete your backups.

Recommendation: Minimum 30-day immutability. 60-90 days is better.

You lose the encryption key. Some immutable backup systems use encryption. If the key is lost, the immutable backup is unrecoverable. This happens more than you'd think.

Recommendation: Document encryption key storage procedures. Test key recovery before you need it.

Immutability prevents legitimate restores. If you accidentally delete the original data and need to restore, but your backup software doesn't support partial restores from immutable storage, you might face complications.

Recommendation: Test restores from immutable backups before you need them. Not all backup software handles immutable storage gracefully.

The backup system itself is compromised, bypassing immutability. If an attacker compromises your backup software's admin account and the backup software can delete backups without going through the storage layer's immutability protection, you're back to square one.

Recommendation: Use storage-layer immutability (S3 Object Lock, B2 Object Lock) rather than software-layer immutability. Storage-layer protection can't be bypassed by compromised backup software.

Vendor Questions (Copy/Paste)

1. "Is your immutability enforced at the storage layer or the software layer? If I compromise the backup software, can I delete immutable backups?"
2. "What's your minimum and maximum immutability retention period? Can I set 90 days?"
3. "What happens if I need to restore from an immutable backup during an emergency? Is there a process for that?"
4. "Can I test immutability? Can I verify that backups are actually locked and cannot be deleted?"
5. "How do you handle encryption keys? If I lose my keys, what happens to my immutable backups?"
6. "What's the cost difference between mutable and immutable storage for my data size?"

Minimum Viable Implementation

1. Enable object locking on your cloud backup storage. If you use Backblaze B2, enable Object Lock when creating buckets. If you use AWS S3, enable Object Lock on your backup bucket. This is usually a checkbox in the bucket settings.

2. Set immutability to 30 days minimum. Configure your backup software to write to the object-locked bucket with a 30-day retention period.

3. Test that immutability is actually working. After your first immutable backup completes, try to delete it through the cloud storage console. It should fail. If it succeeds, your configuration is wrong.

4. Keep your backup software credentials separate from your storage credentials. The backup software should have access to write backups. The storage account (AWS, Backblaze) should have separate admin credentials that the backup software doesn't use. This prevents a compromised backup account from deleting immutable backups.

5. Document the recovery procedure for immutable backups. Immutable backups might require a different restore process. Document this before you need it.

When to Hire Help

• You've had a ransomware incident in the past 2 years
• You store sensitive data (healthcare records, financial data, legal documents)
• You have more than 10 employees and can't guarantee that all of them have good security practices
• Your backup solution is managed by the same person who manages your network (single point of failure)
• You're required to demonstrate backup immutability for compliance (some HIPAA and FINRA requirements)
• You don't understand the difference between storage-layer and software-layer immutability

For most Gulf Coast businesses, enabling object locking on Backblaze B2 or AWS S3 is straightforward and affordable. The hard part is verifying it's actually working and testing restores from immutable storage.

The accounting firm that paid $85,000 spent $150/month on immutable cloud backup for the next three years. They calculated it was cheaper than one more incident.