S3-Bucket-Replikation: Methoden, Beispiele, Fallstricke

WebDisk Blog · Kategorie: Object Storage · Lesezeit: ~27 Minuten

Kurz gefasst:- Bucket-Replikation – eine zweite Kopie der Objekte an einem anderen Ort – kennt fünf Lösungsfamilien: eine Regel im S3 selbst, Cluster-Replikation (multisite), Kopieren mit Werkzeugen (rclone), einen ereignisgesteuerten Worker und Doppelschreiben in der Anwendung.- Alle eint eine Eigenschaft: Replikation vervielfältigt auch das Löschen und das Überschreiben. Ein Replikat ist kein Backup – dazu wird es erst im Verbund mit Versionierung und Schreibsperre (S3 Object Lock).- In WebDisk Files gibt es die Bucket-Replikation: einen einmaligen Import eines S3-kompatiblen Speichers in einen neuen Speicher bei WebDisk, mit Fortschrittsanzeige – ohne Transfergebühren, im Rahmen des im Abonnement enthaltenen Migrationskontingents. >Sie arbeiten nicht mit dem Terminal? Überspringen Sie die Befehlsblöcke – die Beschreibung der Methoden, der Abschnitt über die Fallstricke und der Teil über WebDisk vermitteln das vollständige Bild.

Die Frage „Haben wir eine zweite Kopie?“ fällt meist im denkbar schlechtesten Moment: wenn jemand ein Verzeichnis gelöscht hat, wenn der Anbieter eine Störung der Region gemeldet hat oder wenn die Geschäftsführung fragt, was passiert, wenn morgen der Anbieter gewechselt werden muss. Die Antwort „wir haben doch die Cloud“ genügt nicht, denn die Cloud ist kein einzelner Ort – sie ist ein konkreter Bucket, an einem konkreten Standort, mit einem konkreten Konto, das jemand übernehmen kann.

Die Bucket-Replikation (Bucket – ein Behälter für Dateien in einem S3-Speicher, das Gegenstück zu einer Festplatte oder einer Netzwerkfreigabe; in den WebDisk-Diensten nennen wir ihn Speicher) ist die Antwort auf diese Frage – aber eine unvollständige und leicht misszuverstehende Antwort. In diesem Artikel gehen wir alle real eingesetzten Methoden der Datenreplikation im Objektspeicher durch: von der fertigen Regel, die mit einem einzigen Befehl aktiviert wird, über die Replikation ganzer Cluster bis hin zum eigenen Worker, der auf Ereignisse lauscht. Zu jeder zeigen wir ein Beispiel, die Einstiegskosten und das, was die jeweilige Methode nicht leistet. Am Ende beschreiben wir, wie wir die Replikation in WebDisk Files gelöst haben.

Wozu einen Bucket replizieren? Fünf verschiedene Gründe, fünf verschiedene Lösungen

Bevor Sie eine Technik wählen, benennen Sie das Problem – denn „Replikation“ ist ein Wort für fünf verschiedene Aufgaben, und was für die eine gut ist, kann für die andere nutzlos sein.

Widerstandsfähigkeit gegen den Ausfall eines Standorts (DR, disaster recovery – Wiederherstellung nach einer Katastrophe). Sie wollen den Verlust einer ganzen Region, eines Rechenzentrums oder eines Clusters überstehen. Nötig ist eine Kopie physisch anderswo, am besten in einer anderen Fehlerdomäne und am besten mit eigenen Zugangsdaten.
Migration und Ausstieg beim Anbieter. Sie verlagern Daten von einem S3 in ein anderes – einmalig, aber vollständig und überprüfbar. Das ist keine kontinuierliche Replikation, sondern ein kontrollierter Transfer mit Qualitätsabnahme; ausführlicher haben wir darüber im Zusammenhang mit dem Vendor-Lock-in geschrieben.
Geografische Nähe. Eine Kopie näher an den Nutzern oder näher an der Rechenleistung, um die Antwortzeit zu verkürzen. Hier zählt die Propagationsverzögerung, nicht die Beständigkeit.
Trennung von Umgebungen und Rollen. Eine Kopie der Produktionsdaten für Analytik, Tests oder das Archiv – oft mit Filter, auf ein einziges Präfix zugeschnitten und von sensiblen Daten befreit.
Isolation der Kopie vom Produktionskonto. Eine Kopie an einem Ort, den die Zugangsdaten der Produktion nicht erreichen – damit die Übernahme des Kontos nicht den Verlust von allem bedeutet. Das ist das Anti-Ransomware-Szenario, und es hat eigene Spielregeln.

Merken Sie sich diese Liste, denn wir kommen bei der Methodenwahl darauf zurück: Den ersten Punkt bedient am besten eine unidirektionale Replikation unter Beibehaltung der Historie, den zweiten ein einmaliges, überprüfbares Kopieren mit einem Werkzeug, den dritten die native Replikation des Anbieters, den vierten das Kopieren mit Filter und den fünften eine Kopie in einem separaten Konto mit Schreibsperre.

Replikation, Synchronisation, Backup – drei Wörter, die keine Synonyme sind

Diese Unterscheidung entscheidet darüber, ob Ihre zweite Kopie überhaupt etwas rettet.

Replikation hält eine Kopie im Einklang mit der Quelle. Ihr Ziel ist, dass das Ziel so aussieht wie die Quelle – einschließlich der Tatsache, dass eine Datei gelöscht wurde. Eine gute Replikation ist schnell und getreu; das heißt zugleich, dass sie die Katastrophe getreu vervielfältigt.

Synchronisation (rclone sync, aws s3 sync --delete) ist eine periodisch, in Chargen ausgeführte Replikation – mit derselben Eigenschaft: Sie löscht im Ziel das, was in der Quelle nicht vorhanden ist.

Backup ist eine Kopie mit Historie und mit Schutz vor Veränderung: mehrere Zeitpunkte, Aufbewahrungsfristen, keine Möglichkeit, vor Fristablauf zu löschen. Ein Backup ist absichtlich nicht im Einklang mit der Quelle – sein Wert besteht gerade darin, dass es den Zustand vor dem Fehler kennt.

Die 3-2-1-Regel und den Unterschied zwischen Kopie und Synchronisation haben wir im Artikel über Cloud-Backup ausgeführt. Hier genügt ein Satz, den man sich über den Schreibtisch hängen sollte: Ein Replikat schützt vor dem Verlust von Hardware, ein Backup schützt vor dem Verlust von Daten. Das sind keine Austauschartikel, und die meisten ernsthaften Umsetzungen haben beides.

Vier Fragen, die die Methode für Sie auswählen

Bevor wir zu den Techniken kommen, vier Fragen. Die Antworten darauf engen die Auswahl meist auf eine, höchstens zwei Methoden ein.

Welches RPO (Recovery Point Objective) ist bei Ihnen zulässig? Wie viele Minuten – oder Stunden – an Daten dürfen Sie verlieren? Sekunden bedeuten ereignisgesteuerte oder native Replikation; bei Stunden genügt problemlos ein geplantes Kopieren mit einem Werkzeug.
Liegen beide Enden beim selben Anbieter? Native S3-Replikation funktioniert in der Regel innerhalb einer Plattform. Zwischen verschiedenen Anbietern bleiben fast immer nur Werkzeuge oder ein eigener Worker.
Soll die Kopie die Historie kennen? Wenn ja, brauchen Sie Versionierung auf beiden Seiten und eine Methode, die Versionen überträgt – oder die bewusste Entscheidung, dass die Kopie „flach“ ist und die Historie das Backup hält.
Wer zahlt für den Transfer und wer hat die Schlüssel? Eine Kopie beim selben Anbieter ist mitunter kostenlos, eine Kopie „nach außen“ kostet ausgehenden Datenverkehr. Und eine Kopie, die mit denselben Schlüsseln erreichbar ist wie die Produktion, schützt nicht vor einer Kontoübernahme.

Methode 1. Replikationsregel im S3 selbst: Der Speicher achtet selbst auf die Kopie

Die konzeptionell einfachste und „cloudigste“ Methode: Sie sagen dem Speicher, dass er sich selbst um die Kopie kümmern soll. Die Konfiguration lebt auf dem Quell-Bucket als Replikationsregel, und die gesamte Arbeit erledigt die Speicherschicht – ohne jede Maschine auf Ihrer Seite.

