Requirements for S3 Object Lock

You must review the requirements for enabling the global S3 Object Lock setting, the requirements for creating compliant ILM rules and ILM policies, and the restrictions StorageGRID places on buckets and objects that use S3 Object Lock.

Requirements for using the global S3 Object Lock setting

Requirements for compliant ILM rules

If you want to enable the global S3 Object Lock setting, you must ensure that the default rule in your active ILM policy is compliant. A compliant rule satisfies the requirements of both buckets with S3 Object Lock enabled and any existing buckets that have legacy Compliance enabled:
  • It must create at least two replicated object copies or one erasure-coded copy.
  • These copies must exist on Storage Nodes for the entire duration of each line in the placement instructions.
  • Object copies cannot be saved in a Cloud Storage Pool.
  • Object copies cannot be saved on Archive Nodes.
  • At least one line of the placement instructions must start at day 0, using Ingest Time as the reference time.
  • At least one line of the placement instructions must be forever.
For example, this rule satisfies the requirements of buckets with S3 Object Lock enabled. It stores two replicated object copies from Ingest Time (day 0) to forever. The objects will be stored on Storage Nodes at two data centers.
Example Compliant Rule Two Copies Forever

Requirements for active and proposed ILM policies

When the global S3 Object Lock setting is enabled, active and proposed ILM policies can include both compliant and non-compliant rules.
  • The default rule in the active or any proposed ILM policy must be compliant.
  • Non-compliant rules only apply to objects in buckets that do not have S3 Object Lock enabled or that do not have the legacy Compliance feature enabled.
  • Compliant rules can apply to objects in any bucket; S3 Object Lock or legacy Compliance does not need to be enabled for the bucket.
A compliant ILM policy might include these three rules:
  1. A compliant rule that creates erasure-coded copies of the objects in a specific bucket with S3 Object Lock enabled. The EC copies are stored on Storage Nodes from day 0 to forever.
  2. A non-compliant rule that creates two replicated object copies on Storage Nodes for a year and then moves one object copy to Archive Nodes and stores that copy forever. This rule only applies to buckets that do not have S3 Object Lock or legacy Compliance enabled because it stores only one object copy forever and it uses Archive Nodes.
  3. A default, compliant rule that creates two replicated object copies on Storage Nodes from day 0 to forever. This rule applies to any object in any bucket that was not filtered out by the first two rules.

Requirements for buckets with S3 Object Lock enabled

Requirements for objects in buckets with S3 Object Lock enabled

Lifecycle of objects in buckets with S3 Object Lock enabled

Each object that is saved in a bucket with S3 Object Lock enabled goes through three stages:

  1. Object ingest
    • When adding an object version to a bucket with S3 Object Lock enabled, the S3 client application can optionally specify retention settings for the object (retain-until-date, legal hold, or both). StorageGRID then generates metadata for that object, which includes a unique object identifier (UUID) and the ingest date and time.
    • After an object version with retention settings is ingested, its data and S3 user-defined metadata cannot be modified.
    • StorageGRID stores the object metadata independently of the object data. It maintains three copies of all object metadata at each site.
  2. Object retention
    • Multiple copies of the object are stored by StorageGRID. The exact number and type of copies and the storage locations are determined by the compliant rules in the active ILM policy.
  3. Object deletion
    • An object can be deleted when its retain-until-date is reached.
    • An object that is under a legal hold cannot be deleted.