Objektreplikation für Blockblobs

Die Objektreplikation kopiert asynchron Block-Blobs zwischen einem Quellspeicherkonto und einem Zielkonto. Folgende Szenarien werden unter anderem von der Objektreplikation unterstützt:

• Minimieren der Latenz. Die Objektreplikation kann die Wartezeit für Leseanforderungen verringern, indem Clients die Nutzung von Daten aus einer Region ermöglicht wird, die sich in größerer physischer Nähe befindet.
• Erhöhen der Effizienz für Computeworkloads. Bei der Objektreplikation können Computeworkloads dieselben Sätze von Blockblobs in verschiedenen Regionen verarbeiten.
• Optimieren der Datenverteilung. Sie können Daten an einem einzelnen Ort verarbeiten oder analysieren und dann nur die Ergebnisse in zusätzliche Regionen replizieren.
• Optimieren der Kosten. Nachdem Ihre Daten repliziert wurden, können Sie die Kosten reduzieren, indem Sie sie mithilfe von Lebenszyklusverwaltungsrichtlinien in die Archivebene verschieben.

Das folgende Diagramm zeigt, wie die Objektreplikation Blockblobs aus einem Quellspeicherkonto in einer Region in Zielkonten in zwei verschiedenen Regionen repliziert.

Informationen zum Konfigurieren der Objektreplikation finden Sie unter Konfigurieren der Objektreplikation.

Voraussetzungen und Vorbehalte für die Objektreplikation

Für die Objektreplikation müssen auch die folgenden Azure Storage Funktionen aktiviert sein:

• Change feed: Muss für das Quellkonto aktiviert sein. Informationen zum Aktivieren des Änderungsfeeds finden Sie unter Enable und Deaktivieren des Änderungsfeeds.
• Blobversionsverwaltung: Muss für das Quell- und das Zielkonto aktiviert sein. Informationen zum Aktivieren der Versionsverwaltung finden Sie unter Aktivieren und Verwalten der Blobversionsverwaltung.

Das Aktivieren von Änderungsfeeds und blob-Versionsverwaltung kann zusätzliche Kosten verursachen. Weitere Informationen finden Sie auf der Azure Storage Preisseite.

Die Objektreplikation wird für allgemeine v2-Speicherkonten und Premium-Blockblob-Konten unterstützt. Sowohl Quell- als auch Zielkonten müssen Blockblobkonten des Typs „Universell V2“ oder „Premium“ sein. Die Objektreplikation unterstützt nur Blockblobs. Anfügeblobs und Seitenblobs werden nicht unterstützt.

Die Objektreplikation wird für Konten unterstützt, die mit entweder von Microsoft oder kundenseitig verwalteten Schlüsseln verschlüsselt sind. Weitere Informationen zu vom Kunden verwalteten Schlüsseln finden Sie unter Customer-managed keys for Azure Storage encryption.

Die Objektreplikation wird für Blobs im Quellkonto, die mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt sind, nicht unterstützt. Weitere Informationen zu vom Kunden bereitgestellten Schlüsseln finden Sie unter Verschlüsselungsschlüssel für eine Anfrage an den Blob-Speicher bereitstellen.

Ein vom Kunden verwalteter Failover wird weder für das Quell- noch für das Zielkonto in einer Objektreplikationsrichtlinie unterstützt.

Die Objektreplikation wird in Konten mit aktiviertem hierarchischen Namespace noch nicht unterstützt.

Die Objektreplikation wird für Blobs, die mit Data Lake Storage-APIs hochgeladen werden, nicht unterstützt.

Funktionsweise der Objektreplikation

Bei der Objektreplikation werden Blockblobs in einem Container entsprechend den von Ihnen konfigurierten Regeln asynchron kopiert. Der Inhalt des Blobs, alle dem Blob zugeordneten Versionen sowie die Metadaten und Eigenschaften des Blobs werden aus dem Quellcontainer in den Zielcontainer kopiert.

Blobversionsverwaltung

Die Objektreplikation erfordert, dass die Blobversionsverwaltung sowohl für das Quell- als auch das Zielkonto aktiviert ist. Wenn ein repliziertes Blob im Quellkonto geändert wird, wird vor der Änderung eine neue Blobversion im Quellkonto erstellt, die den vorherigen Zustand des Blobs widerspiegelt. Die aktuelle Version im Quellkonto spiegelt die neuesten Updates wider. Sowohl die aktuelle Version als auch vorherige Versionen werden in das Zielkonto repliziert. Weitere Informationen zur Auswirkung von Schreibvorgängen auf Blobversionen finden Sie unter Versionsverwaltung für Schreibvorgänge.