Drei Dinge müssen vorhanden sein, damit das überhaupt anläuft:

Versionierung auf beiden Seiten – die Replikation arbeitet mit Objektversionen, nicht mit Namen; ohne Versionierung gibt es nichts zu replizieren (es ist dasselbe Fundament, auf dem Object Lock steht),
eine Identität mit Berechtigungen für beide Buckets – in AWS ist das eine IAM-Rolle, die der S3-Dienst in Ihrem Namen annimmt,
eine Regel – mit Filter (ganzer Bucket, Präfix oder Tag), Priorität und der Beschreibung des Ziels.

Bevor Sie beginnen. Die Beispiele verwenden aws CLI und rclone, konfiguriert wie in den vorherigen Artikeln der Serie (aws configure + --endpoint-url Ihres Anbieters – wir lassen ihn unten der Lesbarkeit halber weg). Vorsicht mit echten Daten: rclone sync und aws s3 sync --delete löschen im Ziel das, was in der Quelle nicht vorhanden ist, und ein Tippfehler im Quellpräfix kann die Kopie leeren. Üben Sie mit Test-Buckets.

Ein praktisches Beispiel in AWS. Zuerst die Versionierung, dann die Regel selbst:

# 1. Versionierung auf Quelle und Ziel — zwingende Voraussetzung
aws s3api put-bucket-versioning --bucket firma-produkcja \
  --versioning-configuration Status=Enabled
aws s3api put-bucket-versioning --bucket firma-kopia-dr \
  --versioning-configuration Status=Enabled

# 2. Replikationsregel: alles, was in „raporty/“ landet, landet im zweiten Bucket
aws s3api put-bucket-replication --bucket firma-produkcja \
  --replication-configuration '{
    "Role": "arn:aws:iam::111122223333:role/s3-replikacja",
    "Rules": [{
      "ID": "raporty-do-dr",
      "Priority": 1,
      "Status": "Enabled",
      "Filter": { "Prefix": "raporty/" },
      "DeleteMarkerReplication": { "Status": "Disabled" },
      "Destination": {
        "Bucket": "arn:aws:s3:::firma-kopia-dr",
        "StorageClass": "STANDARD_IA"
      }
    }]
  }'

Die Prüfung, ob ein konkretes Objekt bereits kopiert wurde, ist ebenso einfach – den Replikationsstatus sieht man in seinen Metadaten:

aws s3api head-object --bucket firma-produkcja --key raporty/2026-08.csv
# "ReplicationStatus": "COMPLETED" ← oder PENDING / FAILED
# in der Kopie meldet dasselbe Objekt "REPLICA"

Achten Sie auf DeleteMarkerReplication. Dieses eine Feld entscheidet über den Charakter der gesamten Lösung: aktiviert – die Kopie ist ein getreuer Spiegel und das „Verschwinden“ der Datei propagiert auf die andere Seite; deaktiviert – die gelöschte Datei bleibt in der Kopie. Für eine als DR verstandene Replikation ist das Deaktivieren mitunter eine bewusste Wahl, aber man muss wissen, dass dabei eine Kopie entsteht, die sich mit der Zeit von der Quelle entfernt und selbst nicht aufräumt.

Die zweite Sache, die man leicht vergisst: Das Löschen einer konkreten Version wird niemals repliziert: Wenn Sie in der DELETE-Anfrage eine Versionskennung angeben, verschwindet sie ausschließlich in der Quelle. Das ist eine absichtliche Schutzeigenschaft – und eine gute Nachricht für das Szenario „jemand hat das Konto übernommen und räumt die Daten ab“. Achtung bei einem Migrationsdetail: Ältere Konfigurationen (ohne das Element Filter) replizierten standardmäßig Löschmarkierungen aus Nutzeraktionen, neuere hingegen nicht. Das Hinzufügen eines Filters zu einer alten Regel ändert also im Stillen das Verhalten beim Löschen.

Drei Überraschungen, die diese Methode in petto hat:

Die Regel wirkt ab dem Moment der Aktivierung. Objekte, die vorher im Bucket lagen, werden nicht von selbst kopiert – beim Hyperscaler muss man dafür einen separaten Massenauftrag starten (in AWS: S3 Batch Replication), außerhalb davon kopiert man sie einfach mit einem gewöhnlichen Werkzeug (Methode 3, weiter unten beschrieben). Das gilt auch für jede Unterbrechung der Regel – wir kommen darauf in Fallstrick 6 zurück.
Replikation bildet keine Ketten. Die Kopie im Bucket B fährt nicht weiter nach C, selbst wenn B eine eigene Regel hat. Ketten baut man nicht – jedes Ziel wird separat an die Quelle angeschlossen.
Ein Filter nach Tags erfasst nur Tags, die beim Schreiben vergeben wurden. Das nachträgliche Taggen einer Datei löst keine Replikation aus, was das beliebte Muster „erst hochladen, dann klassifizieren“ wirksam sprengt. Ein Filter nach Präfix hat dieses Problem nicht.

Wenn die Replikation vertragliche Zeitrahmen haben soll, kauft man sie beim Hyperscaler separat dazu: S3 Replication Time Control verpflichtet den Anbieter, 99,9 % der neuen Objekte innerhalb von 15 Minuten zu übertragen, und liefert dazu Metriken sowie Ereignisse bei Überschreitung des Schwellenwerts. Ohne diese Option gibt AWS kein Versprechen ab: Die Dokumentation sagt nur, dass sich die meisten Objekte innerhalb von 15 Minuten replizieren, bei großen kann es einige Stunden dauern und in Extremfällen sogar mehrere Dutzend – ohne SLA. In der Praxis ist es meist eine Sache von Sekunden, aber im Audit zählt die Verpflichtung, nicht die Praxis.

Wann sinnvoll: beide Enden liegen beim selben Anbieter, Ihnen liegt an einem kleinen RPO und Sie wollen keine eigene Kopierinfrastruktur betreiben. Was sie nicht löst: die Verlagerung der Daten zu einem anderen Anbieter, die Historie vor der Aktivierung der Regel und den Schutz vor dem Löschen – Letzteren fügt man separat hinzu, mit Versionierung und einer Sperre auf dem Ziel-Bucket.

Methode 2. Replikation auf Cluster-Ebene: multisite, also eine Eigenschaft der Plattform

Die Methode für diejenigen, die zwei Objektspeicher haben – zwei Cluster, zwei Serverräume – und wollen, dass die Replikation eine Eigenschaft der Plattform ist und nicht jedes einzelnen Buckets. In Ceph RGW heißt das multisite, in MinIO – Replikation der Installation.

In Ceph sieht die Hierarchie so aus: Ein realm (Namensraum) enthält eine zonegroup, und darin wohnen Zonen (zone) – eine je Standort, jede auf einem eigenen Ceph-Cluster aufgebaut. Die Zonen tauschen untereinander zwei unabhängige Ströme aus: Metadaten (Benutzer, Buckets, Richtlinien – zentral von der Hauptzone verwaltet) und Daten (Objekte – von jeder Zone einzeln synchronisiert). Das erledigen die RGW-Daemons selbst, ohne jeden externen Agenten.

# Standort A — Realm, Zonengruppe und Hauptzone
radosgw-admin realm create --rgw-realm=firma --default
radosgw-admin zonegroup create --rgw-zonegroup=eu --endpoints=https://s3-a.firma.pl --master --default
radosgw-admin zone create --rgw-zonegroup=eu --rgw-zone=eu-a --endpoints=https://s3-a.firma.pl --master --default

# Systembenutzer — mit diesem Schlüssel authentifizieren sich die Zonen untereinander
radosgw-admin user create --uid=sync --display-name="Sync User" --system \
  --access-key=<klucz-systemowy> --secret=<sekret>
radosgw-admin zone modify --rgw-zone=eu-a --access-key=<klucz-systemowy> --secret=<sekret>
radosgw-admin period update --commit

# Standort B — zweite Zone in derselben Gruppe; zieht zuerst Realm und Period
radosgw-admin realm pull --url=https://s3-a.firma.pl \
  --access-key=<klucz-systemowy> --secret=<sekret> --default
radosgw-admin period pull --url=https://s3-a.firma.pl \
  --access-key=<klucz-systemowy> --secret=<sekret>
