Migration cookbook: from AWS, Azure, Backblaze, Wasabi and Infomaniak

A reference for moving existing object storage to chili with rclone. For each source provider you get a short, correct rclone recipe; the pattern is always the same. Configure a source remote and the chili remote, copy with rclone copy --checksum, then verify with rclone check.

Prerequisites

• rclone 1.60 or newer (rclone version)
• chili access keys (access key and secret) and a target bucket, or permission to create one
• read access on the source (list and download) and write access on the chili bucket
• the source endpoint or region details from the source provider’s console

1. Configure the chili remote

This is the migration target for every source below. In ~/.config/rclone/rclone.conf:

[chili]
type = s3
provider = Other
access_key_id = AKIA...
secret_access_key = ...
endpoint = https://<ENDPOINT>

chili uses the generic S3 provider (provider = Other). The region line can be left out; if your portal assigns a location constraint, set it as documented there rather than guessing. Test the connection:

rclone lsd chili:

2. Overview: source backends at a glance

Each row is detailed below. After configuring a source remote, the copy and verify steps in sections 9 and 10 are identical for all of them.

3. AWS S3

Per the rclone Amazon S3 documentation, AWS uses provider = AWS, requires a region, and leaves endpoint blank so the standard per-region endpoint is used.

[aws]
type = s3
provider = AWS
access_key_id = <KEY>
secret_access_key = <SECRET>
region = eu-central-1
endpoint =

rclone copy aws:<bucket> chili:<bucket> --transfers 8 --checkers 16 --checksum --progress

Set region to the bucket’s actual region.

4. Azure Blob

The rclone Azure Blob documentation uses type = azureblob. Authenticate with account plus shared key, or alternatively with a SAS URL or a connection string:

[azure]
type = azureblob
account = <STORAGE_ACCOUNT>
key = <SHARED_KEY>
# alternative: sas_url = <SAS-URL>
# alternative: connection_string = <...>

rclone copy azure:<container> chili:<bucket> --transfers 8 --checksum --progress

Two Azure specifics from the same documentation: azureblob does not support rclone about, so it cannot report free space; plan capacity from the source side instead. Archive-tier blobs must be deleted before they can be overwritten unless you pass --azureblob-archive-tier-delete, and empty directories need --azureblob-directory-markers.

5. Backblaze B2

B2 offers two paths. Variant A uses rclone’s native B2 backend, documented in the rclone Backblaze B2 guide:

[b2]
type = b2
account = <applicationKeyId>
key = <applicationKey>

Use the applicationKeyId as account, not the master account ID; otherwise B2 returns 401 errors, as the rclone documentation notes.

Variant B uses the S3-compatible API. B2 exposes S3 alongside its native API, and per Backblaze’s rclone documentation the S3-compatible API needs a dedicated application key; the master application key is not S3-compatible.

[b2s3]
type = s3
provider = Other
access_key_id = <keyID>
secret_access_key = <appKey>
endpoint = <regional S3 endpoint from the B2 console>

Read the exact regional S3 endpoint from the bucket detail (“Endpoint”) in the B2 console rather than hard-coding it; please verify the regional endpoint scheme there.

rclone copy b2:<bucket> chili:<bucket> --transfers 8 --checksum --progress

6. Wasabi

Per the rclone Amazon S3 documentation, Wasabi uses provider = Wasabi with the same key and secret as AWS, and the regional endpoint set explicitly as a hostname. region can be left blank for this S3 clone.

[wasabi]
type = s3
provider = Wasabi
access_key_id = <KEY>
secret_access_key = <SECRET>
endpoint = s3.eu-central-1.wasabisys.com
region =

Use the endpoint hostname that matches your bucket’s region. s3.wasabisys.com is the global (us-east-1) endpoint; EU buckets need an EU endpoint such as s3.eu-central-1.wasabisys.com.

rclone copy wasabi:<bucket> chili:<bucket> --transfers 8 --checksum --progress

7. Infomaniak Swiss Backup (Swift)

Infomaniak Swiss Backup is reached over Swift. Per the Infomaniak rclone guide for Swiss Backup, use type = swift:

[infomaniak]
type = swift
user = SBI-XXXXXX
key = <password>
auth = https://swiss-backup02.infomaniak.com/identity/v3
domain = default
tenant = sb_project_SBI-XXXXXX
tenant_domain = default
region = RegionOne

The cluster number in the auth URL (swiss-backupNN) varies per account; read it from the Infomaniak Manager under “Cloud storage information”. Devices created before October 2020 use auth = https://swiss-backup.infomaniak.com/identity/v3.

rclone copy infomaniak:<container> chili:<bucket> --transfers 8 --checksum --progress

Note that Swiss Backup credentials work over Swift, not over an S3 API. For S3 access you would use Infomaniak Public Cloud instead, with separate credentials (next section).

8. Infomaniak Public Cloud (S3-compatible)

If your source is Infomaniak Public Cloud Object Storage rather than Swiss Backup, it is S3-compatible (AWS Signature V4). Per the Infomaniak Public Cloud S3 documentation, the endpoint is https://s3.pub1.infomaniak.cloud/ (or pub2), region is the us-east-1 compatibility default since all data stays in Swiss data centres, and you need EC2-style credentials created with openstack ec2 credentials create, not the Swiss Backup credentials.

[infomaniak-s3]
type = s3
provider = Other
endpoint = https://s3.pub1.infomaniak.cloud
region = us-east-1
access_key_id = <EC2_KEY>
secret_access_key = <EC2_SECRET>

rclone copy infomaniak-s3:<bucket> chili:<bucket> --transfers 8 --checksum --progress

9. Copy the data

The copy step is the same for every source. copy transfers only new and changed files and never deletes at the target:

rclone copy <source>:<bucket> chili:<bucket> --transfers 8 --checksum --progress

--checksum compares by checksum rather than timestamp and size, which is the more reliable choice for a migration. Do a trial run with --dry-run first. Use rclone sync only if you deliberately want the target mirrored to the source, since sync deletes at the target what is missing at the source.

10. Verify

Because chili has no egress fees, you can read everything back and compare without a retrieval charge. rclone check compares source and target by checksum:

rclone check <source>:<bucket> chili:<bucket> --checksum

Expected output on a clean migration:

NOTICE: S3 bucket <bucket>: 0 differences found
NOTICE: S3 bucket <bucket>: <N> matching files

Common pitfalls

• Endpoint spelling: take the chili endpoint from the portal, including the scheme (https://). For a generic S3 target (provider = Other) please verify whether rclone expects the full https:// URL or a bare hostname in your version, as the rclone S3 documentation does not pin this down with an explicit “Other” example.
• Path style: if uploads against an S3-compatible source or target fail with addressing errors, check whether the provider expects path-style addressing.
• Region as a compatibility value: for S3 clones the region is often just a required string with no meaning; leave it blank where the provider has no region concept.
• TLS: keep all endpoints on HTTPS; do not disable certificate verification.
• B2 keys: use the applicationKeyId, not the master account ID, and a dedicated application key for the S3-compatible API.

The result: existing object storage from AWS, Azure, Backblaze, Wasabi or Infomaniak, copied and checksum-verified into a Swiss S3-compatible target in Zurich or Geneva, geo-redundant on request, with no egress fees on the verification read.