Versioning allows you to keep multiple versions of the same object. Upon enabling Versioning for your bucket, each version of an object is considered a separate entity contributing to your storage space usage. Every version represents the full object, not just the differences from its predecessor. This aspect will be evident in your usage reports and will influence your usage-based billing.
Note: Versioning is supported for both contract-owned buckets and user-owned buckets. For more information, see Bucket Types.
Data Recovery: Versioning can be used as a backup solution for your data. If you accidentally overwrite or delete an object, you can restore it to a previous version.
Tracking Changes: Versioning can be used to track changes to your data over time. This can be useful for debugging purposes or auditing changes to your data.
Buckets can exist in one of three states:
Unversioned: Represents the default state. No versioning is applied to objects in a bucket.
Versioning - enabled: In this state, each object version is preserved.
Versioning - disabled: No new versions are created, but existing versions are retained.
Objects residing in your bucket before the activation of versioning possess a version ID of null. Once versioning is enabled, it cannot be disabled but can be suspended. During suspension:
New object versions are not created.
Existing object versions are retained.
You can resume Versioning anytime, with new versions being created henceforth.
Upon enabling Versioning for a bucket, every object version is assigned a unique, immutable Version ID, serving as a reliable reference for different object versions. New object versions are generated exclusively through PUT operations, with actions such as COP entailing a PUT operation, thus spawning a new version.
Notably, a new Version ID is allocated for each version, even if the object content remains unaltered. Objects residing in the bucket before the activation of versioning bear a Version ID of null.
When an object is deleted, all its versions persist in the bucket, while Object Storage introduces a delete marker, which is also assigned its Version ID.
You can manage Versioning using the DCD, API, and CLI.
1. In the DCD, go to Menu > Storage > IONOS Object Storage.
2. From the drop-down list in the Buckets tab, choose either Show user-owned buckets or Show contract-owned buckets depending on the bucket type you want to view.
3. From the Buckets list, choose the bucket to which you want to manage Versioning.
4. Click Bucket settings and go to the Versioning setting under the Data management section.
5. In the Versioning, click Enable to have object versions. On choosing the Disable option, it suspends object versioning but preserves existing object versions.
Result: Based on the selection, Versioning is either enabled or disabled for objects in the bucket.
1. In the DCD, go to Menu > Storage > IONOS Object Storage.
2. From the drop-down list in the Buckets tab, choose either to Show user-owned buckets or Show contract-owned buckets depending on the bucket type you want to view.
3. From the Buckets list, choose the bucket in which the desired object exists.
4. Click the object name within the bucket listing.
5. Navigate to the object's Versions tab by clicking the object name or clicking the three dots against the object name.
6. Copy Version IDs or download non-current versions of the object. You can also select and delete non-current object versions.
Result: Based on the selection, Version IDs and non-current object versions are successfully managed.
Use the API to configure and manage Versioning for a bucket.
Use the CLI to manage Versioning.
For a bucket with Object Lock enabled, Versioning is automatically enabled and cannot be suspended.
For Bucket Replication to function correctly, Versioning must be enabled.
IONOS Object Storage allows the setup of lifecycle rules for managing both current and non-current versions of objects in versioning-enabled buckets. For instance, you can automate the deletion of non-current object versions after a specified number of days after they transition to a non-current status. For more information, see Lifecycle.
