80 TB von einem S3-Anbieter zum anderen verschieben. Klingt nach einem Wochenende mit rclone. In der Praxis dauert es oft zwei Monate. Nicht wegen der Datenmenge—wegen des Weges.
Das Dreieck, das niemand sieht
S3-Migration hat drei Punkte, nicht zwei. Die Daten liegen beim alten Anbieter. Das Ziel ist der neue. Aber wo läuft das Migrations-Tool? Auf dem eigenen Laptop? Auf einer VM bei Hetzner? Bei AWS?
Genau hier liegt das Problem. Der Datenfluss ist kein Pfeil von A nach B, sondern ein Dreieck:
Alter Anbieter → Migrations-Host → Neuer AnbieterDieser Umweg kostet. In Zeit und in Geld.
Der teure Umweg
Egress-Gebühren fallen an, wenn Daten ein Rechenzentrum verlassen. Bei einer Migration über einen dritten Host zahlen Sie zweimal: einmal vom alten Anbieter zu Ihrem Server, und nochmal von Ihrem Server zum Ziel—falls der Server auch bei einem Cloud-Anbieter steht.
Bei 80 TB und 90€/TB Egress (AWS, Azure) sind das 7.200€, nur um die Daten zum Migrations-Server zu bekommen. Steht der bei einem anderen Cloud-Anbieter, zahlen Sie nochmal.
ZERO-Z3 berechnet 5€/TB Egress und keinen Cent für Ingress. Aber der Weg zu uns kann trotzdem teuer werden, wenn er über die falschen Zwischenstationen führt.
Kleine Dateien, großes Problem
Bei großen Dateien dominiert die Bandbreite. 1 GB bei 1 Gbps dauert theoretisch 8 Sekunden—in der Praxis eher 12–20 Sekunden durch TCP Slow Start, Protokoll-Overhead und geteilte Leitungen. Trotzdem verkraftbar.
Kleine Dateien sind ein anderes Tier. Eine 10-KB-Datei ist in Millisekunden übertragen. Aber bevor überhaupt ein Byte fließt, muss das Protokoll seine Arbeit tun: DNS-Lookup, TCP-Handshake, TLS-Handshake, HTTP-Request. Pro Objekt 2–4 Roundtrips. Bei 50ms Latenz zwischen Migrations-Host und Ziel sind das 100–200ms—nur fürs Reden, bevor die eigentliche Übertragung beginnt.
Ein Beispiel aus der Praxis: 80 TB in 3,2 Milliarden Objekten. Durchschnitt 25 KB, viele deutlich kleiner. Backup-Chunks, Metadaten, Logs. Eine S3-Migration im großen Stil.
Die Rechnung bei 50ms Latenz und 3 Roundtrips pro Objekt:
3,2 Mrd. × 150ms = 480 Mio. Sekunden = 15 JahreMit 1.000 parallelen Streams:
15 Jahre / 1.000 = 5,5 TageDas wäre der optimistische Fall—perfekte Parallelisierung, keine Engpässe, keine Fehler. In der Praxis sehen wir bei solchen Migrationen 50–100 GB pro Stunde. Bei 80 TB sind das 66 Tage.
rclone ist nicht das Problem
Für S3-Migrationen ist rclone erste Wahl. Bei vielen kleinen Dateien schlägt es MinIO Client und AWS CLI um das 6–9-fache. Die richtigen Flags machen einen Unterschied:
rclone copy source:bucket dest:bucket \
--transfers 32 \
--checkers 16 \
--fast-list \
--s3-upload-concurrency 4 \
--s3-chunk-size 64MAber auch das beste Tool kann keine Physik überlisten. Ein schnelles Werkzeug auf einem schlecht angebundenen Host bleibt langsam. Der Standort des Migrations-Hosts entscheidet, nicht die Software.
Self-Service-Migration und ihre Grenzen
Manche Anbieter haben eingebaute Migrations-Tools. Cloudflare R2 nennt seins "Super Slurper", Backblaze B2 bietet Migrations-Support, AWS hat DataSync. Diese Tools ziehen direkt vom Quell-Bucket—kein Dreieck, kein doppelter Egress.
Klingt gut. Der Haken: Dateigrößen-Limits, begrenzte Parallelität, und niemand, der hinschaut wenn etwas schiefgeht. R2 begrenzt auf 1 TB pro Objekt und lässt nur 3 Migrationen gleichzeitig laufen. Für ein paar Terabyte mit normalen Dateigrößen funktioniert das.
Für 80 TB verteilt auf Milliarden Objekte funktioniert es nicht. Große Migrationen brauchen jemanden, der aufpasst. Fehlgeschlagene Objekte wiederholen, Rate-Limits abfangen, Chunk-Sizes auf die tatsächliche Dateiverteilung abstimmen. Das ist kein Self-Service-Job.
Wie wir das lösen
Die einfachste Lösung: Den Migrations-Host dorthin stellen, wo das Ziel ist. Wenn rclone im selben Rechenzentrum läuft wie ZERO-Z3, fällt die halbe Latenz weg. Kein Egress für den zweiten Hop. Sub-Millisekunden statt 50ms.
Wir bieten zwei Varianten an.
Sie machen es selbst, aber von unserem Netz aus. Wir stellen eine VM in unserem Rechenzentrum bereit. 10–25 Gbps Anbindung, direkter Zugang zu ZERO-Z3, kein zusätzlicher Egress. Sie zahlen weiterhin Egress vom alten Anbieter—daran führt kein Weg vorbei, die Daten müssen irgendwie raus. Aber Sie zahlen nur einmal.
Wir machen es für Sie. Sie geben uns Read-Only-Credentials für den Quell-Bucket. Wir analysieren die Datenstruktur, finden die optimalen Einstellungen, führen die Migration durch und validieren, dass alles angekommen ist. Sie können den Fortschritt verfolgen. Wir kümmern uns um die Probleme—und bei Milliarden Objekten gibt es immer welche.
Kosten
Selbst migrieren:
| VM (8 vCPU, 16 GB RAM, 25 Gbps) | ~50€/Woche |
| ZERO-Z3 Ingress | 0€ |
| ZERO-Z3 Storage | nach Verbrauch |
Managed Migration:
| Bis 10 TB | 250€ pauschal |
| Über 10 TB | 25€/TB |
| Über 100 TB | auf Anfrage |
10 TB kosten 250€. 50 TB kosten 1.250€. Die Pauschale deckt den Setup-Aufwand—Analyse, Konfiguration, Validierung. Darüber skaliert es linear.
Der größte Posten bleibt Egress vom alten Anbieter. Daran können wir nichts ändern. Aber wir verhindern, dass Sie doppelt zahlen.
Für wen das Sinn macht
Mehr als ein Terabyte. Millionen kleiner Dateien—Backup-Chunks, Logs, Metadaten. Wer in Tagen fertig sein will, nicht in Monaten. Und wer keine Lust hat, eine Woche an rclone-Flags zu basteln und dann festzustellen, dass der Migrations-Host am falschen Ort steht.
Schreiben Sie uns: wie viel Daten, ungefähr wie viele Objekte, wo die Daten aktuell liegen. Wir sagen Ihnen, was Sie erwarten können.