- 19 Apr 2024
- Print
- PDF
Immutability: Compliance and Object Locking
- Updated on 19 Apr 2024
- Print
- PDF
Immutability prevents the modification or deletion of objects, throughout the storage lifetime. You can define immutability in Wasabi using the Compliance or Object Locking feature. (Note that Compliance is also referenced as Bucket Locking.)
The Compliance and Object Locking immutability features are mutually exclusive. A bucket can have either Compliance or Object Locking, but not both features.
Enabling and Setting Immutability Features
Either feature, Compliance or Object Locking, must be first enabled and then set. Enabling either feature simply enables the ability to set the feature for the bucket. When the feature is enabled, you can set the feature with bucket settings.
- A bucket is created with Compliance enabled by default (unless you select the Object Locking feature while creating the bucket).
Instructions to set the Compliance feature are provided in Compliance. - You can enable Object Locking on a bucket only during bucket creation. You cannot enable object locking on an existing bucket. If you create a bucket with Object Locking enabled, Compliance is disabled automatically and cannot be used.
Instructions to enable the Object Locking feature are provided in Object Locking, and instructions to set the feature are provided in Bucket Settings: Object Locking.
Refer also to Checking for Immutability (below).
You may also want to refer to immutability for Third-Party Integrations (below).
Compliance and Object Locking Differences
Compliance | Object Locking |
---|---|
The Compliance feature is used to achieve bucket immutability, and prevents any change or deletion of objects (all objects) in a bucket, until a specified retention time passes. | Object Locking prohibits the modification or deletion of individual objects during a configured retention time. |
Compliance is a bucket-level setting. It takes effect across an ENTIRE bucket, across ALL the objects in that bucket. | Object locking is an object-level setting. It takes effect at an individual object level, not across the entire bucket.
|
Compliance works with versioning enabled or disabled. If versioning is disabled and you try to upload the same object again before the retention time elapses, you will get an Access Denied error through the Console. | Versioning must be enabled for object locking. |
Compliance can be enabled at any time, even after the bucket has been created. | Enabling the Object Locking feature MUST be done during bucket creation. You cannot enable object locking on existing buckets. |
When working with a third-party application, there is no third-party application dependency. The Compliance setting is controlled by the Wasabi bucket settings. | When working with a third-party application, the third-party application must support the use of object locking when uploading objects. When writing the individual objects, the parameters for object locking must be specified (such as for Veeam Object Lock Integration, Kasten K10, Commvault, Arq Backup, and MSP360). |
Checking for Immutability
Does the Bucket Have Compliance or Object Locking Set?
- In the Wasabi Console, navigate to your bucket.
- Click the gear icon for Settings:
When compliance is enabled, bucket settings will have a Compliance tab. For example:
When object locking is enabled, bucket settings will have an Object Locking tab. For example:
Checking Object Locking for a Specific Object
- Click the toggle to show versions.
- Click on the object name. For example:
The File Details indicate the Object Locking status. For example:
Third-Party Integrations
- Arcserve UDP
- Arcserve Cloud Console
- Arq Backup
- Atempo Miria
- Atempo Tina
- BackupAssist Classic
- BackupAssist ER
- Catalogic DPX
- Comet Enterprise Backup
- Commvault
- HornetSecurity VM Backup (Altaro VM Backup)
- HYCU
- Kasten K10
- Marquis Project Parking
- Marquis Workspace Backup
- MSP360
- Nakivo
- SEP sesam
- Veeam Object Lock Integration
- Veritas NetBackup
- Veritas Backup Exec
- Zerto