> ## Documentation Index
> Fetch the complete documentation index at: https://docs.onebucket.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Migrate CloudPools from AWS to Wasabi
> Put OneBucket in front of PowerScale CloudPools, then move the cloud tier from AWS S3 to Wasabi without reconfiguring the OneFS cluster.
PowerScale CloudPools tiers cold file data to a single cloud storage account. Changing providers normally means recalling everything you tiered back onto the cluster and sending it out again to the new target — a capacity problem, a change window, and a migration project in one.
Putting a OneBucket™ between OneFS and your object stores removes that constraint. CloudPools talks to one endpoint that never changes, and you add, drain, and retire backends behind it from the OneBucket console.
## What this buys you
Not one tiered file comes back to the cluster. The stubs never change.
No change window. CloudPools keeps serving reads and writes the whole way.
No bulk copy job to scope, schedule, run, and reconcile.
When it's done, you can point CloudPools straight at Wasabi and drop OneBucket from the path entirely.
Each of those is unpacked at the end. The steps come first.
This guide does both halves in order:
Point an existing CloudPools account at OneBucket, with AWS S3 as the only backend.
Add Wasabi alongside AWS, shift writes over, and retire the AWS backend.
## Before you start
* Admin access to your [OneBucket console](https://app.onebucket.io) 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
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.
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](/setup) for the full walkthrough.
Secret keys are shown only once, at creation. Copy or download the secret before you leave the page.
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.
A policy maps one OneBucket™ to one or more **Peer Buckets** at your Endpoints. Open **Policies** and select **Create Policy**.
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**.
The OneBucket™ name cannot be changed after the policy is created.
Select **Add Peer Bucket**. At least one Peer Bucket must be synchronous.
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.
The peer appears as `*` on `AWS`, type `sync`, active. Select **Next**.
**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**.
Select the **Core Access Key(s)** allowed to use this OneBucket™ — including the key CloudPools will authenticate with. Select **Create Policy**.
The policy now shows one Core Key, a Quorum of `1`, and a single `sync` peer on `AWS`. Active policies apply automatically.
Return to the OneFS **Edit cloud storage account details** dialog and change:
| Field | New value |
| -------------------- | -------------------------------------------------------------------------- |
| **Name or alias** | Something recognizable, such as `OneBucket` |
| **URI** | Your OneBucket S3 endpoint, for example `https://s3.cluster8.onebucket.io` |
| **User name (key)** | Your OneBucket Access Key ID |
| **Key (secret key)** | The matching secret |
| **Storage region** | `Default` — OneBucket resolves placement itself |
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.
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`.
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.
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**.
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.
The **Peer Bucket** tab now lists AWS in sequence `1` and Wasabi in sequence`2`, both `sync` and both active. Sequence controls the order OneBucket tries peers — drag a row by its handle to change it.
Select **Apply changes**.
The policy summary shows two active `sync` peers. **Quorum** is still`1`, 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.
**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.
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.
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.
Select the trash icon on the AWS row and confirm **Delete**.
Removing a Peer Bucket removes OneBucket's route to that backend. Objects that exist only on AWS become unreachable through this OneBucket™. Confirm Wasabi holds everything you need before you delete.
One `sync` peer remains on `WASABI`. Select **Apply changes**.
The policy shows a single active `sync` peer on`WASABI`, 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.
What it does not do is move your data. Every file CloudPools has already tiered is a stub on the cluster pointing at an object in the *old* account. Change that account's target, and the stubs still reference AWS.
To actually leave AWS, you have to bring the data home and send it out again: recall every tiered file back onto the cluster, then re-tier it to Wasabi. That is the expensive part, and it is expensive three ways at once.
| | Cost of a recall-and-re-tier |
| ------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Capacity** | The cluster needs enough free space to hold data it deliberately tiered off. |
| **Time and egress** | Every object crosses the wire twice — cloud to cluster, cluster to cloud — and you pay AWS egress on the way in. |
| **Risk** | It is a change window, with stubs being rewritten while users are reading through them. |
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.
Not one tiered file came back to the cluster.
No change window. CloudPools served reads and writes throughout.
No copy job to scope, schedule, run, and reconcile.
**No rehydration.** The stubs never changed, because the endpoint they point at never changed. `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.
**And it is repeatable.** Adding a third provider, splitting reads across two, or reversing this entire move is the same handful of policy edits. CloudPools keeps tiering exactly as designed — it just gains a cloud tier that is no longer a single fixed destination.
## Next
Credentials, Endpoints, and policies from scratch.
How placement, caching, and quorum work behind the bucket.