Considerations for compliant buckets and objects

Restrictions for using compliant buckets

• The global Compliance setting must be enabled before you can create a compliant bucket. If the global setting is disabled, you will not see the Compliance fields in the Tenant Manager, and errors will occur if you try to create a compliant bucket with the Tenant Management API or the S3 REST API.
• If you need to create compliant buckets, you must enable compliance and specify compliance settings when you create the bucket. After a bucket has been saved, compliance cannot be enabled or disabled for the bucket.
• When you specify the retention period for the bucket, you are specifying the minimum amount of time each object in that bucket must be retained (stored) within StorageGRID.
• You can edit bucket settings to increase the retention period, but you can never decrease this value.
• If your organization is notified of a pending legal action or regulatory investigation, you can preserve relevant information by placing a legal hold on the bucket. When a bucket is under a legal hold, no object in that bucket can be deleted even if its retention period has ended. As soon as the legal hold is lifted, objects in the bucket can be deleted when their retention periods end.
• You can add new objects to a compliant bucket at any time, regardless of the bucket's compliance settings.
• You can retrieve objects from a compliant bucket at any time, regardless of the bucket's compliance settings.
• Lifecycle configuration is not supported for compliant buckets.
• Object versioning is not supported for compliant buckets.

Restrictions for objects in compliant buckets

Each object that is saved in a compliant bucket goes through three stages:

1. Object ingest
   • When an object is ingested, the system generates metadata for the object that includes a unique object identifier (UUID) and the ingest date and time. The object inherits the compliance settings from the bucket.
   • After an object is ingested into a compliant bucket, its data, S3 user-defined metadata, or S3 object tags cannot be modified, even after the retention period expires.
   • StorageGRID maintains three copies of all object metadata at each site to provide redundancy and protect object metadata from loss. Metadata is stored independently of object data.
2. Retention period
   • The retention period for an object starts when the object is ingested into the bucket.
   • Each time the object is accessed or looked up, the compliance settings for the bucket are also looked up. The system uses the object's ingest time and date and the bucket's retention period setting to calculate when the object's retention period will expire.
   • During an object's retention period, multiple copies of the object are stored by StorageGRID. The exact number and type of copies and the storage locations are determined by rules in the active ILM policy.
     Note: Contact your StorageGRID administrator to understand how objects will be managed or to request a new ILM rule be added to manage the objects in a particular bucket.

   • During an object's retention period, or when legal hold is enabled for the bucket, you cannot delete the object.

3. Object deletion
   • When an object's retention period ends, all copies of the object can be deleted, unless legal hold is enabled for the bucket.
   • When an object’s retention period ends, a bucket-level compliance setting allows you to control how objects are deleted: by users when required or automatically by the system.
   • If the bucket setting is to delete objects automatically, all copies of the object are removed by the background ILM process in StorageGRID. When an object’s retention period ends, the object is scheduled for deletion. The actual amount of time needed to delete all object copies can vary, depending on the number of objects in the grid and how busy the grid processes are.