Wenn Ihr Speicherkonto Objektreplikationsrichtlinien in Kraft hat, können Sie die Versionierung von Blobs für dieses Konto nicht deaktivieren. Sie müssen alle Objektreplikationsrichtlinien für das Konto löschen, bevor Sie die Blobversionsverwaltung deaktivieren.

Löschen eines Blobs im Quellkonto

Wenn ein Blob im Quellkonto gelöscht wird, wird die aktuelle Version des Blobs zu einer früheren Version, und es gibt keine aktuelle Version mehr. Alle vorhandenen vorherigen Versionen des Blobs bleiben erhalten. Dieser Status wird in das Zielkonto repliziert. Weitere Informationen zur Auswirkung von Löschvorgängen auf Blobversionen finden Sie unter Versionsverwaltung für Löschvorgänge.

Momentaufnahmen

Die Objektreplikation unterstützt keine Blobmomentaufnahmen. Beliebige Momentaufnahmen eines Blobs im Quellkonto werden nicht in das Zielkonto repliziert.

Blobindextags

Die Objektreplikation unterstützt jetzt das Kopieren von Indextags aus Quell-Blobs in Ziel-Blobs. Sie können diese Funktion als Teil einer neuen oder vorhandenen Replikationsregel konfigurieren. Weitere Informationen finden Sie unter Konfigurieren der Objektreplikation.

Blobtiering

Die Objektreplikation wird unterstützt, wenn sich die Quell- und Zielkonten in einer beliebigen Onlineebene befinden (heiß, kühl oder kalt). Die Quell- und Zielkonten können sich in verschiedenen Ebenen befinden. Die Objektreplikation schlägt jedoch ein fehl, wenn ein Blob im Quell- oder Zielkonto in die Archivzugriffsebene verschoben wird. Weitere Informationen zu Blobspeicherebenen finden Sie unter Einstufungen des Datenzugriffs für Blobdaten.

Unveränderliche Blobs

Unveränderliche Regeln für Azure Blob Storage umfassen zeitbasierte Aufbewahrungsrichtlinien und rechtliche Aufbewahrungen. Wenn eine Unveränderlichkeitsrichtlinie für das Zielkonto wirksam ist, kann die Objektreplikation betroffen sein. Weitere Informationen zu Unveränderlichkeitsrichtlinien finden Sie unter Speicherung geschäftskritischer BLOB-Daten mit unveränderbarem Speicher.

Wenn der Zielcontainer über eine Richtlinie zur Unveränderlichkeit auf Containerebene verfügt, können Änderungen an Objekten im Quellcontainer, z. B. Aktualisierungen oder Löschungen, weiterhin erfolgreich sein. Diese Änderungen können jedoch aufgrund der Unveränderlichkeitseinschränkung möglicherweise nicht in den Zielcontainer repliziert werden. Weitere Informationen dazu, welche Vorgänge mit einer Unveränderlichkeitsrichtlinie, die einem Container zugeordnet ist, nicht zulässig sind, finden Sie unter Szenarien mit Bereich auf Containerebene.

Wenn eine Blob-Version eines Zielkontos über eine aktive Richtlinie für die Unveränderlichkeit auf Versionsebene verfügt, kann ein Lösch- oder Aktualisierungsvorgang, der für die Blob-Version des entsprechenden Quellcontainers ausgeführt wird, erfolgreich sein. Die Replikation dieses Vorgangs auf das Zielobjekt schlägt jedoch fehl. Weitere Informationen dazu, welche Vorgänge mit einer Unveränderlichkeitsrichtlinie, die einem Container zugeordnet ist, nicht zulässig sind, finden Sie unter Szenarien mit Bereich auf Versionsebene.

Objektreplikationsrichtlinien und -regeln

Wenn Sie die Objektreplikation konfigurieren, erstellen Sie eine Replikationsrichtlinie, die das Quellspeicherkonto und das Zielkonto angibt. Eine Replikationsrichtlinie enthält eine oder mehrere Regeln, die einen Quell- und Zielcontainer angeben und angeben, welche Quell-BLOBs repliziert werden.

