Tiered Storage

RustFS tiered storage moves objects from local storage to a configured remote backend. This page explains the supported targets and shows how to add and maintain a RustFS tier in the Console.

Tiering is asynchronous. RustFS keeps the object metadata locally, transfers the object data to the remote tier, and continues to serve S3 reads through the original bucket and object key.

Supported backends

The RustFS source defines warm-backend implementations for these target types:

Provider payloads and credential requirements differ. The complete workflow below uses the RustFS backend because the RustFS source includes an end-to-end hot-cluster-to-cold-cluster test for this path.

Before you begin

Prepare the following:

• A source RustFS deployment that stores the hot data.
• A separate target RustFS deployment and an existing target bucket. This example uses my-bucket on the target.
• Target credentials with permission to put, get, list, and delete objects in that bucket.
• Access to the source deployment's RustFS Console.

Use TLS for both deployments in production. Restrict the target credentials to the dedicated tier bucket and prefix.

Manage tiers with rc

Install and configure rc, then list the tiers registered on the source deployment:

rc bucket lifecycle tier list local

Add a RustFS tier with the same settings described in the Console workflow:

rc bucket lifecycle tier add rustfs COLDTIER local \
  --endpoint <target-rustfs-endpoint> \
  --access-key <your-access-key> \
  --secret-key <your-secret-key> \
  --bucket my-bucket \
  --region us-east-1

Inspect the tier configuration and available statistics:

rc bucket lifecycle tier info COLDTIER local

The remaining tier commands update credentials or remove a tier:

rc bucket lifecycle tier edit COLDTIER local \
  --access-key <your-access-key> \
  --secret-key <your-secret-key>
rc bucket lifecycle tier remove COLDTIER local

See Lifecycle Management to create transition rules, confirm transitions, and restore local copies. Run rc bucket lifecycle tier <command> --help to inspect provider-specific options before changing a tier.

Monitor tier activity

Use the tier statistics endpoint with a SigV4-signed request and admin:ListTier permission:

GET /rustfs/admin/v3/tier-stats?tier=COLDTIER HTTP/1.1
Host: <hot-rustfs-endpoint>

Monitor transition failures together with source-cluster capacity and target-side availability. A configured tier adds the target service and network path to the read path for objects that do not have a restored local copy.

Change or remove a tier

The Admin API exposes these mutation routes, all requiring admin:SetTier:

Before editing or removing a tier:

1. Disable lifecycle rules that reference the tier.
2. Confirm that no transition jobs are still using it.
3. Confirm that no source objects depend on data stored in its target bucket or prefix.
4. Back up the tier configuration and record the target location.

Normal tier mutations check backend usage and protect non-empty targets. Do not use a force option to bypass those checks unless you have independently proved that every transitioned object remains recoverable. Removing configuration for an active tier can make transitioned objects unreadable from the source cluster.

Admin API reference

The current RustFS source registers these tier routes:

All Admin API requests require SigV4 authentication. These routes are an administrative interface, not ordinary S3 bucket operations.

Next steps

Review lifecycle management and configure access policies for the administrators and service credentials used by tiered storage.