Why Enabling Object Lock May Not Protect Your Old Backups
Object lock, the mechanism behind immutable backups in cloud object storage, is one of the most misunderstood security controls. Writing on Backblaze's blog, Kari Wilson, a senior product marketing manager at Backblaze, describes the gap between flipping an object lock switch and actually protecting data. The discussion draws on real issues that surface in technical conversations with IT administrators and system architects, after the documentation has been read but before the configuration is fully trusted.
One of the first confusions is the difference between immutability and encryption. 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, but they serve different functions. Treating them as interchangeable is how organisations end up with gaps in one direction or the other.
A related worry is that immutable data will be hard to restore from. It will not be. Immutable data remains 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 is the whole point.
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. However, 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 is clear: if you add object lock to a bucket with existing backups, do not assume those older files are now protected. New backups written after the change will be protected, but anything already sitting in the bucket requires individual lock settings to be applied manually.
There is also a common assumption that immutability is configured at the bucket level. For many backup applications, that is only half the picture. When 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. 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 and immutability period 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 are written. Once the 14 days expire, the object lock is released. The file is still there, governed by your retention policy, but it is no longer immutable. The two settings do not need to match. A typical setup runs a long retention policy with a shorter immutability window, covering the period when ransomware or a malicious actor is most likely to attempt deletion.
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 that if ransomware or an attack hits your environment, you will know within hours, maybe a couple of days. The immutability period does not 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. 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 is also a cost angle that is 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 does not charge for PUT requests, so lock writes and renewals are included with your storage. In practice, this means shorter immutability windows do not carry a cost penalty on B2, and there is no incentive to minimize lock renewals to reduce your API bill.
If you configure a 7-day immutability period in Veeam and then check the actual lock expiration dates in your bucket, do not 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 a buffer. The practical implication is storage capacity planning: if you budget for 7 days of immutable storage, you may actually need to account for closer to 14 days of data that cannot be deleted at any given time. Plan for that variance.
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 is 32 days old, you have 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 is no need for bucket-level deletion rules. If something is not 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 do not 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 is not on the enterprise list, check the documentation before assuming immutability will work.