Nachdem Sie die Objektreplikation konfiguriert haben, überprüft Azure Storage den Änderungsfeed für das Quellkonto regelmäßig und repliziert asynchron alle Schreib- oder Löschvorgänge in das Zielkonto. Die Replikationswartezeit hängt von der Größe des Blockblobs ab, das repliziert wird.

Replikationsrichtlinien

Wenn Sie die Objektreplikation konfigurieren, erstellen Sie eine Replikationsrichtlinie für das Zielkonto über den Azure Storage Ressourcenanbieter. Nachdem die Replikationsrichtlinie erstellt wurde, weist Azure Storage sie einer Richtlinien-ID zu. Anschließend müssen Sie diese Replikationsrichtlinie dem Quellkonto mithilfe der Richtlinien-ID zuordnen. Die Richtlinien-ID muss für das Quell- und das Zielkonto identisch sein, damit die Replikation stattfinden kann.

Ein Quellkonto kann in maximal zwei Zielkonten repliziert werden, mit einer einzigen Richtlinie für jedes Zielkonto. Ebenso kann ein Konto als Zielkonto für nicht mehr als zwei Replikationsrichtlinien dienen.

Die Quell- und Zielkonten befinden sich möglicherweise in derselben Region oder in verschiedenen Regionen. Sie befinden sich möglicherweise auch im selben Abonnement oder in anderen Abonnements. Optional befinden sich die Quell- und Zielkonten möglicherweise in verschiedenen Microsoft Entra-Mandanten. Für jedes Quellkonto-/Zielkontopaar kann nur eine Replikationsrichtlinie erstellt werden.

Replikationsregeln

Replikationsregeln geben an, wie Azure Storage Blobs aus einem Quellcontainer in einen Zielcontainer repliziert. Sie können bis zu 1.000 Replikationsregeln für jede Replikationsrichtlinie angeben. Jede Replikationsregel definiert einen einzelnen Quell- und Zielcontainer, und jeder Quell- und Zielcontainer kann nur in einer Regel verwendet werden. Daher können maximal 1.000 Quellcontainer und 1.000 Zielcontainer an einer einzigen Replikationsrichtlinie teilnehmen.

Nachdem Sie eine Replikationsregel erstellt haben, werden vorhandene Blobs ignoriert. Nur neue Block-Blobs, die nach Erstellen der Regel hinzugefügt werden, werden standardmäßig kopiert. Sie können jedoch angeben, dass sowohl neue als auch vorhandene Blockblobs kopiert werden. Sie können auch einen benutzerdefinierten Kopierbereich definieren, der alle block-Blobs kopiert, die nach einer bestimmten Zeit erstellt wurden.

Sie können ferner einen oder mehrere Filter als Teil einer Replikationsregel angeben, um Blockblobs anhand eines Präfixes zu filtern. Wenn Sie ein Präfix angeben, werden nur Blobs, die mit diesem Präfix im Quellcontainer übereinstimmen, in den Zielcontainer kopiert.

Die Quell- und Zielcontainer müssen beide vorhanden sein, bevor Sie sie in einer Regel angeben können. Nachdem Sie die Replikationsrichtlinie erstellt haben, sind Schreibvorgänge im Zielcontainer nicht zulässig. Alle Versuche, in den Zielcontainer zu schreiben, schlagen mit dem Fehlercode 409 (Konflikt) fehl.

Um in einen Zielcontainer mit einer Replikationsregel zu schreiben, müssen Sie zuerst die Replikation deaktivieren. Sie können die Regel deaktivieren, indem Sie sie entweder für diesen Container löschen oder die gesamte Replikationsrichtlinie entfernen.

Lese- und Löschvorgänge im Zielcontainer sind zulässig, wenn die Replikationsrichtlinie aktiv ist.

Sie können den Vorgang Blobebene festlegen für einen Blob im Zielcontainer aufrufen, um ihn auf die Archivebene zu verschieben. Weitere Informationen zur Archivebene finden Sie unter Zugriffsebenen für Blob-Daten.

Richtliniendefinitionsdatei

Eine JSON-Datei wird verwendet, um eine Objektreplikationsrichtlinie zu definieren. Sie können die Richtliniendefinitionsdatei aus einer vorhandenen Objektreplikationsrichtlinie abrufen oder eine Objektreplikationsrichtlinie erstellen, indem Sie eine Richtliniendefinitionsdatei hochladen.