radosgw-admin zone create --rgw-zonegroup=eu --rgw-zone=eu-b --endpoints=https://s3-b.firma.pl \
  --access-key=<klucz-systemowy> --secret=<sekret>
radosgw-admin period update --commit

# tägliche Diagnose: bleibt die Zone zurück?
radosgw-admin sync status
# Sie suchen nach Shards „behind“ (aufzuholen) und „recovery“ (Fehler, erneuter Versuch eingeplant)

Die Replikation ist asynchron, mit letztlicher Konsistenz – Änderungen propagieren im Hintergrund, und weitere Portionen des Änderungsprotokolls werden alle zehn bis mehrere Dutzend Sekunden abgefragt. Das heißt genau so viel, dass der zweite Standort das Objekt kurz nach dem Schreiben noch nicht hat und dass das Umschalten auf die Ersatzzone eine Entscheidung des Betreibers ist, kein Automatismus: Man befördert sie manuell, am besten nachdem man sich vergewissert hat, dass sie den Rückstand aufgeholt hat.

Neuere Ceph-Releases erlauben es, ausgewählte Buckets statt der ganzen Zone zu replizieren – dazu dient eine granulare Synchronisationsrichtlinie aus drei Schichten: der Gruppe (ob Replikation erlaubt ist), dem Fluss (in welche Richtung die Daten fließen – wechselseitig oder unidirektional) und der „Röhre“ (was genau und wohin). Das empfohlene Muster ist, auf Ebene der Zonengruppe breit zu erlauben und punktuell auf Bucket-Ebene zu aktivieren:

# auf Ebene der Zonengruppe: „erlaubt, aber ich aktiviere nicht alles“
radosgw-admin sync group create --group-id=grupa-dr --status=allowed
radosgw-admin sync group flow create --group-id=grupa-dr --flow-id=a-do-b \
  --flow-type=directional --source-zone=eu-a --dest-zone=eu-b
radosgw-admin sync group pipe create --group-id=grupa-dr --pipe-id=wszystko \
  --source-zones='*' --dest-zones='*'
radosgw-admin period update --commit

# auf Ebene des konkreten Buckets: „diesen replizieren“ (ohne period update)
radosgw-admin sync group create --bucket=firma-backup \
  --group-id=backup-default --status=enabled
radosgw-admin sync group pipe create --bucket=firma-backup \
  --group-id=backup-default --pipe-id=pipe1 \
  --source-zones='*' --dest-zones=eu-b

radosgw-admin sync info --bucket=firma-backup # was tatsächlich fließt und wohin

Die Röhre kann bei der Gelegenheit auch filtern (Präfix, Tags) und das Ziel umformen: in einen Bucket mit anderem Namen, zu einem anderen Eigentümer oder in eine andere Speicherklasse replizieren. Es gibt außerdem ein separates Modul, das Daten unidirektional in ein externes S3 schiebt – also zu einem völlig fremden Anbieter, ohne einen zweiten Ceph-Cluster aufzustellen.

Die für die Sicherheit interessanteste Variante ist die Archivzone (archive zone): eine Zone, die Versionierung erzwingt und alle aufeinanderfolgenden Versionen von allem hält, was durch den Cluster geflossen ist, und aus der sich Objekte ausschließlich über ihre eigenen Gateways entfernen lassen. Das ist die einzige Spielart der Replikation auf Cluster-Ebene, die sich gegen einen Bedienfehler und gegen Ransomware wehrt, denn sie bricht mit der Kernannahme „die Kopie soll aussehen wie das Original“. Der praktische Aufbau sieht so aus: Die Produktion arbeitet auf gewöhnlichen, nicht versionierten Zonen, und daneben steht ein Archiv, an das aus der Produktion niemand herankommt.

Wann sinnvoll: Sie haben (oder kaufen) zwei Standorte und wollen eine für die Kunden transparente Replikation – einschließlich Konten und Richtlinien. Was sie nicht löst: gar nichts, wenn der zweite Standort nicht existiert. Multisite ist eine Infrastruktur- und Kostenentscheidung, kein Schalter im Panel; sie verlangt einen zweiten Cluster, eine Leitung, die den Änderungsstrom trägt, und Disziplin bei Aktualisierungen (neue Funktionen aktiviert man erst dann, wenn alle Zonen sie verstehen).

Hat Ihr Anbieter das überhaupt? Ein Überblick über neun Plattformen

Stand August 2026. Bevor Sie eine Replikation auf Basis einer Bucket-Regel planen, prüfen Sie, ob es überhaupt etwas gibt, womit man sie aktivieren kann. Das ist die häufigste Enttäuschung in diesem Thema: Native Replikation ist eine Funktion der Plattform und kein Teil des S3-Standards. Das Protokoll ist gemeinsam, aber ob es überhaupt eine Replikationsregel gibt und was sie genau tut, ist bei jedem Anbieter unterschiedlich.

AWS S3 – vollständige native Replikation, innerhalb derselben Region und zwischen Regionen, mit optional vertraglich zugesicherter Propagationszeit und einem separaten Massenauftrag für bereits vorhandene Objekte.
OVHcloud – native, asynchrone Replikation, konfiguriert mit dem standardmäßigen put-bucket-replication; die Versionierung muss man auf Quelle und Ziel selbst aktivieren (von allein tut das nur die separate Option zur Replikation über den Standort hinaus, die beim Anlegen des Buckets in Drei-Zonen-Regionen angehakt wird), es gibt außerdem einen separaten Stapelmodus für früher geschriebene Objekte. Beide Buckets müssen im selben Projekt liegen.
Wasabi – native Replikation, gesteuert über S3-kompatible Aufrufe. Kurios: Sie verlangt keine Versionierung, wohl aber einen übereinstimmenden Zustand auf beiden Seiten (versioniert zu versioniert, nicht versioniert zu nicht versioniert) und denselben Eigentümer der Buckets.
Backblaze B2 – native Replikation, aber über eine eigene API und CLI konfiguriert, nicht über die S3-Schnittstelle; bis zu zwei Regeln pro Bucket, mit der Option, bestehende Dateien einzubeziehen. Für den Replikationsverkehr selbst zahlen Sie nicht – Sie zahlen für die zweite Datenkopie.
Google Cloud Storage – die Replikation ist eine Eigenschaft des Buckets, keine Regel: Sie wählen einen Dual-Region- oder Multi-Region-Bucket, und das war’s. Das nominelle Ziel ist der vollständige Objektbestand in 12 Stunden und gegen Aufpreis (Turbo) – 15 Minuten.
Azure Blob – zwei disjunkte Schichten: Georedundanz des gesamten Kontos (GRS/GZRS) sowie Objektreplikation zwischen Containern, die Versionierung auf beiden Seiten und einen Änderungsfeed auf der Quelle verlangt.
MinIO – hat sowohl Replikation pro Bucket als auch Replikation ganzer Installationen (samt Benutzern und Richtlinien), aber man muss den Stand des Projekts kennen: Das Repository der Community-Ausgabe wurde im April 2026 archiviert, und im kommerziellen AIStor gehört die Replikation zu den Funktionen kostenpflichtiger Pläne. Die Server-Replikation verbindet dabei ausschließlich MinIO-Installationen miteinander.
Ceph RGW – multisite und granulare Synchronisationsrichtlinie, oben beschrieben; bei einem auf Ceph gestützten Anbieter lautet die Frage also schlicht: Haben Sie eine zweite Zone?
DigitalOcean Spaces, Scaleway, Cloudflare R2 – native Bucket-zu-Bucket-Replikation fehlt. R2 gleicht das mit zwei Migrationswerkzeugen aus (einer massenhaften Übertragung und einem inkrementellen Nachladen von Objekten bei Bedarf), bei den übrigen bleibt Methode 3.

Die praktische Schlussfolgerung lautet: Beim Szenario „Kopie bei einem anderen Anbieter“ landet man fast immer wieder bei Werkzeugen – denn selbst wenn beide Plattformen eine native Replikation haben, bekommen sie sie fast nie miteinander abgestimmt.

Methode 3. Kopieren mit Werkzeugen: rclone, mc, s5cmd und aws s3 sync

