Post Syndicated from Kari Wilson original https://www.backblaze.com/blog/what-it-teams-get-wrong-about-immutable-backups-and-object-lock/

If you’ve spent any time configuring immutable backups, you’ve probably hit at least one of these moments: you thought the data was protected, something went wrong, and the protection wasn’t quite what you expected. Object lock is one of the most misunderstood features in cloud storage, and the gap between “I enabled it” and “it’s actually working correctly” is where most mistakes live.

This is a collection of the real issues that come up in technical conversations with IT administrators and system architects, the kind of problems that surface after the documentation has been read but before the configuration is fully trusted.

The Difference Between Immutability and Encryption

These two features often get lumped together as “data security,” but they protect against completely different threats.

Encryption protects people from seeing your data. Object lock protects people from deleting it. An encrypted backup that an attacker can wipe is not a recovery option. An immutable backup that an attacker can read in plaintext is still a usable recovery point.

Both matter. They serve different functions. Treating them as interchangeable is how organizations end up with gaps in one direction or the other.

Immutable Does Not Mean Inaccessible

This one causes real hesitation when IT teams are evaluating immutability for production backup workflows. The concern is that locking data will make it unavailable for restores.

It won’t.

Immutable data is fully readable and downloadable throughout the immutability period. You can restore from it, access individual files, and upload new versions alongside the protected ones. The only thing object lock prevents is modification and deletion before the immutability period expires. That’s the whole point.

The Bucket Creation Problem

With Backblaze B2, object lock can be enabled at bucket creation or added to an existing bucket later. Once enabled, it cannot be turned off, so the change is permanent in that direction.

That said, enabling object lock on an existing bucket does not retroactively protect the files already in it. Only files uploaded or copied into the bucket after object lock is enabled are eligible to be locked. Files that were there before are unaffected.

The practical implication: if you’re adding object lock to a bucket with existing backups, don’t assume those older files are now protected. They aren’t. New backups written after the change will be, but anything already sitting in the bucket requires individual lock settings to be applied manually.

Who Actually Configures the Retention Period

There’s a common assumption that immutability is configured at the bucket level. For many backup applications, that’s only half the picture.

When you’re using Veeam or similar enterprise tools, the backup application manages object lock on a per-file basis. The bucket needs to have object lock enabled as a capability, but the application controls which files get locked and for how long. Think of the bucket setting as opening the door; the backup software decides what walks through it.

This means both sides need to be configured. Object lock enabled on the bucket, and immutability enabled within the backup application. One without the other does nothing.

Retention Period vs. Immutability Period

These are separate settings that operate independently.

A four-year retention policy means your backup application keeps the data for four years. A 14-day immutability period means files cannot be deleted or modified for 14 days after they’re written. Once the 14 days expire, the object lock is released. The file is still there, governed by your retention policy, but it’s no longer immutable.

The two settings don’t need to match. A typical setup runs a long retention policy with a shorter immutability window. The immutability window covers the period when ransomware or a malicious actor is most likely to attempt deletion. Once that window passes, normal retention rules apply.

How Long Should the Immutability Period Be?

The most common recommendation is 7 to 14 days, with 14 days being a reasonable default for most environments.

The logic is straightforward: if ransomware or an attack hits your environment, you’re going to know within hours, maybe a couple of days. The immutability period doesn’t need to cover months of potential compromise. It needs to cover the window between when an attack occurs and when you detect and respond to it.

For most organizations, 14 days is more than sufficient. Security teams that have tested their incident response workflows often find 7 days works fine. The point is aligning the period with your detection capability, not maximizing it arbitrarily.

There’s also a cost angle that’s easy to miss. Every time backup software writes or renews an object lock, it makes a PUT-class API call to update the retention metadata on that object. On AWS S3, those calls are billed as standard PUT requests at $0.005 per 1,000. In large environments with frequent backup jobs, those transaction fees accumulate. Backblaze B2 doesn’t charge for PUT requests, so lock writes and renewals are included with your storage. In practice, this means shorter immutability windows don’t carry a cost penalty on B2, and there’s no incentive to minimize lock renewals to reduce your API bill.

Veeam Quietly Extends Your Immutability Period

If you configure a 7-day immutability period in Veeam and then check the actual lock expiration dates in your bucket, don’t be surprised to see files locked through day 10, 14, or even 17. Veeam adds extra days to the immutability period beyond whatever you configure.

This is intentional behavior. Veeam is protecting against the scenario where a file is written late in a backup job, and a retention cleanup operation would otherwise try to delete it before the immutability period has fully elapsed. The extra days create buffer.

