Back

Blog details

Migrate from Amazon S3 to AIOZ Storage with rclone

AIOZ Network
5 min readAugust 06, 2026
aioz-storage
Migrate from Amazon S3 to AIOZ Storage with rclone
Dark terminal window with lines of command-line output

Moving a bucket from Amazon S3 to AIOZ Storage does not require rewriting your application code. AIOZ's own documentation covers exactly one migration path, rclone, and it works because both S3 and AIOZ Storage sit behind the same type = s3 remote in rclone's config format. This article walks through the actual config diff, the sync command, and the one gotcha AIOZ's docs call out by name.

TL;DR:

  • Add two remotes to your rclone config: one for S3 with provider = AWS, one for AIOZ Storage with provider = Other.
  • Run rclone sync to copy the bucket over, then rclone check to verify it landed intact.
  • If you hit a "corrupted on transfer: sizes differ" error, add --ignore-size.

Can You Migrate from Amazon S3 to AIOZ Storage?

Yes, and AIOZ's documentation treats it as a config change rather than a data-format change. Both remotes use rclone's s3 type, meaning rclone talks to AIOZ Storage the same way it talks to any S3-compatible target, just with different credentials and a different endpoint. There is no proprietary AIOZ migration tool involved, and no aws s3 sync path documented either; rclone is the one path AIOZ actually walks through.

What You Need Before You Start

Two things. First, rclone itself, installed and configured with your existing Amazon S3 credentials (rclone config file will tell you where its config lives, typically ~/.config/rclone/rclone.conf). Second, an AIOZ Storage access grant with S3 credentials: generate one from your AIOZ Storage account (choose the "S3 Credentials" type when creating it), and you get back an Access Key, Secret Key, and endpoint to use as the destination. AIOZ Storage's access grant system covers what that credential actually is under the hood, but for this migration you mainly need the three values it hands back.

Setting Up Your rclone Config: Source and Destination Remotes

Open your rclone config file and add (or confirm you already have) a source remote for S3:

[s3]
type = s3
provider = AWS
access_key_id = <your-s3-access-key-id>
secret_access_key = <your-s3-secret-access-key-id>
region = <your-s3-region>
endpoint = <your-s3-endpoint>

Then add a destination remote for AIOZ Storage:

[aioz-storage]
type = s3
provider = Other
access_key_id = <your-aioz-storage-access-key-id>
secret_access_key = <your-aioz-storage-secret-access-key>
endpoint = <your-aioz-storage-endpoint>
Shipping containers stacked at a busy port, symbolizing large-scale transfer

Look closely at what actually changes between the two blocks. type = s3 stays identical on both, which is the whole reason this migration doesn't need a different tool. provider flips from AWS to Other. AIOZ's remote drops the region field entirely, since it isn't a region-partitioned service the way S3 is. Everything else is just different credentials and a different endpoint value, which you fill in from the access grant you generated in the previous step. AIOZ's migration guide leaves the endpoint as a placeholder, but its own SDK documentation confirms the actual value: https://s3.aiozstorage.network.

Running and Verifying the Migration

With both remotes configured, the sync itself is one command:

rclone sync --progress s3:your-bucket aioz-storage:your-bucket

That copies everything from your S3 bucket into the matching AIOZ Storage bucket, printing progress as it goes. Once it finishes, don't just trust that it worked: run a check pass to confirm the data landed intact.

rclone check --progress s3:your-bucket aioz-storage:your-bucket

Only after that check comes back clean should you update your application's endpoint, region, and credentials to point at AIOZ Storage instead of S3, since your code is talking to an S3-compatible API either way and doesn't need any other change.

The One Documented Gotcha (and How to Work Around It)

AIOZ's migration guide names exactly one error to watch for: corrupted on transfer: sizes differ. When that happens, rerun the sync with --ignore-size appended:

rclone sync --progress s3:your-bucket aioz-storage:your-bucket --ignore-size

AIOZ's documentation doesn't explain why file sizes might be reported differently between the two sides, but rclone's own flag reference at least clarifies what the workaround actually does: --ignore-size tells rclone to skip using size as a comparison signal and fall back to modification time or checksum instead, so treat it as a real change to how rclone verifies a match, not a blind bypass. What the guide does not cover at all: object ACLs, versioning, or lifecycle rules. If your S3 bucket leans on any of those, verify separately whether AIOZ Storage has an equivalent before you cut over, since the migration guide itself is silent on all three.

Frequently Asked Questions

Do I need to change my application code to migrate from S3 to AIOZ Storage?
No. Both are S3-compatible under rclone's s3 remote type, so the migration is a credentials and endpoint change, not a code or data-format change.

What rclone command migrates data from S3 to AIOZ Storage?
rclone sync --progress s3:your-bucket aioz-storage:your-bucket, using a source remote configured with provider = AWS and a destination remote configured with provider = Other.

What does the "corrupted on transfer: sizes differ" error mean during migration?
AIOZ's documentation doesn't explain the cause, only the fix: rerun the sync with the --ignore-size flag appended.

How do I verify my S3 to AIOZ Storage migration completed correctly?
Run rclone check --progress s3:your-bucket aioz-storage:your-bucket after the sync finishes, and don't cut your application over until that check passes clean.

What credentials do I need for the AIOZ Storage side of the migration?
An access grant generated with the "S3 Credentials" type, which returns an Access Key, Secret Key, and endpoint you plug into your rclone destination remote.

Does the migration guide cover S3 features like versioning or lifecycle rules?
No. AIOZ's migration documentation covers object data transfer only; it doesn't address ACLs, versioning, or lifecycle policies, so verify those separately if your bucket depends on them.

References

We only send updates when meaningful changes ship, and you can unsubscribe anytime

Related Content

blog thumbnail

What AI Agent Sandboxes on Modal and E2B Actually Store

AI agent sandboxes need external storage for files that outlive the sandbox. Real providers like Modal and E2B mount S3-compatible buckets, AIOZ Storage included.

aioz-storage
6 min readAugust 22, 2026
blog thumbnail

Offloading LangGraph Agent Checkpoints to AIOZ Storage

AIOZ storage can back LangGraph's S3 checkpoint offload tier, but not the whole backend. Here is the real DynamoDB-plus-S3 setup and its credential gap.

aioz-storage
6 min readAugust 21, 2026
blog thumbnail

AIOZ Storage as a Dataset and Model-Output Backend

AIOZ storage for AI datasets means S3-compatible buckets for training data and model outputs, no native versioning or lifecycle policies. Here is the honest scope.

aioz-storage
6 min readAugust 20, 2026
blog thumbnail

AIOZ Storage for AI and Data Pipelines: What's Real

AIOZ storage for AI workloads means S3-compatible object storage for datasets, checkpoints, and model outputs. No vector database. Here is what is real.

aioz-storage
6 min readAugust 19, 2026
blog thumbnail

Managing Team Access and Sub-Users on AIOZ Storage

Add AIOZ storage team members through the dashboard's 3-step wizard: name and password, per-bucket permissions, and a one-time credential download.

aioz-storage
6 min readAugust 18, 2026
blog thumbnail

Calling AIOZ Storage's S3 API Directly with Postman

No Postman collection to import. AIOZ Storage docs show building raw S3 requests by hand, authenticated with AWS Signature and your access grant keys.

aioz-storage
4 min readAugust 17, 2026