Die universellste Methode und – entgegen dem Anschein – die in der Praxis am häufigsten verwendete. Sie verlangt weder Zustimmung noch Unterstützung des Anbieters auf irgendeiner Seite: Sie nehmen zwei S3-Endpoints, zwei Schlüsselpaare und schieben die Daten hinüber. Sie funktioniert zwischen beliebigen Plattformen, deshalb rettet gerade sie bei Migrationen und beim Ausstieg beim Anbieter.

Der König dieser Kategorie ist rclone, denn es versteht mehrere Dutzend Backends und hat genau die Schalter, die bei dieser Aufgabe nötig sind:

# Konfiguration zweier Remotes: rclone config (Typ: s3, provider: AWS / Ceph / Minio / Other)

# 1. inkrementelle Kopie OHNE irgendetwas im Ziel zu löschen — die sichere Standardwahl
rclone copy zrodlo:firma-produkcja cel:firma-kopia --progress

# 2. vollständiger Spiegel: das Ziel sieht genau aus wie die Quelle (LÖSCHT überzählige Dateien!)
rclone sync zrodlo:firma-produkcja cel:firma-kopia --progress

# 3. Produktionsvariante: Parallelität für S3, Vergleich über Prüfsummen,
# massenhaftes Listing und über den Tag veränderliches Bandbreitenlimit (Werte in BYTE/s)
rclone sync zrodlo:firma-produkcja cel:firma-kopia \
  --checksum --transfers 32 --checkers 64 --fast-list \
  --bwlimit "08:00,20M 18:00,off" \
  --log-file /var/log/rclone-dr.log --log-level INFO

# 4. Qualitätsabnahme — haben beide Seiten wirklich dasselbe
rclone check zrodlo:firma-produkcja cel:firma-kopia --one-way --checksum

Der Unterschied zwischen copy und sync ist keine Nuance, sondern eine Strategieentscheidung: copy liefert eine Kopie, die niemals von selbst etwas löscht (sie wächst, überlebt aber ein Löschen in der Produktion), sync liefert einen Spiegel (er ist im Einklang, wiederholt aber jede Katastrophe – einschließlich eines Tippfehlers im Quellpräfix, der das Ziel leeren kann). Für den DR-Zweck wollen Sie in der Regel copy – oder sync auf einem Bucket mit aktivierter Versionierung, wo das „Löschen“ nur eine Markierung ist.

Vier Details, die eine funktionierende Replikation von einer scheinbar funktionierenden unterscheiden:

Standardmäßig vergleicht rclone Größe und Änderungszeit, und die Änderungszeit schreibt es in S3 in ein eigenes Metadatum. Objekte, die mit einem anderen Werkzeug hochgeladen wurden, haben dieses Metadatum nicht, also stützt sich der Vergleich dann auf das serverseitige LastModified, das sich bei jeder Kopie ändert – und der nächste Durchlauf kann alles für abweichend halten. Daher --checksum im Beispiel oben.
--checksum vergleicht bei S3 den MD5, den mehrteilige Objekte (multipart) im ETag nicht haben. rclone behilft sich damit bei den eigenen Uploads über ein eigenes Metadatum, aber bei großen Dateien, die mit etwas anderem hochgeladen wurden, gibt es schlicht nichts zu vergleichen. Das ist derselbe Fallstrick, über den wir unten im Abschnitt zur Verifikation schreiben.
Eine Kopie von S3 zu S3 läuft standardmäßig über Ihre Maschine. Zwischen zwei verschiedenen Konfigurationen lädt rclone die Daten herunter und wieder hoch, es sei denn, Sie geben ausdrücklich --server-side-across-configs an (und zwischen verschiedenen Anbietern funktioniert serverseitiges Kopieren ohnehin nie). Bei 50 TB ist das der Unterschied zwischen einem Transfer von 50 und 100 TB – und die entsprechende Rechnung für ausgehenden Datenverkehr.
Starten Sie das mit einer Sperre. Die häufigste Art, wie sich eine solche Replikation selbst zu Fall bringt, sind überlappende Durchläufe aus dem Cron. Das Minimum ist flock -n, schöner ist ein systemd-Timer mit Type=oneshot und Persistent=true, der keine zweite Instanz derselben Unit startet und den Durchlauf nach einem Neustart des Hosts nachholt.

# /etc/cron.d/replikacja — stündlich, mit Sperre gegen überlappende Durchläufe
17 * * * * root /usr/bin/flock -n /var/lock/replikacja.lock \
/usr/bin/rclone copy zrodlo:firma-produkcja cel:firma-kopia \
--checksum --fast-list --log-file /var/log/rclone-dr.log

Alternativen, die man kennen sollte:

s5cmd – wenn es auf rohen Durchsatz bei Hunderttausenden Objekten ankommt; es parallelisiert deutlich aggressiver als aws s3 sync. Der Preis dafür ist das fehlende Bandbreitenlimit (es kann die gesamte verfügbare Leitung belegen) und das Fehlen einer ordentlichen Integritätsprüfung; hinzu kommt, dass es mit einem einzigen Satz Zugangsdaten arbeitet, sodass ein Transfer zwischen zwei verschiedenen Anbietern bei ihm über die lokale Festplatte laufen muss.
aws s3 sync – ist überall dort, wo die AWS CLI ist, und reicht für einfache Aufgaben. Es hat einen einseitigen Test „Quelle neuer“ und überträgt bei einer Kopie von S3 zu S3 standardmäßig Tags und einen Teil der Objekteigenschaften (--copy-props default) – auf Kosten zusätzlicher Anfragen. Seit Kurzem kann es außerhalb von AWS auch überraschen. Neuere CLI-Releases berechnen standardmäßig bei jedem Schreibvorgang Prüfsummen; ältere S3-kompatible Implementierungen kennen das nicht und antworten mit einem Fehler. Das ist das häufigste „es geht plötzlich nicht mehr“ der letzten Monate; man behebt es, indem man die Prüfsummen in der CLI-Konfiguration auf den Modus „nur wenn erforderlich“ umstellt.
mc mirror --watch (MinIO-Client) – lockt mit dem Versprechen eines kontinuierlichen Lauschens statt Läufen aus dem Cron, aber das Lauschen stützt sich auf eine MinIO-spezifische Erweiterung. Auf AWS S3 oder Ceph RGW endet das mit einem Fehler oder einem stillen Übergang zum gewöhnlichen Abfragen – also genau dem, was Sie vermeiden wollten. Außerhalb von MinIO behandeln Sie mc wie ein gewöhnliches Kopierwerkzeug – Objekt-Tags überträgt bei einer Kopie von S3 zu S3 im Übrigen auch aws s3 cp/sync; dasjenige, das Tags nicht überträgt, ist ausgerechnet rclone.

Wann sinnvoll: verschiedene Anbieter auf beiden Seiten, Migration, Zuschnitt der Kopie per Filter, volle Kontrolle darüber, was wann kopiert wird. Was sie nicht löst: ein kleines RPO – die Kopie ist so frisch wie der letzte Lauf. Sie überträgt keine Historie: Keines dieser Werkzeuge kopiert Objektversionen oder Löschmarkierungen, und Object Lock sowie die Bucket-Konfiguration stellt sie nicht einmal annähernd wieder her. Sie nimmt Ihnen auch nicht die Kosten des ausgehenden Datenverkehrs ab, die Sie bei jedem Zyklus beim Anbieter der Quelle zahlen. Bei Millionen kleiner Objekte kann allein das Durchsehen der Liste mehr kosten als der Transfer; in dieser Größenordnung sieht Methode 4 sinnvoller aus.

Und wenn im Bucket ein Backup-Repository liegt und keine Dateien?

Ein eigener, oft übersehener Weg ist die Replikation des Backup-Repositorys statt der Replikation der Daten. Wenn in den Bucket ein Backup-Werkzeug schreibt – restic, Kopia oder Veeam –, macht man die zweite Kopie mit dessen eigenen Mitteln (kopia repository sync-to, ein Backup Copy Job in Veeam) oder – im Fall eines restic-Repositorys, das eine Sammlung unveränderlicher Dateien ist – mit einem gewöhnlichen rclone sync --checksum. Man muss nur wissen, was man dabei verliert: Eine bytegenaue Kopie des Repositorys teilt den Verschlüsselungsschlüssel mit dem Original und unterliegt denselben Aufräumoperationen, restic copy dagegen erzeugt eine kryptografisch unabhängige Kopie, muss dafür aber alles herunterladen und neu verschlüsseln. Bei Veeam ist die Sache einfach, und es lohnt sich, es dem Hersteller nachzusprechen: Den Lebenszyklus der Daten im Objektspeicher verwaltet ausschließlich Veeam, und manuelles Kopieren oder das Hinzufügen von Lifecycle-Regeln auf seinem Bucket kann mit Datenverlust enden.