Beispiel für eine Richtliniendefinitionsdatei

Im folgenden Beispiel wird eine Replikationsrichtlinie für das Zielkonto mit einer Regel festgelegt. Die Regel zielt auf Blobs mit dem Präfix b ab und gibt eine minimale Erstellungszeit für die Replikation an. Denken Sie daran, die Werte in eckigen Klammern durch Ihre eigenen Werte zu ersetzen:

{
  "properties": {
    "policyId": "default",
    "sourceAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "destinationAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-28T00:00:00Z"
        }
      }
    ]
  }
}

Geben Sie vollständige Ressourcen-IDs für Quell- und Zielkonten an.

Wenn Sie die Richtliniendefinitionsdatei erstellen, geben Sie die vollständigen Azure Resource Manager Ressourcen-IDs für die Einträge sourceAccount und destinationAccount an, wie im Beispiel im vorherigen Abschnitt gezeigt. Informationen zum Suchen der Ressourcen-ID für ein Speicherkonto finden Sie unter Die Ressourcen-ID für ein Speicherkonto abrufen.

Die vollständige Ressourcen-ID weist folgendes Format auf:

/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>

Die Richtliniendefinitionsdatei erforderte zuvor nur den Kontonamen anstelle der vollständigen Ressourcen-ID für das Speicherkonto. Mit der Einführung der AllowCrossTenantReplication Sicherheitseigenschaft in Version 2021-02-01 der REST-API des Azure Storage-Ressourcenanbieters müssen Sie nun die vollständige Ressourcen-ID für alle Objektreplikationsrichtlinien bereitstellen, die erstellt werden, wenn die mandantenübergreifende Replikation für ein storage Konto nicht zulässig ist, das an der Replikationsrichtlinie teilnimmt. Azure Storage verwendet die vollständige Ressourcen-ID, um zu überprüfen, ob sich die Quell- und Zielkonten im selben Mandanten befinden. Weitere Informationen zum Verhindern mandantenübergreifender Replikationsrichtlinien finden Sie unter Verhinderung der Replikation über Microsoft Entra-Mandanten.

Obwohl die Verwendung nur des Kontonamens für die mandantenübergreifende Replikation weiterhin unterstützt wird, empfiehlt Microsoft die Verwendung der vollständigen Ressourcen-ID als bewährte Methode. Alle vorherigen Versionen der REST-API des Azure Storage Ressourcenanbieters unterstützen den vollständigen Ressourcen-ID-Pfad in Objektreplikationsrichtlinien.

Die folgende Tabelle zeigt, wie sich das Verhalten der Replikationsrichtlinie unterscheidet, wenn Sie eine vollständige Ressourcen-ID im Vergleich zu einem Kontonamen verwenden. Der Vergleich hängt davon ab, ob die mandantenübergreifende Replikation für das Speicherkonto zulässig ist.

Angeben der Richtlinien- und Regel-IDs

In der folgenden Tabelle sind die Werte zusammengefasst, die in den einzelnen Szenarien in der Richtliniendefinitionsdatei für policyId und ruleId verwendet werden müssen.

Verhindern der Replikation über Microsoft Entra-Mandanten hinweg

Ein Microsoft Entra-Mandant ist eine dedizierte Instanz von Microsoft Entra ID, die eine Organisation für Identitäts- und Zugriffsverwaltung darstellt. Jedes Azure-Abonnement verfügt über eine Vertrauensstellung mit einem einzelnen Microsoft Entra-Mandanten. Alle Ressourcen in einem Abonnement, einschließlich Speicherkonten, sind einem derselben Microsoft Entra-Mandanten zugeordnet. Weitere Informationen finden Sie unter What is Microsoft Entra ID?

Standardmäßig ist die mandantenübergreifende Replikation für neue Konten deaktiviert, die ab dem 15. Dezember 2023 erstellt wurden. Wenn Ihre Sicherheitsrichtlinien erfordern, dass Sie die Objektreplikation auf Storage-Konten beschränken, die sich ausschließlich innerhalb desselben Mandanten befinden, können Sie die Replikation über Mandanten hinweg verbieten, indem Sie die Sicherheitseigenschaft AllowCrossTenantReplication-Eigenschaft (Vorschau) festlegen. Wenn Sie die mandantenübergreifende Objektreplikation für ein Speicherkonto deaktivieren, gilt eine zusätzliche Anforderung von Azure Storage. Für jede Objekt-Replikationsrichtlinie, die dieses Speicherkonto als Quelle oder Ziel verwendet, müssen beide Konten zum gleichen Microsoft Entra-Mandanten gehören. Weitere Informationen zum Verhindern der mandantenübergreifenden Objektreplikation finden Sie unter Verhindern der Objektreplikation zwischen Microsoft Entra-Mandanten.

