Migrate from Amazon S3 to AIOZ Storage with rclone

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>

This remote needs no extra setting for AIOZ Storage's upload rules. With provider = Other, rclone uses path-style URLs by default (force_path_style), which AIOZ Storage needs because bucket subdomains don't resolve. From v1.72.0, rclone also leaves the AWS SDK's default upload checksums off unless you set use_data_integrity_protections = true (rclone S3 docs). If an upload still fails with MissingContentLength, check rclone version and keep that option unset (not tested against AIOZ Storage; endpoint behavior checked Oct 19, 2026).

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.

Related Reading

• AIOZ Storage Explained: S3-Compatible Decentralized Storage - what makes AIOZ Storage S3-compatible in the first place, and where that compatibility has limits.
• AIOZ Storage Access Control: Macaroons and Access Grants - how to generate the S3 Credentials access grant this migration needs.
• How AIOZ Storage Encryption Actually Works - what happens to your data's encryption once it lands in AIOZ Storage.
• How AIOZ Storage Pricing Works - what your bill actually looks like after the migration, with a worked cost example.
• AIOZ Storage vs AWS S3: The Full Pricing Comparison - the full cost case for making this migration, beyond the headline storage and egress numbers.
• Migrate from Backblaze B2 to AIOZ Storage with rclone - the other documented rclone migration path, using B2's native remote type instead of S3's.
• Automating Backups to AIOZ Storage with GitHub Actions - the same rclone remote config from this migration, wired into a recurring scheduled backup instead of a one-time move.
• Multi-Cloud Storage Disaster Recovery with AIOZ and S3 - keeping both remotes live and mirrored in both directions with rclone bisync, instead of a one-time migration.
• AIOZ Storage Developer Platform: SDKs, CLI, and Migrations - how this migration path fits alongside the SDKs, CLI, and other developer tooling on AIOZ Storage.

References

• AIOZ Storage Documentation: Migrate from Amazon S3
• rclone Documentation: Amazon S3
• rclone Documentation: Global Flags