Lifecycle rule patterns

The following lifecycle rule patterns cover common retention and cleanup scenarios. For general lifecycle management concepts, see Object Lifecycle Management. For the full CLI reference, see mc ilm rule add.

Expire objects after N days (unversioned bucket)

Delete objects older than a specified number of days on a bucket without versioning:

mc ilm rule add ALIAS/BUCKET --expire-days 90

The scanner evaluates each object’s creation date and deletes it once the specified days have passed.

Expire objects after N days (versioned bucket)

On a versioned bucket, expiring the current version creates a delete marker. Use two rules to fully clean up:

Rule 1: expire the current version (creates a delete marker):

mc ilm rule add ALIAS/BUCKET --expire-days 1095

Rule 2: expire noncurrent versions and clean up orphan delete markers:

mc ilm rule add ALIAS/BUCKET --noncurrent-expire-days 1 --expire-delete-marker

Purge all versions of an object

Delete all versions (current, noncurrent, and delete markers) of an object after a specified number of days since the latest version was created:

mc ilm rule add ALIAS/BUCKET --purge-all-object-versions-days 1095 --purge-all-object-versions-delete-marker

This is a single rule that handles both live objects and objects with a delete marker as the latest version.

Use this pattern when:

• You do not need to retain noncurrent versions for any recovery window
• You want a single rule instead of managing separate expiration and noncurrent rules
• The bucket has versioning enabled for replication but applications only write one version per object

Clean up orphan delete markers

Remove delete markers that have no remaining noncurrent versions behind them:

mc ilm rule add ALIAS/BUCKET --expire-delete-marker

This is a standalone rule. It removes delete markers on the next lifecycle scanner pass after they become the only remaining version of an object.

Abort incomplete multipart uploads

MinIO AIStor removes incomplete multipart uploads automatically, so you do not need a lifecycle rule for them. Lifecycle rules do not act on multipart uploads.

The server removes an upload when it is older than api stale_uploads_expiry (default 24h). It checks for these uploads every api stale_uploads_cleanup_interval (default 6h).

Retain a fixed number of noncurrent versions

Keep only the N most recent noncurrent versions and expire older ones:

mc ilm rule add ALIAS/BUCKET --noncurrent-expire-days 30 --noncurrent-expire-newer 3

This retains the 3 most recent noncurrent versions and expires any noncurrent version older than 30 days.

Scope rules by prefix

Apply a lifecycle rule to a specific prefix within a bucket:

mc ilm rule add ALIAS/BUCKET --prefix "logs/" --expire-days 30

This affects only objects under the logs/ prefix. MinIO AIStor does not evaluate other objects in the bucket against this rule.

Choosing the right pattern

Monitoring lifecycle activity

Key metrics

Scanner status

Check the scanner’s current progress and throughput:

mc admin scanner status ALIAS

If ILM, DeleteAction throughput is lower than expected, reduce the scanner delay to increase scan speed:

mc admin config set ALIAS scanner delay=5.0

Return to the default after the backlog is cleared:

mc admin config set ALIAS scanner delay=10.0

Lifecycle with site replication

Site replication does not replicate lifecycle expiration rules unless you turn on ILM expiry rule replication. See Optional site replication settings. If you leave it off, apply the same rules on each site to keep expiration consistent.

Related pages

• Automatic Object Expiration for detailed expiration rule setup
• mc ilm rule add for the full CLI reference
• Metrics and Alerts for ILM monitoring