How StorageGRID uses object versioning
Suggest changes
PDFs
You can set the versioning state of a bucket if you want to retain multiple versions of each object. Enabling versioning for a bucket can help protect against accidental deletion of objects and enables you to retrieve and restore earlier versions of an object.
The StorageGRID system implements versioning with support for most features, and with some limitations. StorageGRID supports up to 10,000 versions of each object.
Object versioning can be combined with StorageGRID information lifecycle management (ILM) or with S3 bucket lifecycle configuration. You must explicitly enable versioning for each bucket. When versioning is enabled for a bucket, each object added to the bucket is assigned a version ID, which is generated by the StorageGRID system.
Using MFA (multi-factor authentication) Delete is not supported.
|
Versioning can be enabled only on buckets created with StorageGRID version 10.3 or later. |
ILM and versioning
ILM policies are applied to each version of an object. An ILM scanning process continuously scans all objects and re-evaluates them against the current ILM policy. Any changes you make to ILM policies are applied to all previously ingested objects. This includes previously ingested versions if versioning is enabled. ILM scanning applies new ILM changes to previously ingested objects.
For S3 objects in versioning-enabled buckets, versioning support allows you to create ILM rules that use "Noncurrent time" as the Reference time (select Yes for the question, "Apply this rule to older object versions only?" in Step 1 of the Create an ILM rule wizard). When an object is updated, its previous versions become noncurrent. Using a "Noncurrent time" filter allows you to create policies that reduce the storage impact of previous versions of objects.
|
|
When you upload a new version of an object using a multipart upload operation, the noncurrent time for the original version of the object reflects when the multipart upload was created for the new version, not when the multipart upload was completed. In limited cases, the noncurrent time for the original version might be hours or days earlier than the time for the current version. |
How object versioning uses storage capacity in StorageGRID
The amount of storage space used for object versioning depends on the number of times you upload an object, your ILM policy rules, and the accumulation of noncurrent versions:
-
When versioning is enabled on a bucket, each version of an object is stored as a complete, separate object. If you upload a 1 GB file five times, StorageGRID stores 5 GB of raw data (5 x 1 GB) for that object.
-
The ILM policy is evaluated against each object version. For example, if you have a two-copy replication ILM rule, StorageGRID stores two replicated copies of each object version (current and noncurrent). When this ILM rule is applied to a bucket with 10 versions of a 1 GB object, 20 GB of physical storage is used.
-
Without an S3 bucket lifecycle policy or ILM rule targeting noncurrent versions, StorageGRID retains all old versions indefinitely and they continue to consume storage. This is the common cause of unexpected storage growth in versioned buckets.