Um die Mandanten-übergreifende Objektreplikation für ein Speicherkonto zu verbieten, legen Sie die Eigenschaft AllowCrossTenantReplication auf false fest. Wenn das storage Konto derzeit nicht an mandantenübergreifenden Objektreplikationsrichtlinien teilnimmt, wird durch Festlegen der AllowCrossTenantReplication-Eigenschaft auf false verhindert, dass zukünftige Konfiguration von mandantenübergreifenden Objektreplikationsrichtlinien mit diesem storage Konto als Quelle oder Ziel festgelegt wird.

Wenn das Speicherkonto derzeit an einer oder mehreren mandantenübergreifenden Objektreplikationsrichtlinien teilnimmt, ist das Festlegen der Eigenschaft AllowCrossTenantReplication auf false nicht zulässig. Sie müssen die vorhandenen mandantenübergreifenden Richtlinien löschen, bevor Sie die mandantenübergreifende Replikation unterbinden können.

Standardmäßig ist die Eigenschaft AllowCrossTenantReplication für ein Speicherkonto, das ab dem 15. Dezember 2023 erstellt wird, auf "false" festgelegt. Für Speicherkonten, die vor dem 15. Dezember 2023 erstellt wurden, ist der Wert der AllowCrossTenantReplication-Eigenschaft eines Speicherkontos null oder true, dann können autorisierte Benutzer mandantenübergreifend Objektreplikationsrichtlinien mit diesem Konto als Quelle oder Ziel konfigurieren. Weitere Informationen zum Konfigurieren mandantenübergreifender Richtlinien finden Sie unter Konfigurieren der Objektreplikation für Blockblobs.

Sie können Azure Policy verwenden, um eine Reihe von Speicherkonten zu überwachen, um sicherzustellen, dass die AllowCrossTenantReplication-Eigenschaft festgelegt ist, um eine mandantenübergreifende Objektreplikation zu verhindern. Sie können auch Azure Policy verwenden, um Governance für eine Gruppe von Speicherkonten zu erzwingen. Sie können beispielsweise eine Richtlinie mit dem deny-Effekt erstellen, um zu verhindern, dass ein Benutzer ein Speicherkonto erstellt, bei dem die AllowCrossTenantReplication-Eigenschaft auf true festgelegt ist, oder dass ein Benutzer ein vorhandenes Speicherkonto ändert, um den Eigenschaftswert in true zu ändern.

Replikationsmetriken

Die Objektreplikation unterstützt zwei Metriken, um Ihnen Einblicke in den Replikationsfortschritt zu bieten:

• Operationen, die für die Replikation ausstehen: Gesamtanzahl der Vorgänge, die pro Zeitintervall von der Quell- zu Ziel-Speicherkonto-Replikation registriert werden.
• Bytes ausstehend für die Replikation: Summe der ausstehenden Bytes von der Quelldatenspeicherkonten bis zu den Zieldatenspeicherkonten, die pro Zeitintervall übermittelt werden.

Jede der zuvor aufgeführten Metriken kann mit der Dimension von Zeit-Buckets angezeigt werden. Diese Aufschlüsselung ermöglicht Einblicke in die Anzahl von Bytes oder Vorgängen, für welche die Replikation pro Zeitabschnitt ausstehen, wie folgt:

• 0-5 Minuten
• 5-10 Minuten
• 10-15 Minuten
• 15-30 Minuten
• 30 Minuten-2 Stunden
• 2-8 Stunden
• 8-24 Stunden
• >24 Stunden

Das folgende Beispielbild zeigt die Metrik für den ausstehenden Vorgang und die Bytes der vorherigen sieben Tage.

Sie können Replikationsmetriken für das Quellkonto für die Überwachung ausstehender Bytes und ausstehender Vorgänge aktivieren. Weitere Informationen finden Sie unter Konfigurieren von Replikationsmetriken.