Methode 4. Ereignisgesteuerte Replikation: Der Speicher soll selbst sagen, was sich geändert hat

Statt den Speicher zu fragen „was hat sich seit gestern geändert?“, lassen Sie ihn es selbst sagen. Objektspeicher können eine Benachrichtigung über jeden Schreib- und Löschvorgang senden: an eine Queue, an einen Broker, an einen HTTP-Endpoint. Die Benachrichtigung nimmt ein eigener Prozess entgegen und kopiert genau das eine Objekt, das sie betrifft.

In Ceph RGW konfiguriert man das als „Topic“ und eine an den Bucket geheftete Notification. Die Notification auf dem Bucket selbst ist S3-kompatibel, aber das Anlegen des Topics unten ist bereits eine RGW-Erweiterung: Die Attribute push-endpoint und persistent sind Eigentum von Ceph, und die Topic-Kennung hat die Form arn:aws:sns:<zonengruppe>:<mandant>:<topic>. In AWS setzt sich derselbe Effekt anders zusammen – Sie erstellen das Topic separat, geben S3 separat das Recht, darin zu publizieren, und hängen den Empfänger per Subscription an:

# 1. Topic: wohin die Benachrichtigungen gehen sollen (hier: HTTP; genauso gut Kafka oder AMQP).
# Die sns-Aufrufe richten wir an den Endpoint des RGW-Gateways: aws --endpoint-url https://s3-a.firma.pl ...
aws sns create-topic --name replikacja \
  --attributes '{"push-endpoint":"http://worker.wewn:9000/zdarzenia","persistent":"true"}'

# 2. Notification auf dem Bucket: uns interessieren Schreib- und Löschvorgänge
aws s3api put-bucket-notification-configuration --bucket firma-produkcja \
  --notification-configuration '{
    "TopicConfigurations": [{
      "Id": "do-repliki",
      "TopicArn": "arn:aws:sns:eu:firma:replikacja",
      "Events": ["s3:ObjectCreated:*", "s3:ObjectRemoved:*"]
    }]
  }'

Der Worker auf der anderen Seite ist banal in der Beschreibung und anspruchsvoll im Detail: Er nimmt das Ereignis entgegen, holt das Objekt aus der Quelle, schreibt es ins Ziel, bestätigt. Die ganze Schwierigkeit steckt in dem, was passiert, wenn etwas schiefgeht – nötig sind Wiederholungen, eine Queue für fehlgeschlagene Ereignisse (Dead Letter), Robustheit gegen die wiederholte Zustellung desselben Ereignisses und das Bewusstsein, dass die Reihenfolge nicht garantiert ist. Man muss außerdem daran denken, dass Ereignisse die Zukunft beschreiben: Was vor der Aktivierung der Notifications im Bucket lag, erfordert ohnehin ein einmaliges Kopieren mit einem Werkzeug aus Methode 3.

Wann sinnvoll: große Volumina, viele kleine Schreibvorgänge, ein in Sekunden gemessenes RPO, der Bedarf an Replikation zwischen verschiedenen Anbietern bei gleichbleibender Frische. Was sie nicht löst: Hier geschieht nichts von selbst – alles steht auf Ihrem Code und Ihrer Wartung. Das ist die „eigenste“ der Lösungen – sie gibt die meiste Kontrolle und die meisten Dinge, die man überwachen muss.

Methode 5. Doppelschreiben in der Anwendung: klingt am einfachsten, wird am teuersten

Die letzte Familie ist die in die Anwendung verlagerte Replikation: Bei jedem Schreibvorgang senden Sie das Objekt an zwei Speicher zugleich. Das klingt am einfachsten von allen und ist mitunter verlockend, wenn der Speicher nur eine Beigabe zum Produkt ist.

In der Praxis überträgt das Doppelschreiben alle Probleme verteilter Systeme auf Sie. Was tun, wenn der erste Schreibvorgang gelungen ist und der zweite nicht – die Operation gegenüber dem Nutzer ablehnen oder sie annehmen und später reparieren? Wie holt man den Rückstand nach einem Ausfall des zweiten Speichers auf? Woher nimmt man die Kopie der Dateien, die geschrieben wurden, bevor Sie diese Funktion ergänzt haben? Jede Antwort ist ein Stück Code, das nachbildet, was die Speicherschicht fertig und getestet bereithält.

Wann sinnvoll: wenn die zweite Kopie anders sein soll als die erste – zum Beispiel schreiben Sie das Original nach S3 und seine verarbeitete Fassung in ein völlig anderes System. Dann ist das keine Replikation, sondern Produktlogik, und sie sitzt zu Recht in der Anwendung. Was sie nicht löst: die Konsistenz ohne erheblichen Aufwand. Wenn beide Kopien identisch sein sollen, kommt fast immer Methode 1, 3 oder 4 aus diesem Artikel günstiger.

Die Schicht, die vergessen wird: Beständigkeit innerhalb des Clusters

Die obigen Methoden beantworten die Frage „was, wenn wir den ganzen Standort verlieren?“. Es gibt jedoch eine Schicht darunter, die eine deutlich häufigere Frage beantwortet: „was, wenn eine Festplatte oder ein Server ausfällt?“. In Objektspeichern löst das der Cluster selbst – und auch das wird Replikation genannt, was in Gesprächen mit Anbietern die Quelle vieler Missverständnisse ist.

n-fache Replikation – jedes Objekt wird in mehreren vollständigen Kopien auf verschiedenen Hosts gehalten (typischerweise drei). Einfach, schnell im Wiederaufbau, kostet so viel Platz, wie der Multiplikator beträgt.
Erasure Coding (Kodierung mit Redundanz) – das Objekt wird in Daten- und Paritätsfragmente zerlegt, die über die Knoten verteilt werden. Kapazitätsseitig günstiger bei vergleichbarer Widerstandsfähigkeit, rechenintensiver und langsamer im Wiederaufbau.

Beide Techniken schützen vor einem Hardwareausfall innerhalb eines Clusters, und keine von beiden ist Disaster Recovery: Das Löschen eines Objekts durch einen Nutzer propagiert sofort auf alle Kopien und Fragmente. Wenn ein Anbieter sagt „wir replizieren Ihre Daten dreifach“, stellen Sie ihm zwei Fragen: ob diese drei Kopien an verschiedenen Standorten liegen und was passiert, wenn jemand ein DELETE absetzt.

Welche Methode wählen? Der Vergleich in Kürze

Dieselben fünf Methoden, geordnet nach den Kriterien, die tatsächlich über die Wahl entscheiden:

Typisches RPO (wie viele Daten Sie verlieren dürfen) – Regel im S3: Sekunden bis Minuten · multisite: Sekunden bis Minuten · Werkzeuge aus dem Cron: so viel, wie der Abstand zwischen den Läufen beträgt · ereignisgesteuert: Sekunden · Doppelschreiben: null (oder ein Auseinanderlaufen, wenn ein Schreibvorgang scheitert).
Ob es zwischen verschiedenen Anbietern funktioniert – Regel im S3: meist nein · multisite: zwischen Clustern derselben Plattform, wobei das Modul zur Cloud-Synchronisation unidirektional in ein fremdes S3 schieben kann · Werkzeuge: ja, immer · ereignisgesteuert: ja · Doppelschreiben: ja.
Wie viel eigene Infrastruktur nötig ist – Regel im S3: keine · multisite: ein zweiter Cluster · Werkzeuge: eine Maschine mit Zugang zu beiden Enden · ereignisgesteuert: Worker, Queue und deren Monitoring · Doppelschreiben: Anwendungscode.
Ob die Versionshistorie übertragen wird – Regel im S3: ja (repliziert Versionen) · multisite: ja · Werkzeuge: nein (kopieren den aktuellen Stand) · ereignisgesteuert: nur das, was Sie selbst kopieren · Doppelschreiben: nein.
Ob das Löschen vervielfältigt wird – Regel im S3: hängt von DeleteMarkerReplication ab · multisite: ja, außer in der Archivzone · Werkzeuge: sync ja, copy nein · ereignisgesteuert: hängt von Ihrem Worker ab · Doppelschreiben: hängt vom Code ab.
Hauptkosten – Regel im S3: Transfer zwischen Regionen und Gebühren für Anfragen · multisite: der zweite Standort · Werkzeuge: ausgehender Datenverkehr und Maschinenzeit · ereignisgesteuert: Wartung und Bereitschaftsdienst · Doppelschreiben: technische Schulden.

