Migrate from Backblaze B2 to AIOZ Storage with rclone

AIOZ's documentation covers a Backblaze B2 migration path separately from its Amazon S3 one, and the difference is not just branding. B2 doesn't run through rclone's s3 remote type at all, it uses type = b2, which means this migration is a source-and-destination remote type change, not the same-type credential swap the S3 migration is. This guide covers the actual b2-to-s3 config, the sync command, and the one gotcha AIOZ's docs name for this path specifically.

TL;DR:

• Backblaze B2 configures as rclone's native b2 remote (account and key fields), while AIOZ Storage stays on the s3 remote with provider = Other, two different remote types in one sync command.
• The sync and check commands themselves work exactly like the S3 migration, just with a b2: source instead of s3:.
• The same "corrupted on transfer: sizes differ" error and --ignore-size fix apply here too.

Can You Migrate from Backblaze B2 to AIOZ Storage?

Yes, and AIOZ publishes a dedicated guide for it, separate from the Amazon S3 migration guide. The mechanism is still rclone, but the setup underneath is different: Backblaze B2 has its own native rclone backend (type = b2), while AIOZ Storage is reached through rclone's generic S3-compatible backend (type = s3, provider = Other). One sync command bridges both, but you're configuring two different kinds of remote, not two flavors of the same one.

Why This Migration Is Different From the S3 One

Migrating from Amazon S3 is a same-remote-type change: both sides use type = s3, and only the provider field and credentials flip. B2 breaks that pattern. Since Backblaze's own B2-vs-S3-compatible-API comparison confirms the Native API predates its later S3-compatible one and rclone built B2 support around that native API first, your source remote for this migration uses entirely different config fields, account and key, not access_key_id and secret_access_key. The destination side is identical to the S3 migration though, since AIOZ Storage itself is S3-compatible regardless of what you're migrating from.

What You Need Before You Start

Two credentials, from two different places. From Backblaze, you need either your Account ID or an Application Key ID, plus the matching Application Key, generated from the B2 dashboard. From AIOZ Storage, you need an access grant created with the "S3 Credentials" type, which returns an Access Key, Secret Key, and endpoint. How access grants work covers what that credential actually is, but this migration only needs the three values it hands back.

Setting Up Your rclone Config: B2 Source and AIOZ Storage Destination

Add a source remote for Backblaze B2:

[b2]
type = b2
account = <your-b2-account-or-keyid>
key = <your-b2-application-key>

Then add a destination remote for AIOZ Storage, identical to what the S3 migration guide uses:

[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>

Notice the AIOZ Storage block never changes based on where you're migrating from. It's the source block that shape-shifts to match whatever backend you're leaving, B2's native fields here, S3's access_key_id/secret_access_key/region fields if you were coming from Amazon instead. AIOZ's migration guide leaves the destination endpoint as a placeholder, but its SDK documentation confirms the real value: https://s3.aiozstorage.network.

Does Migrating Off Backblaze B2 Cost Anything on the B2 Side?

Possibly, and it's worth checking before you kick off a large sync. Backblaze B2's own pricing gives free egress up to 3x your average monthly stored data, then charges $0.01/GB beyond that. A one-time full-bucket migration reads your entire stored volume out through B2's egress path, so if you're already running close to that 3x ceiling from normal application traffic, the migration read can push you over it. For most accounts, a single full sync stays comfortably inside the free allowance, but it's a real cost some migration guides skip mentioning entirely. Check your current egress usage against that 3x threshold before syncing a bucket in the multi-terabyte range.

Running and Verifying the Migration

With both remotes configured, sync your bucket over:

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

Then check that everything landed intact before you touch your application's configuration:

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

Only cut your application over to AIOZ Storage's endpoint and credentials once that check comes back clean.

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

AIOZ's B2 migration guide flags the same error as the S3 guide: corrupted on transfer: sizes differ. The fix is identical too, rerun with --ignore-size appended:

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

AIOZ doesn't explain why this happens on either migration path, so treat it as a documented workaround rather than a diagnosed cause. And as with the S3 migration, this guide covers object data only. B2's own bucket lifecycle rules, file versioning, and application key permission scopes have no stated equivalent in AIOZ's documentation, verify those separately if your B2 setup depends on them before you cut over.

Frequently Asked Questions

Does migrating from Backblaze B2 to AIOZ Storage use the same rclone remote type as migrating from S3?
No. B2 uses rclone's native b2 remote type with account and key fields. AIOZ Storage's own side always uses the s3 remote type with provider = Other, regardless of what you're migrating from.

What rclone command migrates data from Backblaze B2 to AIOZ Storage?
rclone sync --progress b2:your-bucket aioz-storage:your-bucket, with a B2 source remote and an AIOZ Storage destination remote already configured.

What credentials does Backblaze B2 require for this migration?
Your Account ID or Application Key ID, plus the matching Application Key, both generated from the Backblaze B2 dashboard.

Does the "corrupted on transfer: sizes differ" error happen on this migration too?
Yes. It's the same error AIOZ's S3 migration guide names, and the same fix applies: rerun the sync with --ignore-size appended.

Do I need a different AIOZ Storage endpoint for a B2 migration versus an S3 migration?
No. The AIOZ Storage destination remote (https://s3.aiozstorage.network) is identical regardless of which service you're migrating from.

Does this migration guide cover B2's file versioning or lifecycle rules?
No. AIOZ's documentation covers object data transfer only. Verify B2 versioning, lifecycle rules, or application key scopes separately if your setup depends on them.

Does Backblaze B2 charge for the data transferred out during a migration?
Possibly. B2 gives free egress up to 3x your average monthly stored data, then $0.01/GB beyond that. A large one-time migration sync counts against that allowance, so check your current usage against the threshold first if your bucket is in the multi-terabyte range.

Related Reading

• Migrate from Amazon S3 to AIOZ Storage with rclone - the same-remote-type migration path this article's B2 config directly contrasts with.
• AIOZ Storage Access Control: Macaroons and Access Grants - how to generate the S3 Credentials access grant this migration needs.
• AIOZ Storage Glossary: Bucket, Passphrase, Macaroon - quick definitions for the access grant and bucket terms used throughout this guide.
• How AIOZ Storage Pricing Works - what your bill looks like after the migration, including how it compares to what Backblaze charges.

References

• AIOZ Storage Documentation: Migrate from Backblaze
• rclone Documentation: Backblaze B2
• Backblaze: What's the Diff? S3 Compatible API vs. B2 Native API