Using Object Versioning
Object versioning provides data protection against accidental or malicious object update, overwrite, or deletion.
Standard Oracle Cloud Infrastructure pricing applies to each bucket that is enabled for versioning. You are charged for all latest object versions and previous object versions (including deleted versions) stored in the bucket. Previous object versions are retained until you explicitly delete them.
Object versioning does increase your storage costs. Consider using Object Lifecycle Management to help you manage object versions automatically.
This topic describes Object Storage versioning and provides details on how to create and manage object versions.
About Object Versioning
Object versioning is enabled at the bucket level. Versioning directs Object Storage to automatically create an object version each time a new object is uploaded, an existing object is overwritten, or when an object is deleted. You can enable object versioning at bucket creation time or later.
A bucket that is versioning-enabled can have many versions of an object. There is always one latest version of the object and zero or more previous versions.
Understanding Object Versioning Status
Each Object Storage bucket has object versioning status of disabled, enabled, or suspended. By default, object versioning is disabled on a bucket. It's important to understand the behavior associated with each object versioning status.
Disabled
If object versioning is disabled on a bucket:
- Object versioning has never been enabled on the bucket.
- When you upload an object with the same name as an existing object, the object is overwritten and the overwritten object is not retained or recoverable.
- When you delete an object, the deletion is permanent and objects are not recoverable.
Enabled
If object versioning is enabled on a bucket:
-
When you upload an object with the same name as an existing object, the existing object becomes a previous version and the newly uploaded object becomes the latest version.
- Each uploaded object is assigned a unique version identifier. The identifier lets you direct Object Storage actions to a specific version.
- When you delete an object, Object Storage retains a version of the deleted object. For more information about object deletion, see Understanding Object Version Deletion.
- You cannot disable object versioning. You can, however, suspend versioning.
Suspended
If object versioning is suspended on a bucket:
- Upload and delete behavior is the same as a bucket that has versioning disabled.
- Object versions created before versioning suspension are retained, unless you take explicit action to delete them.
- You can re-enable object versioning at any time.
Understanding Object Version Deletion
No object is physically deleted from a bucket that has versioning enabled until you take explicit action to do so. When you delete an object without targeting a specific version, the latest object version becomes a previous object version and a special delete marker is created that marks the deletion point. A delete marker contains only minimal metadata. If you delete a folder, a delete marker is created for each object in the folder. You can simply delete the delete marker to make that deleted version become the latest object version.
When you upload an object with the same name as the delete marker, the uploaded object becomes the latest version of the object. The delete marker remains. There can be multiple delete markers for an object and you can recover any of the previous object versions.
Object version deletion is different. When you delete an object version, the version is permanently deleted. Permanent deletion also happens if you explicitly delete the latest version by version ID. All delete operations that target a specific object version ID permanently deletes the data.
Required IAM Policies
To use Oracle Cloud Infrastructure, you must be granted security access in a policy by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment to work in.
If you're new to policies, see Getting Started with Policies and Common Policies.
For administrators:
- You can create a policy that lets the specified IAM group manage Object Storage namespaces,
buckets, and their associated objects in all compartments in the tenancy. For
example, to let the IAM group StorageAdmins do
everything in the
tenancy:
Allow group StorageAdmins to manage object-family in tenancy - Alternatively, you can create policies that reduce the scope of access. For example,
you can create the policies to let the StorageAdmins group manage only buckets and
objects in a compartment called ObjectStore in the
tenancy:
Allow group StorageAdmins to manage buckets in compartment ObjectStore Allow group StorageAdmins to manage objects in compartment ObjectStore - If you create more restrictive policies that grant individual permissions,
BUCKET_UPDATE is required to enable versioning. Uploading objects, overwriting
existing objects, or deleting objects require the regular permissions necessary for
those operations. OBJECT_VERSION_DELETE is required to delete object versions. For
example, to allow a group called StorageSupport to manage Object Storage resources, but prevent that group
from permanently removing object
versions:
Allow group StorageSupport to manage object-family in tenancy where request.operation != 'DeleteObjectVersion'
For more information about other alternatives for writing policies, see Details for Object Storage, Archive Storage, and Data Transfer.
Scope and Constraints
- Versioning can be enabled on a bucket in the Standard (Object Storage) or Archive Storage tier.
- Restoring an archived object is an in-place operation and does not create an object version.
- You can rename the latest version of an object, but you cannot rename a previous object version. Renaming an object creates a new object.
Interaction Between Versioning and Other Object Storage Features
This section describes some key things you need to know about the interaction between object versioning and other Object Storage features.
Bucket Re-Encryption
Bucket re-encryption (using either Oracle or your own master encryption key) also re-encrypts any existing object versions.
Lifecycle Management
Lifecycle policies can archive the latest version or previous versions of an object. When Lifecycle policies delete the latest version of an object, that object becomes a previous version and a delete marker is created. When Lifecycle policies delete a previous version of an object, that deletion is permanent.
Copying Objects
If you copy the latest version of an object to a different bucket, only the object is copied. None of the object's previous versions are copied. You can copy a previous version of an object to another bucket, but that action creates either the latest version of a new object or a new object version in the destination bucket.
Replication
- Replication cannot replicate previous object versions.
- You cannot enable versioning on a replication destination bucket. A destination bucket is read-only.
Retention Rules
- You cannot add retention rules to a bucket that has versioning enabled.
- You cannot enable versioning on a bucket with active retention rules.
- You can add retention rules to bucket that has versioning suspended. However, you cannot resume versioning with active retention rules.
Troubleshooting Versioning
This topic provides troubleshooting solutions for issues you might encounter using versioning.
If enabling versioning fails, the most likely cause is missing or incomplete IAM permissions. Enabling versioning requires:
- User permissions that let you use the bucket and manage the objects in that bucket.
- Minimally, BUCKET_UPDATE permissions.
Review the existing policies that grant user permissions. For more information, see Required IAM Policies.
You can't recover a deleted bucket. You can cancel a deletion in progress. However, resources deleted before the cancellation can’t be recovered. You can't delete a bucket that contains any of the following resources:
-
Objects and object versions
-
Pre-authenticated requests
-
Replication policy
- Uncommitted multi-part uploads
When you delete an object in a version-enabled bucket, a previous version of that object is created. Select Show Deleted Objects to display the object versions that might prevent you from deleting the bucket.
If deleting a previous object version fails, the most likely cause is missing or incomplete IAM permissions. Object version deletion requires:
- User permissions that let you use the bucket and manage the objects in that bucket.
- Minimally, OBJECT_VERSION_DELETE permissions.