Kurz gesagt, nach Szenarien: Migration oder Ausstieg beim Anbieter – rclone (Methode 3) mit check zum Schluss. DR innerhalb eines Anbieters – eine Replikationsregel (Methode 1) auf einem Bucket mit Versionierung. DR zwischen Anbietern – rclone copy nach Zeitplan oder ein ereignisgesteuerter Worker, wenn das RPO in Sekunden gemessen werden soll. Eine ransomware-resistente Kopie – eine beliebige Methode, sofern das Ziel Versionierung und eine Schreibsperre hat und die Zugangsdaten dafür andere sind als die der Produktion.

Sechs Fallstricke, in die man bei der ersten Umsetzung tappt

1. Das Replikat geht zusammen mit dem Original unter. Der wichtigste der Fallstricke und die einzige Sache, die wir in diesem Text absichtlich wiederholen: Das Löschen, das Überschreiben und das Verschlüsseln durch Ransomware ist eine Änderung wie jede andere, und die Replikation überträgt sie auf die Kopie – meist in einem guten Dutzend Sekunden. Das ist keine Theorie: Im Januar 2025 wurde öffentlich eine Kampagne beschrieben, in der Angreifer mit gültigen Zugriffsschlüsseln den Inhalt von Buckets mit dem Mechanismus von S3 selbst (mit einem Kundenschlüssel) verschlüsselten und dem Opfer einen Speicher voller unlesbarer Objekte hinterließen – ohne Einbruch in den Server, ausschließlich mit gewöhnlichen S3-Anfragen. Eine Kopie schützt also vor dem Ausfall von Hardware und Standort, nicht vor dem Menschen und nicht vor dem Angreifer. Das Heilmittel ist Versionierung auf der Zielseite plus eine Schreibsperre (Object Lock, Archivzone) oder ein Modus „nur anhängen“ (copy statt sync). Das Protokoll selbst hilft hier mehr, als es scheint: Das Löschen einer konkreten Version wird niemals repliziert, und eine Löschmarkierung in neueren Konfigurationen standardmäßig ebenfalls nicht.

2. Objekte von vor der Aktivierung der Regel werden nicht kopiert. Die Replikation umfasst die Zukunft. Die Historie erfordert ein einmaliges Hinüberschieben – mit einem Massenauftrag beim Anbieter oder mit rclone copy – und daran vergisst man am leichtesten, weil das Panel „Replikation aktiviert“ anzeigt und alles gut aussieht.

3. Die Kopie ist nicht alles, was der Bucket hatte. Standardmäßig werden die Objekte und ihre Metadaten übertragen. Nicht von selbst übertragen werden: die Bucket-Richtlinien, die CORS-Konfiguration, die Lifecycle-Regeln, die Einstellungen der Standardverschlüsselung, die Konfiguration der Benachrichtigungen und – bei den werkzeugbasierten Methoden – die Versionshistorie sowie die Löschmarkierungen. Sie fahren nicht zusammen mit den Objekten mit, also muss man sie nach der Migration von Hand wiederherstellen – sonst sieht der neue Bucket genauso aus, verhält sich aber anders.

4. Die Verschlüsselung ändert die Spielregeln – und zwar in jeder Methode anders. In der nativen AWS-Replikation kopieren sich Objekte, die serverseitig mit dem Standardschlüssel (SSE-S3) oder mit einem Kundenschlüssel (SSE-C) verschlüsselt sind, ohne zusätzliche Konfiguration – aber Objekte mit verwaltetem Schlüssel (SSE-KMS) replizieren sich standardmäßig überhaupt nicht: Man muss sie ausdrücklich in der Regel aktivieren und einen Schlüssel angeben, der in der Zielregion erstellt wurde. Der Fallstrick ist hinterhältig, denn das Speichern einer solchen Konfiguration mit einem falschen Schlüssel endet mit der Antwort „OK“, und die Replikation fällt erst beim ersten Objekt aus. Bei den werkzeugbasierten Methoden ist es genau umgekehrt: Dort blockiert SSE-C das serverseitige Kopieren – der Speicher ohne Schlüssel entschlüsselt die Quelle nicht und verschlüsselt die Kopie nicht, also müssen die Bytes durch einen Prozess laufen, der den Schlüssel kennt (in Ceph RGW ist das serverseitige Kopieren verschlüsselter Objekte überhaupt nicht implementiert – CopyObject antwortet mit NotImplemented). Die drei Verschlüsselungsvarianten haben wir in einem eigenen Text über SSE-S3, SSE-KMS und SSE-C auseinandergenommen.

5. „Es wurde kopiert“ ist nicht dasselbe wie „es stimmt überein“. Große Dateien werden in Teilen (multipart) hochgeladen, und ihr ETag ist dann keine gewöhnliche MD5-Summe mehr – ein Vergleich darüber liefert falsche Ergebnisse. Derselbe Fallstrick kehrt von der anderen Seite bei der nativen Replikation zurück: Wenn das Objekt in der Quelle unverschlüsselt ist und der Ziel-Bucket eine Standardverschlüsselung aktiviert hat, erhält das Replikat ein anderes ETag als das Original – und jedes Skript, das ETags vergleicht, meldet eine Abweichung, die es nicht gibt. Die Qualitätsabnahme macht man also über Prüfsummen (rclone check --checksum) oder über den Vergleich der Objektanzahl und der Gesamtgrößen auf beiden Seiten. Solange Sie diesen Vergleich nicht anstellen, ist die Migration nur eine Behauptung.

6. Der stille Ausfall der Replikation. Die Replikation geht diskret kaputt: abgelaufene Zugangsdaten, eine geänderte Richtlinie, ein volles Ziel, ein angehaltener Worker. Der Bucket nimmt weiter Schreibvorgänge an, das Panel schreit nicht, und die Kopie hört einfach auf zu wachsen. Schlimmer noch: In der nativen Replikation wird ein Objekt, dessen Kopie fehlgeschlagen ist, nicht von selbst wiederholt – um es einzuholen, muss man es erneut hochladen oder einen Massenauftrag starten. Genauso wirkt das Deaktivieren der Regel „für einen Moment“: Nach dem erneuten Aktivieren wird der Rückstand nicht automatisch aufgeholt. Deshalb muss man zu jeder dieser Methoden ein Monitoring hinzufügen – den Synchronisationsstatus (radosgw-admin sync status), Metriken zur Verzögerung und zur Zahl der ausstehenden Objekte beim Anbieter, Benachrichtigungen über eine fehlgeschlagene Replikation. Oder den denkbar einfachsten Sensor: einen Alarm, wenn die Zahl der Objekte in der Kopie der Quelle nicht mehr folgt.

Was kostet die zweite Kopie – und in welcher Jurisdiktion liegt sie?

Bei Hyperscalern ist der Transfer, der die Region verlässt, kostenpflichtig; bei kontinuierlicher Replikation zahlen Sie ihn für jede Änderung, bei einer vollständigen Migration – für das gesamte Volumen. Hinzu kommen die Gebühren für die Anfragen selbst, und die können bei nativer Replikation überraschen: Das Kopieren eines einzigen Objekts sind auf der Quellseite bis zu mehrere Lesevorgänge und ein Schreibvorgang. Die Rechnung für die zweite Kopie hat also drei Posten und nicht einen: Speicherung, Anfragen und Transfer. Eine gute regulatorische Nachricht: Der EU Data Act lässt die Gebühren für den Anbieterwechsel selbst auslaufen – ab Januar 2027 dürfen sie nicht mehr erhoben werden –, aber die laufende Replikation betrifft das nicht, denn das ist gewöhnlicher ausgehender Datenverkehr und keine Migration bei Vertragskündigung. Wie viel das im Jahresmaßstab bedeuten kann, haben wir in den Texten über die Rechnung für die Public Cloud und über die Unterschiede zwischen Hyperscaler und lokalem Anbieter durchgerechnet.