The practical implication is storage capacity planning. If you’re budgeting for 7 days of immutable storage, you may actually need to account for closer to 14 days of data that can’t be deleted at any given time. Plan for that variance.

Don’t Set Bucket Lifecycle Rules When Using Backup Software

Bucket-level lifecycle rules that automatically delete data based on age or other criteria will conflict with how backup applications manage their own data lifecycle.

When you let Veeam or another application handle your backup chain, that application tracks which files are active, which are expired, and when each should be removed. If you set a bucket lifecycle rule that deletes files after 30 days, and your backup application is still referencing a file that’s 32 days old, you’ve broken the chain.

The right approach is to leave bucket lifecycle rules alone and let the backup software handle all data management. If your backup application is working correctly, there’s no need for bucket-level deletion rules. If something isn’t working correctly, a lifecycle rule will compound the problem.

Not All Backup Software Supports Object Lock

Consumer sync tools and basic file backup applications generally don’t support immutable backups. When they encounter an immutable object, the write operation to delete or modify it will fail, which breaks the backup job.

Enterprise backup applications like Veeam and Commvault have native support for object lock. They know how to write immutability flags, manage retention periods, and handle the S3 API calls correctly.

If your current backup tool isn’t on the enterprise list, check the documentation before assuming immutability will work. A backup chain that fails silently because of incompatible object lock handling isn’t protecting anything.

Can You Change the Immutability Period After Setting It?

You can extend it. You cannot shorten it.

Once an object is locked with a specific expiration date, that date can only move forward. This is a deliberate design constraint: the whole value of immutability is that it can’t be weakened retroactively. If a compromised account or a bad actor could shorten or remove the lock, the protection would be meaningless.

The same principle applies to governance mode versus compliance mode configurations. Compliance mode makes data deletion impossible even for account administrators during the retention period. Governance mode allows certain privileged users to modify the lock. For serious ransomware protection, compliance mode is generally the stronger choice.

What Happens If Someone Deletes the Account?

This is the limit of what object lock protects against, and it’s worth understanding clearly.

Object lock prevents any individual from deleting immutable objects within your account. Even an administrator with full permissions cannot delete a locked object before its retention period expires.

However, if someone with account-level access deletes the entire account, that protection doesn’t save the data. This applies to every cloud storage provider, not just Backblaze. It’s not a gap in object lock, it’s a different attack surface entirely.

The mitigation here is account security: two-factor authentication, limited administrative privileges, and monitoring for unusual account activity. Object lock and account security work together. Neither one makes the other redundant.

Does Immutability Cost Extra?

With Backblaze B2, no. Immutability is included as part of the standard storage subscription.

This is worth noting because some storage providers charge separately for object lock API calls, including the PUT requests that renew or write lock metadata. Those transaction fees can add up significantly in environments with high file counts or frequent lock renewals. With B2, you pay for the storage you use, including any additional storage consumed by data that can’t be deleted during its immutability period. The feature itself has no surcharge.

Versioning and Storage Costs

If you enable versioning alongside immutability, all versions of a file count toward your storage usage, not just the current one. If a file has been modified 50 times and you’re storing 50 versions, you’re paying for all 50 regardless of how many of them are currently immutable.

This is consistent across cloud storage providers and is the tradeoff for having granular recovery options. The right versioning configuration depends on your recovery objectives and your budget. Keeping every version indefinitely is rarely necessary. Most backup applications give you control over how many versions to retain, and that setting directly affects your storage costs.

What to Do Before You Deploy

A few things worth confirming before putting object lock into production:

• First, verify that your backup application has native object lock support and that you’ve enabled immutability within the application settings, not just at the bucket level.
• Second, create your bucket with object lock enabled even if you’re not planning to use it on day one. You can’t go back and enable it later.
• Third, skip bucket lifecycle rules if your backup software is managing the data lifecycle. Let the application do its job.
• Fourth, account for Veeam’s extra days when planning storage capacity. The actual locked window will be longer than what you configure.
• Fifth, review your immutability period in the context of your incident detection capability. A 30-day immutability window isn’t more secure than a 14-day window if your security team can detect an incident within 48 hours.

Object lock is one of the more reliable tools available for protecting backup data against ransomware. It does what it claims. The configurations above are where implementations go wrong, and most of them are easy to get right once you know where to look.

The post What IT Teams Get Wrong About Immutable Backups and Object Lock appeared first on Backblaze Blog | Cloud Storage & Cloud Backup