What this buys you
No rehydration
Not one tiered file comes back to the cluster. The stubs never change.
No downtime
No change window. CloudPools keeps serving reads and writes the whole way.
No migration project
No bulk copy job to scope, schedule, run, and reconcile.
No lock-in
When it’s done, you can point CloudPools straight at Wasabi and drop OneBucket from the path entirely.
Part 1
Point an existing CloudPools account at OneBucket, with AWS S3 as the only backend.
Part 2
Add Wasabi alongside AWS, shift writes over, and retire the AWS backend.
Before you start
- Admin access to your OneBucket console and to the OneFS web UI.
- Access keys for each backend — the AWS keys CloudPools already uses, and a Wasabi Access Key ID and secret.
- An existing CloudPools cloud storage account. This guide edits one rather than creating it from scratch.
The screenshots show OneFS 9.15.0.0 on cluster
garage43. Menu paths are stable across recent 9.x releases, but exact labels can differ.Part 1: Put OneBucket in front of CloudPools
1
See where CloudPools points today
In OneFS, go to Storage → Storage Pools (SmartPools) and open the CloudPools tab. Select your cloud storage account and choose Edit.This is the starting point: an Amazon S3 account whose URI is a regional AWS endpoint, using the AWS User name (key) CloudPools has been writing with. Storage region is pinned to that region.Leave this dialog open — you come back to it in the last step of Part 1.
2
Collect your OneBucket credentials
In the OneBucket console, open Credentials. Note two things: the S3 endpoint shown at the top of the page — the URL CloudPools will use — and the Access Key ID of an active S3 credential.If you have no credentials yet, select Add Credentials and create an S3 pair first. See Set up your OneBucket for the full walkthrough.
3
Add an Endpoint for each backend
Open Endpoints. Each Endpoint is one object store OneBucket can reach.Add both providers now, even though only AWS will carry data at first — having Wasabi defined in advance makes Part 2 a policy change rather than a setup task. For each, select Create Endpoint and enter the name, URL, protocol, and bucket style, then that store’s own access keys.
4
Open the Policies page
A policy maps one OneBucket™ to one or more Peer Buckets at your Endpoints. Open Policies and select Create Policy.
5
Name the OneBucket™ (step 1 of 4)
Enter a bucket name, or 
* to match any Peer Bucket at your Endpoints. * is the right choice for CloudPools, which creates and names its own buckets.Optionally select Gzip or Brotli under Available Encoding, then select Next.6
Add your first Peer Bucket (step 2 of 4)
Select Add Peer Bucket. At least one Peer Bucket must be synchronous.
7
Configure AWS as a synchronous peer
Choose Synchronous so every write lands on AWS before the request returns, and leave Active on. Under Permissions, select Read, Write, and Delete — CloudPools needs all three.Set Endpoint to 
AWS, optionally enter a Region, and select the AWS Access Key ID. Set Peer Bucket to * to keep bucket names unchanged, then apply.8
Review the peer list
The peer appears as 
* on AWS, type sync, active. Select Next.9
Set the sync quorum (step 3 of 4)
Quorum is the minimum number of synchronous Peer Buckets with write access that must acknowledge a PUT for it to succeed. With one peer, the only value is 
1/1.Marking a peer Required forces every PUT to succeed on that specific peer, regardless of quorum. Select Next.10
Authorize the core keys (step 4 of 4)
Select the Core Access Key(s) allowed to use this OneBucket™ — including the key CloudPools will authenticate with. Select Create Policy.
11
Confirm the policy is live
The policy now shows one Core Key, a Quorum of 
1, and a single sync peer on AWS. Active policies apply automatically.12
Repoint the CloudPools account at OneBucket
Return to the OneFS Edit cloud storage account details dialog and change:
Leave Account ID and Telemetry reporting bucket as they are. Select Save; State Details confirms the account revalidated using AWS signature version 4 authentication.
CloudPools now writes through OneBucket to AWS. Nothing has changed from the cluster’s point of view — and this is the last time you edit anything in OneFS.
Part 2: Move the cloud tier to Wasabi
Everything from here happens in the OneBucket console. OneFS keeps pointing at the same endpoint with the same credentials throughout.1
Open the policy for editing
On Policies, select the gear icon on your policy to open Update Policy. The dialog exposes the same four stages as the wizard — OneBucket™, Peer Bucket, Sync Quorum, and Core Keys — as tabs you can revisit in any order.Open the Peer Bucket tab. Today it lists one 
sync peer on AWS.2
Add Wasabi as a second synchronous peer
Select Add another Peer Bucket. Choose Synchronous, leave Active on, and grant Read, Write, and Delete.Select Turn on opportunistic replication so OneBucket populates Wasabi as objects move through it, rather than requiring a separate bulk copy. Set Endpoint to 
WASABI and select the Wasabi Access Key ID you registered with that Endpoint.3
Set the peer bucket name and apply
Scroll to Peer Bucket and enter 
* to keep bucket names identical across providers. You can instead add a prefix or suffix — backup-*, for example — to rename buckets on this backend only.Select Apply.4
Demote AWS to read-only
Edit the AWS peer and clear Write and Delete, leaving Read selected. New objects now go only to Wasabi, while anything not yet replicated is still served from AWS.Replication and Compression grey out once the peer can no longer be written to, and so do its Endpoint and key fields.
5
Confirm both peers
The Peer Bucket tab now lists AWS in sequence 
1 and Wasabi in sequence2, both sync and both active. Sequence controls the order OneBucket tries peers — drag a row by its handle to change it.Select Apply changes.6
Verify the policy
The policy summary shows two active Drain AWS as its own step. Use flux, OneBucket’s asynchronous movement engine, to copy the AWS bucket to Wasabi in the background. OneBucket stays in front the whole time, so CloudPools keeps seeing one endpoint while the copy runs. Flux isn’t required, either: any copy tool works because OneBucket fronts both buckets regardless.Leave the policy in this state until Wasabi holds everything you need.
sync peers. Quorum is still1, so a write succeeds as soon as one synchronous peer with write access acknowledges it.Don’t wait for tiering activity to fill Wasabi. Opportunistic replication only copies objects as they move through OneBucket — and CloudPools touches cold data rarely. A recall is read-only, and even when a file changes, CloudPools writes new objects and leaves the old ones in place until garbage collection, which defaults to years.
7
Deactivate the AWS peer
When you’re ready to stop reading from AWS, switch its Active toggle off in the policy list. A banner appears: This policy includes disabled Peer Bucket(s).Deactivating is reversible — toggle it back on if reads start failing.
8
Confirm the peer is inactive
Reopen Update Policy and check the Peer Bucket tab. AWS shows as inactive, Wasabi as active.Run your validation here — list buckets, read a recalled file, write a new one — while the AWS peer can still be re-enabled.
9
Delete the AWS peer
Select the trash icon on the AWS row and confirm Delete.
10
Confirm Wasabi is the only peer
One 
sync peer remains on WASABI. Select Apply changes.11
Verify the finished policy
The policy shows a single active 
sync peer onWASABI, and the warning banner is gone.CloudPools is now tiering to Wasabi. The OneFS cloud storage account still points at the same OneBucket endpoint with the same credentials it had at the end of Part 1 — it was never touched during the migration.
Why not point CloudPools straight at Wasabi?
You can. Editing the same OneFS dialog to use a Wasabi URI and Wasabi keys is a valid way to change providers.
The timing is what makes the difference. Make this edit as your migration, and you pay the table above. Make it after OneBucket has already moved the data and it costs nothing — see No lock-in below.
What this bought you
Going through OneBucket, none of that happened.No rehydration
Not one tiered file came back to the cluster.
No downtime
No change window. CloudPools served reads and writes throughout.
No migration project
No copy job to scope, schedule, run, and reconcile.
s3.cluster8.onebucket.io was the target before the swap and after it. Which provider sits behind that name is a policy detail the cluster never sees — so there was nothing to recall and nothing to re-tier, and the cluster needed no spare capacity to absorb it.
No downtime. No cutover moment to schedule. AWS served reads while Wasabi filled; both served reads once Wasabi was warm, and Wasabi served them alone at the end. Every step in Part 2 was a toggle you could flip back, right up until you deleted the AWS peer.
No migration project. Opportunistic replication seeded Wasabi with everything CloudPools touched, and flux drained the cold remainder behind the bucket. The copy never involved the cluster or a maintenance calendar — the only judgment call was when Wasabi held enough for AWS to go.
No lock-in. OneBucket does not have to stay in the path. Because the policy used * as the Peer Bucket name and no encoding, the objects now in Wasabi carry the same bucket names and the same keys they had on AWS. So once Wasabi holds a complete copy, you open that OneFS dialog one final time, point it straight at Wasabi with your Wasabi keys, and CloudPools resolves its existing stubs against Wasabi directly. The edit that was expensive as a migration method costs nothing as a postscript.
Which is the part worth saying plainly: the thing that made the move safe is not something you are then stuck with. Keep OneBucket for what it does next — a third provider, a cache tier, spreading reads, the next move. Remove it if you would rather not have it in the data path. Either way the migration is done, and it was done without a recall.
Tested end to end: stubs written through OneBucket resolve correctly once the CloudPools account points straight at Wasabi. It relies on the objects being stored unchanged — keep the Peer Bucket as
* with no prefix or suffix, and leave policy encoding off.Data still has to cross from AWS to Wasabi, and you still pay egress once for the objects that move. The difference is that it happens behind the bucket, on its own schedule, while both providers keep serving — instead of through the cluster, in a window, with capacity set aside for it.
Next
Set up your OneBucket
Credentials, Endpoints, and policies from scratch.
Architecture
How placement, caching, and quorum work behind the bucket.