Die andere Seite derselben Rechnung ist die rechtliche: Ein Replikat hat einen Standort. Eine Kopie „irgendwo in der Cloud“ ist mitunter eine Kopie außerhalb des Europäischen Wirtschaftsraums, was ein rechtliches Ereignis ist und nicht nur ein operatives. Das Anlegen eines Replikats in einem anderen Land ist eine Änderung in der Verarbeitung: Es berührt den Auftragsverarbeitungsvertrag, das Verarbeitungsverzeichnis und die Risikobewertung, nicht nur eine Konfigurationsdatei. Den Standort beider Enden legt man also vor dem ersten Transfer fest und nicht nach dem Audit – darüber, warum die Frage „wo liegen die Daten und ihre Kopien physisch“ auch eine jurisdiktionelle Dimension hat, haben wir im Artikel über europäisches Cloud Computing geschrieben.

Wie machen wir das in WebDisk Files?

Im Organisationspanel von WebDisk Files – in dem Bereich, der dem Administrator der Organisation zugänglich ist – gibt es eine Funktion mit einem unmissverständlichen Namen: Bucket-Replikation. Sie beantwortet dasjenige Szenario aus der Liste vom Anfang, nach dem Kunden am häufigsten fragen – „wir haben Daten bei einem anderen Anbieter und wollen sie bei Ihnen haben“ – und tut das ohne Terminal und ohne vermittelnde Maschine auf Ihrer Seite, in den Grenzen des Kontingents kostenloser Migrationen und ohne uns um Erlaubnis zu fragen.

Das sieht so aus:

Sie geben die Adresse des Quell-Endpoints, den Zugriffsschlüssel und den geheimen Schlüssel an – für einen beliebigen, öffentlich erreichbaren S3-kompatiblen Speicher. Aus einer Liste wählen Sie den Anbietertyp (AWS, Ceph/RGW, MinIO, Wasabi, DigitalOcean Spaces oder „anderer, S3-kompatibler“), denn verschiedene Implementierungen haben ihre kleinen Eigenheiten, die man besser von vornherein berücksichtigt.
Sie klicken auf „Buckets anzeigen“. Wir prüfen die Zugangsdaten sofort und zeigen die Liste der für diese Schlüssel sichtbaren Buckets – dadurch zeigt sich ein Tippfehler im Schlüssel in der ersten Sekunde und nicht nach einer Stunde Kopieren. (Der Schlüssel muss das Recht haben, Buckets aufzulisten – den Namen der Quelle tippt man nicht von Hand ein, man wählt ihn aus der Liste.)
Sie wählen den Quell-Bucket, benennen den neuen Speicher auf unserer Seite und wählen die Kopiergeschwindigkeit. Die Basisgeschwindigkeit beträgt 50 MB/s, die höchste heute verfügbare – 250 MB/s; das gewählte Limit gilt für die gesamte Migration, sodass das Kopieren die Leitung nicht auf unvorhersehbare Weise auslastet.
Sie drücken auf „Synchronisieren“ und sehen dem Fortschritt zu: kopierte Bytes und Prozent des Ganzen, die aktuelle Geschwindigkeit, die voraussichtliche Restzeit und – sollte etwas schiefgehen – eine Fehlermeldung bei der Migration. Die Migration können Sie jederzeit anhalten – die bereits kopierten Dateien bleiben im neuen Speicher.

Darunter läuft genau das, was wir in Methode 3 beschrieben haben, nur als Dienst: Für jede Migration starten wir einen eigenen, einmaligen Worker mit rclone. Der Worker holt seine Konfiguration mit einem Token, das nur für diese eine Migration gültig ist, meldet mit demselben Token den Fortschritt an das Panel und verschwindet nach getaner Arbeit. Einige Designentscheidungen, die man kennen sollte:

Den geheimen Schlüssel zur Quelle bewahren wir verschlüsselt in der Datenbank auf (die Kennung des Zugriffsschlüssels ist, wie in jedem S3, kein Geheimnis). Zum Schreiben in den Zielspeicher verwendet der Worker die S3-Schlüssel der Organisation selbst – dieselben, die Sie im Panel haben; er erhält sie zusammen mit der Konfiguration, für die Dauer eines Auftrags, und sie bleiben nicht in der Beschreibung der Migration zurück.
Die Adresse der Quelle wird geprüft, bevor sich der Server mit ihr verbindet. Wir weisen Adressen ab, die auf interne Netze und Metadatendienste zeigen – das ist der übliche Schutz vor dem Missbrauch eines Formulars, das definitionsgemäß eine beliebige URL vom Nutzer entgegennimmt.
Der Zielspeicher entsteht als gewöhnlicher Speicher, im Panel sichtbar und genauso zugänglich wie die übrigen: über den Browser, den Desktop-Client und über S3.

Der wichtigste Satz zur Abrechnung: Diese Funktion ist im Preis des Dienstes enthalten. Für den Transfer berechnen wir nichts – weder für das Volumen noch für die gewählte Geschwindigkeit; jede Organisation hat ein Kontingent kostenloser Migrationen, und wenn Sie weitere brauchen, genügt es, uns zu schreiben. Eine fehlgeschlagene oder angehaltene Migration verbraucht das Kontingent nicht, der Versuch lässt sich also ohne Kosten wiederholen – denken Sie nur daran, dass der Zielspeicher mit den bereits kopierten Dateien bestehen bleibt und auf Ihre Speicherung angerechnet wird; wenn Sie ihn nicht wollen, löschen Sie ihn einfach.

Man muss auch ehrlich sagen, was diese Funktion nicht ist. Es ist eine einmalige Kopie und keine kontinuierliche Replikation: Sie kopiert den aktuellen Stand des Quell-Buckets, wacht nicht endlos über ihn und überträgt keine Versionshistorie aus der Quelle. Wenn Sie eine laufend gepflegte Kopie brauchen, haben Sie in Files alles, was Methode 3 verlangt: Im Panel finden Sie die Adresse des Endpoints und die S3-Schlüssel, also funktionieren rclone, restic, Veeam, AWS CLI oder ein eigenes Skript mit Ihrem Speicher genauso wie mit jedem anderen S3 – in beide Richtungen. Das ist im Übrigen unsere Antwort auf die Frage nach dem Vendor-Lock-in: Mit denselben Werkzeugen, mit denen die Daten hineinkommen, kann man sie auch herausführen, ohne uns um einen Export zu bitten.

Die Schichten, die in WebDisk Files das Bild der zweiten Kopie vervollständigen:

Beständigkeit innerhalb des Clusters – jedes Objekt wird in drei Kopien auf getrennten Hosts unseres Ceph-Clusters gehalten, desselben, auf dem der Dienst Object Storage läuft. Das ist die Schicht aus dem vorherigen Abschnitt: Sie schützt vor dem Ausfall einer Festplatte und eines Knotens, nicht vor dem Löschen.
Versionierung – ein Schreibvorgang unter einem bestehenden Namen erzeugt eine neue Version, und die vorherigen bleiben zur Wiederherstellung verfügbar. Das ist der erste reale Schutz davor, dass „jemand die Datei überschrieben hat“.
Anti-Ransomware – ein Speicher der WORM-Klasse auf Basis von S3 Object Lock, in dem für einen gewählten Zeitraum (von 90 Tagen bis 7 Jahren) keine S3-Anfrage eine geschriebene Version löscht oder ändert. Das ist die Schicht, die eine Replikation niemals ersetzen wird – und umgekehrt: Die Replikation ist das, was Object Lock nicht leistet.
Verschlüsselung – SSE-S3 auf Ebene des Speichers oder SSE-C mit einem Schlüssel auf Ihrer Seite, zur Wahl, je nachdem, wer den Schlüssel halten soll.

Das Set, das wir Kunden mit einem realen Kontinuitätsanspruch in der Praxis empfehlen: Arbeitsdaten in Files, das Backup in einen separaten Speicher mit Anti-Ransomware (denn das löscht niemand) und – wenn das DR-Szenario es verlangt – eine dritte Kopie bei einem völlig anderen Anbieter, angefertigt mit rclone copy nach Zeitplan. Drei Kopien, zwei verschiedene Systeme, eine außerhalb unserer Infrastruktur – also die 3-2-1-Regel, nur in Konkreta ausbuchstabiert.

