Migrations-Cookbook: von AWS, Azure, Backblaze, Wasabi und Infomaniak

Ein Referenz-Cookbook für die Migration bestehender Object-Storage-Daten nach chili. Für jeden Quell-Anbieter gibt es ein knappes rclone-Rezept. Das Muster ist immer gleich: Quell-Remote und chili-Remote konfigurieren, mit rclone copy --checksum übertragen und mit rclone check verifizieren. Am Ende liegen die Daten S3-kompatibel in der Schweiz, in Zürich oder Genf und auf Wunsch georedundant, ohne Egress-Gebühren.

Voraussetzungen

• rclone ab Version 1.60 (rclone version)
• chili-Zugangsschlüssel (Access Key und Secret) aus dem Portal sowie ein Ziel-Bucket oder die Berechtigung, einen anzulegen
• Lese-Zugriff auf den Quell-Speicher (anbieterspezifische Credentials, siehe je Rezept)
• genügend Bandbreite; bei grossen Beständen die Migration ausserhalb der Lastzeiten planen

Übersicht: Quelle, rclone-Backend, Besonderheit

1. chili als Ziel-Remote konfigurieren

Dieses Remote ist in allen Rezepten das Ziel. Eintrag in ~/.config/rclone/rclone.conf:

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

Bei provider = Other (S3-Klon) kann region leer bleiben. Verbindung testen:

rclone lsd chili:

2. AWS S3

Für AWS wird provider = AWS gesetzt; region ist erforderlich, der endpoint bleibt leer, dann nutzt rclone den Standard-Endpoint der Region (rclone S3-Doku).

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

Migrieren und verifizieren:

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

--checksum vergleicht über die Prüfsumme statt über Zeitstempel und Grösse. Vorab empfiehlt sich ein Trockenlauf mit --dry-run.

3. Azure Blob Storage

Das Backend heisst azureblob. Authentifizieren lässt sich per Account und Shared Key, alternativ über eine SAS-URL (sas_url) oder einen Connection-String (connection_string) (rclone Azure-Blob-Doku).

[azure]
type = azureblob
account = <STORAGE_ACCOUNT>
key = <SHARED_KEY>

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

Zwei Eigenheiten von azureblob: rclone about wird nicht unterstützt, die Kapazitätsplanung muss daher gegebenenfalls quellseitig erfolgen. Liegen Blobs im Archive-Tier, müssen sie vor dem Überschreiben gelöscht werden, sofern nicht --azureblob-archive-tier-delete gesetzt ist (rclone Azure-Blob-Doku).

4. Backblaze B2

Backblaze B2 bietet sowohl eine native API als auch eine S3-kompatible API. rclone unterstützt beide Wege (Backblaze-Doku).

Variante A, natives B2-Backend. account ist die Application Key ID, key der Application Key. Wichtig: Es muss die applicationKeyId verwendet werden, nicht die Master-Account-ID, sonst antwortet B2 mit 401 (rclone B2-Doku).

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

Variante B, S3-kompatible API. Für die S3-API muss ein eigener Application Key angelegt werden; der Master Application Key ist nicht S3-kompatibel (Backblaze-Doku). Den exakten regionalen S3-Endpoint im B2-Bucket-Detail unter «Endpoint» ablesen und nicht hartkodieren (das genaue Schema bitte dort prüfen).

[b2s3]
type = s3
provider = Other
access_key_id = <keyID>
secret_access_key = <appKey>
endpoint = <regionaler S3-Endpoint aus dem B2-Bucket-Detail>

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

5. Wasabi

Für Wasabi wird provider = Wasabi gesetzt, die Authentifizierung läuft wie bei AWS über Access Key und Secret. Den regionalen Endpoint-Hostnamen explizit setzen: s3.wasabisys.com entspricht us-east-1, EU-Buckets brauchen den passenden EU-Endpoint wie s3.eu-central-1.wasabisys.com. region kann bei diesem S3-Klon leer bleiben (rclone S3-Doku).

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

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

6. Infomaniak

Infomaniak hat zwei getrennte Produkte mit unterschiedlichen Protokollen. Prüfen Sie zuerst, welches die Quelle ist.

Variante Swiss Backup (Swift). Backend swift. Der auth-URL enthält eine Cluster-Nummer (swiss-backupNN), die je nach Standort variiert; die korrekte Nummer steht im Infomaniak-Manager unter «Cloud storage information». Geräte, die vor Oktober 2020 erstellt wurden, nutzen auth = https://swiss-backup.infomaniak.com/identity/v3 (Infomaniak-Support).

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

Variante Public Cloud (S3-kompatibel). Das separate Produkt Public Cloud Object Storage ist S3-kompatibel. Endpoint ist https://s3.pub1.infomaniak.cloud (alternativ pub2); als region dient der Default us-east-1 als reiner Kompatibilitätsparameter, die Daten liegen in Schweizer Rechenzentren. Benötigt werden EC2-style-Credentials via openstack ec2 credentials create, nicht die Swiss-Backup-Zugangsdaten (Infomaniak-Docs).

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

Migrieren und verifizieren (für beide Varianten analog):

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

Verifizieren

Nach jeder Migration zeigt rclone check per Prüfsumme, dass Quelle und Ziel identisch sind:

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

2026/06/17 10:42:13 NOTICE: S3 bucket mein-bucket: 0 differences found
2026/06/17 10:42:13 NOTICE: S3 bucket mein-bucket: 1284 matching files

Da der Abruf bei chili keine Egress-Gebühr kostet, lässt sich zusätzlich eine Stichprobe zurücklesen und vergleichen, ohne Zusatzkosten:

rclone copy chili:<bucket>/<objekt> /tmp/restore-test --progress
rclone check chili:<bucket> <quelle>:<bucket> --checksum --one-way

Häufige Stolpersteine

• Endpoint-Schreibweise: Den chili-Endpoint aus dem Portal als vollständige URL eintragen, inklusive https://. Beim S3-kompatiblen Backblaze- oder Infomaniak-Endpoint die genaue Schreibweise (volle URL oder blosser Hostname) im jeweiligen Portal prüfen, statt sie anzunehmen.
• Backblaze-Credentials: Im nativen b2-Backend gehört die applicationKeyId in das Feld account, nicht die Master-Account-ID, sonst kommt ein 401-Fehler zurück.
• Infomaniak-Cluster: Die swiss-backupNN-Nummer im auth-URL stimmt nicht immer mit dem Beispiel überein. Den Wert aus «Cloud storage information» übernehmen.
• Infomaniak S3 vs. Swift: Für die S3-API von Infomaniak Public Cloud braucht es EC2-style-Credentials; die Swiss-Backup-Zugangsdaten funktionieren dort nicht.
• Region bei S3-Klonen: Bei provider = Other kann region leer bleiben. Bei AWS ist region dagegen Pflicht.
• sync statt copy: rclone copy ist additiv. rclone sync spiegelt und löscht am Ziel, was in der Quelle fehlt; vor einem sync immer --dry-run laufen lassen.

Das Ergebnis: die Daten jedes dieser Anbieter liegen S3-kompatibel in der Schweiz, in Zürich oder Genf und auf Wunsch georedundant, ohne Egress-Gebühren.