Replikationsstatus

Sie können den Replikationsstatus für ein Blob im Quellkonto überprüfen. Weitere Informationen finden Sie unter Überprüfen des Replikationsstatus eines Blobs.

Wenn der Replikationsstatus für ein Blob im Quellkonto auf einen Fehler hinweist, untersuchen Sie die folgenden möglichen Ursachen:

• Stellen Sie sicher, dass die Objektreplikationsrichtlinie im Zielkonto konfiguriert ist.
• Überprüfen Sie, ob das Zielkonto noch existiert.
• Überprüfen Sie, ob der Zielcontainer noch vorhanden ist.
• Stellen Sie sicher, dass der Zielcontainer nicht gelöscht wurde und sich nicht im Prozess der Löschung befindet. Das Löschen eines Containers kann bis zu 30 Sekunden dauern.
• Überprüfen Sie, ob der Zielcontainer weiterhin an der Richtlinie für die Objektreplikation teilnimmt.
• Wenn das Quell-BLOB mit einem vom Kunden bereitgestellten Schlüssel als Teil eines Schreibvorgangs verschlüsselt ist, schlägt die Objektreplikation fehl. Weitere Informationen zu vom Kunden bereitgestellten Schlüsseln finden Sie unter Verschlüsselungsschlüssel für eine Anfrage an den Blob-Speicher bereitstellen.
• Überprüfen Sie, ob das Quell- oder Ziel-BLOB auf die Archivebene verschoben wird. Archivierte Blobs können nicht über die Objektreplikation repliziert werden. Weitere Informationen zur Archivebene finden Sie unter Zugriffsebenen für Blob-Daten.
• Stellen Sie sicher, dass der Zielcontainer oder Blob nicht durch eine Unveränderbarkeitsrichtlinie geschützt ist. Denken Sie daran, dass ein Container oder Blob eine Unveränderlichkeitsrichtlinie von seinem übergeordneten Element erben kann. Weitere Informationen zu Unveränderlichkeitsrichtlinien finden Sie unter Übersicht über unveränderlichen Speicher für Blob-Daten.

Featureunterstützung

Die Unterstützung für dieses Feature kann durch aktivieren von Data Lake Storage Gen2, Network File System (NFS) 3.0-Protokoll oder dem SSH File Transfer Protocol (SFTP) beeinträchtigt werden. Wenn Sie eine dieser Funktionen aktiviert haben, lesen Sie Blob Storage Featureunterstützung in Azure Storage Konten um die Unterstützung für dieses Feature zu bewerten.

Abrechnung

Es gibt keine Kosten zum Konfigurieren der Objektreplikation, einschließlich der Aufgabe, den Änderungsfeed zu aktivieren, die Versionsverwaltung zu aktivieren und Replikationsrichtlinien hinzuzufügen. Bei der Objektreplikation entstehen jedoch Kosten für Lese- und Schreibvorgänge für die Quell- und Zielkonten. Kosten für die Replikation von Daten vom Quellkonto auf das Zielkonto entstehen ebenfalls, wie auch Lesekosten bei der Verarbeitung des Änderungsfeeds.

Hier sehen Sie eine Aufschlüsselung der Kosten. Informationen zum Preis der einzelnen Kostenkomponenten finden Sie unter Azure Blob Storage Pricing.

¹ Bei dem Quellkonto, wenn die Ebene eines Blobs oder einer Version unverändert ist, werden Sie für eindeutige Datenblöcke in diesem Blob, deren Versionen, in Rechnung gestellt. Siehe Preise und Abrechnung für Blobversionsverwaltung. Auf dem Zielkonto für eine Version werden Ihnen alle Blöcke einer Version in Rechnung gestellt, unabhängig davon, ob diese Blöcke eindeutig sind.

² Dies umfasst nur Blobversionen, die seit Abschluss der letzten Replikation erstellt wurden.

³ Die Objektreplikation kopiert die gesamte Version in das Ziel (nicht nur die eindeutigen Blöcke der Version). Diese Übertragung verursacht Kosten für den Netzwerkausgang. Siehe Bandwidth-Preise.

Nächste Schritte

• Konfigurieren der Objektreplikation
• Verhindern der Objektreplikation über Microsoft Entra-Mandanten hinweg
• Blob-Versionierung
• Change-Feed-Unterstützung in Azure Blob Storage