Häufige Fragen

Ersetzt die Replikation ein Backup? Nein, und das ist das Wichtigste, was man sich aus diesem Artikel merken sollte. Die Replikation hält eine Kopie im Einklang mit der Quelle, also vervielfältigt sie auch das Löschen, das Überschreiben und das Verschlüsseln der Dateien durch Ransomware. Zum Backup wird sie erst dann, wenn das Ziel Versionierung und eine Löschsperre hat – oder wenn die Replikation grundsätzlich nie etwas löscht.

Verlangsamt die Replikation die Schreibvorgänge in den Bucket? In den Methoden 1–4 nicht: Das Kopieren ist asynchron und geschieht nach der Bestätigung des Schreibvorgangs. Spürbar verlangsamt nur das Doppelschreiben in der Anwendung, denn dort wartet der Nutzer auf beide Speicher zugleich.

Wie lange dauert die Übertragung von 10 TB? Die Arithmetik ist unbarmherzig: Bei 50 MB/s sind das etwa zweieinhalb Tage ununterbrochener Übertragung, bei der höchsten Geschwindigkeitsstufe – gut ein Dutzend Stunden. In der Praxis ist der Engpass oft nicht das Bandbreitenlimit, sondern die Quelle (Anfragelimits beim Anbieter) oder die Zahl der Objekte: Eine Million kleiner Dateien kopiert sich deutlich länger als eine einzelne Datei derselben Gesamtgröße.

Lassen sich Daten von einem anderen Anbieter zu WebDisk replizieren? Ja – das ist genau die Aufgabe der Funktion „Bucket-Replikation“ im Files-Panel. Es genügen der Endpoint sowie der Zugriffs- und der geheime Schlüssel, mit denen die Liste der Quell-Buckets sichtbar ist; den Rest erledigen wir auf unserer Seite, und Sie sehen dem Fortschrittsbalken zu. Die Gegenrichtung ist ebenfalls offen: Die S3-Schlüssel zu Ihrem Speicher haben Sie im Panel.

Überträgt die Replikation die Versionshistorie der Dateien? Die native Replikation in S3 und multisite – ja, denn sie arbeiten mit Versionen. Werkzeuge wie rclone oder aws s3 sync – nein: Sie kopieren den aktuellen Stand der Objekte. Wenn die Historie die Migration überleben soll, muss man das separat planen; häufiger löst man es so, dass die Historie das Backup hält und nicht das Replikat.

Was ist mit verschlüsselten Dateien – kopieren sie sich überhaupt? Das hängt davon ab, wer den Schlüssel hat, und von der Plattform. Bei der serverseitigen Verschlüsselung (SSE-S3, SSE-KMS) ist das Kopieren selbst transparent – mit zwei Vorbehalten: In der nativen AWS-Replikation muss man SSE-KMS-Objekte ausdrücklich in der Regel zulassen und einen Schlüssel in der Zielregion angeben (siehe Fallstrick 4), und in Ceph RGW ist das serverseitige Kopieren verschlüsselter Objekte schlicht nicht implementiert. Bei der Verschlüsselung mit einem Kundenschlüssel (SSE-C) muss jede Kopie durch einen Prozess laufen, der den Schlüssel kennt – deshalb kopiert man solche Objekte mit einem Werkzeug, das den Schlüssel hat, und nicht mit dem Befehl „serverseitig kopieren“.

Wie prüft man, dass die Kopie vollständig ist? Durch Vergleich, nicht durch Vertrauen. Das Minimum ist die Übereinstimmung der Objektanzahl und der Gesamtgröße auf beiden Seiten; die ernsthafte Variante ist rclone check --checksum (Vergleich der Prüfsummen) oder, bei nativer Replikation, die Prüfung des Replikationsstatus der Objekte und der Verzögerungsmetriken. Eine Migration ohne eine solche Abnahme ist nicht abgeschlossen.

Was kostet es, eine zweite Kopie zu unterhalten? Drei Posten und nicht einer: die Speicherung auf der anderen Seite, die Gebühren für Anfragen und der ausgehende Datenverkehr aus der Quelle – Letzteren zahlen Sie bei jedem Zyklus und nicht ein einziges Mal. Bei kontinuierlicher Replikation rechnen Sie ihn vom Volumen der Änderungen, bei einer Migration – von den gesamten Daten. Eine Kopie beim selben Anbieter ist beim Transfer mitunter kostenlos, eine Kopie „nach außen“ nie.

Womit soll man anfangen, wenn wir heute überhaupt keine zweite Kopie haben? Mit dem günstigsten Schritt, der am meisten bringt: Aktivieren Sie die Versionierung dort, wo die Arbeitsdaten liegen, und lenken Sie die Backups in einen separaten Speicher mit Löschsperre. Erst danach fügen Sie die Replikation hinzu – und wählen Sie sie zu dem Problem, das Sie wirklich haben (Migration, DR, geografische Nähe), und nicht zu einem Schlagwort.

Ist eine Kopie im zweiten Rechenzentrum im Preis enthalten? Trennen wir zwei Dinge. Im Preis enthalten ist die Beständigkeit innerhalb des Clusters (drei Kopien jedes Objekts auf getrennten Hosts), und im Preis enthalten ist die Migration der Daten zu WebDisk. Eine Kopie außerhalb unserer Infrastruktur ist ein eigenes DR-Szenario – Sie können sie selbst anfertigen, mit den S3-Schlüsseln aus dem Panel und einem beliebigen Werkzeug, oder sich bei uns melden und das gemeinsam entwerfen. Wir sagen das lieber offen, als das Wort „Replikation“ als ein Versprechen zu verkaufen, das bei jedem Anbieter etwas anderes bedeutet.

Fazit

Die S3-Bucket-Replikation ist nicht eine einzelne Technologie, sondern fünf Lösungsfamilien mit unterschiedlichen Einstiegskosten und unterschiedlicher Bestimmung: eine Regel im Speicher selbst, die Cluster-Replikation, das Kopieren mit Werkzeugen, ein ereignisgesteuerter Worker und das Doppelschreiben in der Anwendung. Die Wahl zwischen ihnen entscheiden vier Fragen – nach dem zulässigen Datenverlust, danach, ob beide Enden beim selben Anbieter liegen, nach der Versionshistorie und danach, wer für den Transfer zahlt.

Drei Dinge sollte man sich merken:

ein Replikat ist getreu, und Treue kann ein Mangel sein – das Löschen und das Verschlüsseln propagieren zusammen mit den Daten, also muss man die zweite Kopie mit Versionierung und Schreibsperre härten, wenn sie einen schlechten Tag überstehen soll,
eine Migration endet mit der Verifikation, nicht mit der Meldung „fertig“ – Prüfsummen, Objektanzahl, Größe; und bei der Gelegenheit die Wiederherstellung der Richtlinien, der Lifecycle-Regeln und von CORS, die nicht zusammen mit den Objekten mitfahren,
die Replikation wählt man zu einem Problem und nicht zu einem Schlagwort – dasselbe Wort bedeutet bei einer Migration, bei DR und beim Schutz vor Ransomware etwas völlig anderes.

In WebDisk Files haben Sie die Migration aus einem beliebigen S3-kompatiblen Speicher fertig im Panel – Bucket-Replikation, mit Fortschrittsanzeige, mit der Möglichkeit anzuhalten und ohne zusätzliche Gebühr. Testen Sie WebDisk Files oder schreiben Sie uns, wenn Sie die Architektur der zweiten Kopie für Ihre Daten durchsprechen wollen: Wir beraten Sie auch dann, wenn sich eine Kopie außerhalb unserer Infrastruktur als beste Lösung erweist.

Dieser Artikel ist Teil einer Serie über Datensicherheit in den WebDisk-Diensten – zuvor schrieben wir über die Grundlagen von Object Storage, die Verschlüsselung im Ruhezustand (SSE-S3, SSE-KMS, SSE-C), den Zugriff via STS/SSO und über unveränderliche Kopien mit Object Lock. Die Beispiele können Sie auf jeder S3-kompatiblen Plattform ausführen; der Parameter --endpoint-url in der aws CLI verweist auf den Endpoint Ihres Anbieters.

S3-Bucket-Replikation: fünf Wege zur zweiten Kopie – und was keiner davon löst