lifecycle transition rules and becomes eligible for tiering. MinIO scanner (which runs at one minute intervals, each time scanning one sixteenth of the namespace), picks up the object for tiering. The data is moved to the remote tier in entirety, leaving only the object metadata on MinIO.

The data on the backend is stored under the `bucket/prefix` specified in the tier configuration with a custom name derived from a randomly generated uuid - e.g. `0b/c4/0bc4fab7-2daf-4d2f-8e39-5c6c6fb7e2d3`....

of the previous version.

## Inline Data

Inline data is optional. If no inline data is present, it is encoded as 0 bytes.

| Entry               | Encoding                    | Content
| --------------------|-----------------------------|----------------------------------------
| xlMetaInlineDataVer | byte                        | version identifier

of `--older-than` needs to be used to trigger re-syncing of previously replicated objects. This command generates a ResetID which is a unique UUID saved to the remote target config along with the applicable date(defaults to time of initiating the reset). All objects created prior to this date are eligible for re-replication if existing object replication is enabled for the replication rule the object satisfies. At the time of completion of replication, `x-minio-internal-replication-reset-arn:<arn>`...

```
minio server /mnt/controller{1...4}/data{1...16}
```

Standalone erasure coded configuration with 16 sets, 16 drives per set, across mounts and controllers.

```
minio server /mnt{1...4}/controller{1...4}/data{1...16}
```

Distributed erasure coded configuration with 2 sets, 16 drives per set across hosts.

```