Freigeben über

Blob kopieren

Der Copy Blob Vorgang kopiert ein Blob in ein Ziel innerhalb des Speicherkontos.

In Version 2012-02-12 und höher kann die Quelle für einen Copy Blob Vorgang ein Blob mit Commit in einem beliebigen Azure-Speicherkonto sein.

Ab Version 2015-02-21 kann die Quelle für einen Copy Blob Vorgang eine Azure-Datei in einem beliebigen Azure-Speicherkonto sein.

Hinweis

Nur Speicherkonten, die am oder nach dem 7. Juni 2012 erstellt wurden, lassen das Kopieren aus einem Copy Blob anderen Speicherkonto zu.

Anfrage

Sie können die Copy Blob Anforderung wie folgt erstellen. Https wird empfohlen. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos, mycontainer durch den Namen Ihres Containers und myblob durch den Namen Ihres Zielblobs.

Ab Version 2013-08-15 können Sie eine SAS (Shared Access Signature) für das Zielblob angeben, wenn es sich im selben Konto wie das Quellblob befindet. Ab Version 2015-04-05 können Sie auch eine Shared Access Signature für das Zielblob angeben, wenn es sich in einem anderen Speicherkonto befindet.

Anforderungs-URI der PUT-Methode HTTP-Version
https://myaccount.blob.core.windows.net/mycontainer/myblob HTTP/1.1

URI für den emulierten Speicherdienst

Wenn Sie eine Anforderung an den emulierten Speicherdienst senden, geben Sie den Hostnamen des Emulators und den Azure Blob Storage-Port als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos:

Anforderungs-URI der PUT-Methode HTTP-Version
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob HTTP/1.1

Weitere Informationen finden Sie unter Verwenden des Azurite-Emulators für die lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können die folgenden zusätzlichen Parameter für den Anforderungs-URI angeben:

Parameter BESCHREIBUNG
timeout Wahlfrei. Der parameter timeout wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge.

Anforderungsheader

In der folgenden Tabelle werden die erforderlichen und optionalen Anforderungsheader beschrieben:

Anforderungs-Kopfzeile BESCHREIBUNG
Authorization Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date oder x-ms-date Erforderlich. Gibt die koordinierte Weltzeit (UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Erforderlich für alle autorisierten Anforderungen. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure Storage-Dienste.
x-ms-meta-name:value Wahlfrei. Gibt ein benutzerdefiniertes Name-Wert-Paar an, das dem Blob zugeordnet ist. Wenn keine Name-Wert-Paare angegeben sind, kopiert der Vorgang die Metadaten aus dem Quellblob oder der Quelldatei in das Zielblob. Wenn ein oder mehrere Name-Wert-Paare angegeben werden, wird das Zielblob mit den angegebenen Metadaten erstellt, und Metadaten werden nicht aus dem Quellblob oder der Quelldatei kopiert.

Ab Version 2009-09-19 müssen Metadatennamen den Benennungsregeln für C#-Bezeichner entsprechen. Weitere Informationen finden Sie unter Benennen und Verweisen auf Container, Blobs und Metadaten.
x-ms-tags Wahlfrei. Legt die angegebenen query-string-encoded-Tags für das Blob fest. Tags werden nicht aus der Kopierquelle kopiert. Weitere Informationen finden Sie unter Anmerkungen. Unterstützt in Version 2019-12-12 und höher.
x-ms-source-if-modified-since Wahlfrei. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um das Blob nur zu kopieren, wenn das Quellblob seit dem angegebenen Datum/der angegebenen Uhrzeit geändert wurde. Wenn das Quellblob nicht geändert wurde, gibt Blob Storage den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück. Sie können diesen Header nicht angeben, wenn es sich bei der Quelle um eine Azure-Datei handelt.
x-ms-source-if-unmodified-since Wahlfrei. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um den Blob nur zu kopieren, wenn das Quellblob seit dem angegebenen Datum/der angegebenen Uhrzeit nicht geändert wurde. Wenn das Quell-BLOB geändert wurde, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen). Sie können diesen Header nicht angeben, wenn es sich bei der Quelle um eine Azure-Datei handelt.
x-ms-source-if-match Wahlfrei. Ein ETag-Wert. Geben Sie diesen bedingten Header an, um das Quellblob nur dann zu kopieren, wenn sein ETag Wert mit dem angegebenen Wert übereinstimmt. Wenn die Werte nicht übereinstimmen, gibt Blob Storage den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück. Sie können diesen Header nicht angeben, wenn es sich bei der Quelle um eine Azure-Datei handelt.
x-ms-source-if-none-match Wahlfrei. Ein ETag-Wert. Geben Sie diesen bedingten Header an, um das Blob nur dann zu kopieren, wenn sein ETag Wert nicht mit dem angegebenen Wert übereinstimmt. Wenn die Werte identisch sind, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen). Sie können diesen Header nicht angeben, wenn es sich bei der Quelle um eine Azure-Datei handelt.
If-Modified-Since Wahlfrei. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um den Blob nur zu kopieren, wenn das Ziel-BLOB seit dem angegebenen Datum/der angegebenen Uhrzeit geändert wurde. Wenn das Zielblob nicht geändert wurde, gibt Blob Storage den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück.
If-Unmodified-Since Wahlfrei. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um den Blob nur zu kopieren, wenn das Ziel-BLOB seit dem angegebenen Datum/der angegebenen Uhrzeit nicht geändert wurde. Wenn das Ziel-BLOB geändert wurde, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen).
If-Match Wahlfrei. Ein ETag-Wert. Geben Sie einen ETag Wert für diesen bedingten Header an, um das Blob nur dann zu kopieren, wenn der angegebene ETag Wert mit dem ETag Wert für ein vorhandenes Zielblob übereinstimmt. Wenn die Werte nicht übereinstimmen, gibt Blob Storage den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück.
If-None-Match Wahlfrei. Ein ETag Wert oder das Platzhalterzeichen (*).

Geben Sie einen ETag Wert für diesen bedingten Header an, um das Blob nur dann zu kopieren, wenn der angegebene ETag Wert nicht mit dem ETag Wert für das Zielblob übereinstimmt.

Geben Sie das Platzhalterzeichen (*) an, um den Vorgang nur auszuführen, wenn das Ziel-BLOB nicht vorhanden ist.

Wenn die angegebene Bedingung nicht erfüllt ist, gibt Blob Storage den Statuscode 412 zurück (Vorbedingung fehlgeschlagen).
x-ms-copy-source:name Erforderlich. Gibt den Namen des Quellblobs oder der Quelldatei an.

Ab Version 2012-02-12 kann dieser Wert eine URL mit einer Länge von bis zu 2 Kibibyte (KiB) sein, die ein Blob angibt. Der Wert sollte URL-codiert sein, wie er in einem Anforderungs-URI angezeigt wird.

Der Lesevorgang für ein Quellblob im selben Speicherkonto kann über einen freigegebenen Schlüssel autorisiert werden. Ab Version 2017-11-09 können Sie auch Microsoft Entra ID verwenden, um den Lesevorgang für das Quellblob zu autorisieren. Wenn es sich bei der Quelle jedoch um ein Blob in einem anderen Speicherkonto handelt, muss das Quellblob öffentlich sein, oder der Zugriff darauf muss über eine Shared Access Signature autorisiert werden. Wenn das Quellblob öffentlich ist, ist keine Autorisierung erforderlich, um den Kopiervorgang auszuführen.

Ab Version 2015-02-21 kann das Quellobjekt eine Datei in Azure Files sein. Wenn es sich bei dem Quellobjekt um eine Datei handelt, die in ein Blob kopiert wird, muss die Quelldatei über eine Shared Access Signature autorisiert werden, unabhängig davon, ob sie sich im selben Konto oder in einem anderen Konto befindet.

Nur Speicherkonten, die am oder nach dem 7. Juni 2012 erstellt wurden, lassen das Kopieren aus einem Copy Blob anderen Speicherkonto zu.

Hier sind einige Beispiele für Quellobjekt-URLs:

- https://myaccount.blob.core.windows.net/mycontainer/myblob
- https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>
- https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>

Wenn es sich bei dem Quellobjekt um eine Datei in Azure Files handelt, verwendet die Quell-URL das folgende Format. Beachten Sie, dass die URL ein gültiges SAS-Token für die Datei enthalten muss.

- https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastoken

In Versionen vor dem 12.02.2012 können Blobs nur innerhalb desselben Kontos kopiert werden, und ein Quellname kann die folgenden Formate verwenden:

- Blob im benannten Container: /accountName/containerName/blobName
- Snapshot im benannten Container: /accountName/containerName/blobName?snapshot=<DateTime>
- Blob im Stammcontainer: /accountName/blobName
- Snapshot im Root-Container: /accountName/blobName?snapshot=<DateTime>
x-ms-lease-id:<ID> Erforderlich, wenn das Zielblob über eine aktive Lease verfügt. Die für diesen Header angegebene Lease-ID muss mit der Lease-ID des Ziel-BLOB übereinstimmen. Wenn die Anforderung nicht die Lease-ID enthält oder die ID ungültig ist, schlägt der Vorgang mit dem Statuscode 412 fehl (Vorbedingung fehlgeschlagen).

Wenn dieser Header angegeben ist und das Zielblob derzeit nicht über eine aktive Lease verfügt, schlägt der Vorgang mit dem Statuscode 412 (Vorbedingung fehlgeschlagen) fehl.

In Version 2012-02-12 und höher muss dieser Wert eine aktive unendliche Lease für ein geleastes Blob angeben. Eine Lease-ID mit begrenzter Dauer schlägt mit dem Statuscode 412 (Vorbedingung fehlgeschlagen) fehl.
x-ms-source-lease-id: <ID> Optional für Versionen vor 2012-02-12 (nicht unterstützt in 2012-02-12 und höher). Geben Sie diesen Header an, um den Copy Blob Vorgang nur auszuführen, wenn die angegebene Lease-ID mit der aktiven Lease-ID des Quellblobs übereinstimmt.

Wenn dieser Header angegeben ist und das Quellblob derzeit nicht über eine aktive Lease verfügt, schlägt der Vorgang mit dem Statuscode 412 (Fehler bei der Vorbedingung) fehl.
x-ms-client-request-id Wahlfrei. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Grenzwert von 1-KiB-Zeichen bereit, der bei der Konfiguration der Protokollierung in den Protokollen aufgezeichnet wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt.
x-ms-access-tier Wahlfrei. Gibt die Ebene an, die für das Zielblob festgelegt werden soll. Dieser Header gilt nur für Seitenblobs in einem Premium-Konto mit Version 2017-04-17 und höher. Eine vollständige Liste der unterstützten Tarife finden Sie unter Hochleistungsspeicher Premium und verwaltete Datenträger für VMs. Dieser Header wird in Version 2018-11-09 und höher für Blockblobs unterstützt. Blockblobtiering wird für Blob Storage- oder Universell v2-Konten unterstützt. Gültige Werte sind Hot, Coolund ColdArchive. Hinweis:Cold Ebene wird für Version 2021-12-02 und höher unterstützt. Ausführliche Informationen zum Blockblobtiering finden Sie unter Heiße, kalte und Archivspeicherebenen.
x-ms-rehydrate-priority Wahlfrei. Gibt die Priorität an, mit der ein archiviertes Blob rehydratiert werden soll. Dieser Header wird in Version 2019-02-02 und höher für Blockblobs unterstützt. Gültige Werte sind High und Standard. Sie können die Priorität für ein Blob nur einmal festlegen. Dieser Header wird bei nachfolgenden Anforderungen an dasselbe Blob ignoriert. Die Standardpriorität ohne diesen Header ist Standard.
x-ms-seal-blob Wahlfrei. Unterstützt in Version 2019-12-12 oder höher. Dieser Header ist nur für Anfügeblobs gültig. Das Zielblob wird versiegelt, nachdem der Kopiervorgang abgeschlossen ist.
x-ms-immutability-policy-until-date Version 2020-06-12 und höher. Gibt das Aufbewahrungsdatum an, das für das Blob festgelegt werden soll. Dies ist das Datum, bis zu dem das Blob vor Änderungen oder Löschungen geschützt werden kann. Es folgt RFC1123 Format.
x-ms-immutability-policy-mode Version 2020-06-12 und höher. Gibt den Unveränderlichkeitsrichtlinienmodus an, der für das Blob festgelegt werden soll. Gültige Werte sind unlocked und locked. Ein unlocked Wert gibt an, dass der Benutzer die Richtlinie ändern kann, indem er das Aufbewahrungsdatum erhöht oder verringert. Ein locked Wert gibt an, dass diese Aktionen verboten sind.
x-ms-legal-hold Version 2020-06-12 und höher. Gibt die gesetzliche Aufbewahrungspflicht an, die für das Blob festgelegt werden soll. Gültige Werte sind true und false.

Dieser Vorgang unterstützt den Erfolg der x-ms-if-tagsx-ms-source-if-tags und Header nur dann, wenn die angegebene Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge.

Anfragekörper

Keiner.

Antwort

Die Antwort enthält einen HTTP-Statuscode und eine Reihe von Antwortheadern.

Statuscode

In Version 2012-02-12 und höher gibt ein erfolgreicher Vorgang den Statuscode 202 (Akzeptiert) zurück.

In Versionen vor dem 12.02.2012 gibt ein erfolgreicher Vorgang den Statuscode 201 (Erstellt) zurück.

Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

Antwortkopfzeilen

Die Antwort für diesen Vorgang enthält die folgenden Header. Die Antwort kann auch zusätzliche Standard-HTTP-Header enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Antwortkopfzeile BESCHREIBUNG
ETag Wenn der Kopiervorgang in Version 2012-02-12 und höher abgeschlossen ist, enthält dieser Header den ETag Wert des Zielblobs. Wenn der Kopiervorgang nicht abgeschlossen ist, enthält der Header den ETag Wert des leeren Blobs, das zu Beginn des Kopiervorgangs erstellt wurde.

In Versionen vor dem 12.02.2012 gibt dieser Header den ETag Wert für das Zielblob zurück.

In Version 2011-08-18 und höher wird der ETag Wert in Anführungszeichen gesetzt.
Last-Modified Gibt das Datum/die Uhrzeit zurück, zu der der Kopiervorgang in das Zielblob abgeschlossen wurde.
x-ms-request-id Identifiziert eindeutig die Anforderung, die durchgeführt wurde. Sie können diesen Header verwenden, um die Anforderung zu beheben. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
x-ms-version Gibt die Version von Blob Storage an, die zum Ausführen der Anforderung verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die mit Version 2009-09-19 und höher vorgenommen wurden.
Date Ein UTC-Datums-/Uhrzeitwert, der die Uhrzeit angibt, zu der der Dienst die Antwort gesendet hat.
x-ms-copy-id: <id> Version 2012-02-12 und höher. Stellt einen Zeichenfolgenbezeichner für diesen Kopiervorgang bereit. Mit Get Blob oder Get Blob Properties können Sie den Status dieses Kopiervorgangs überprüfen oder an Abort Copy Blob übergeben, um einen ausstehenden Kopiervorgang abzubrechen.
x-ms-copy-status: <success ¦ pending> Version 2012-02-12 und höher. Gibt den Status des Kopiervorgangs mit den folgenden Werten an:

- success: Der Vorgang wurde erfolgreich abgeschlossen.
- pending: Der Vorgang wird ausgeführt.
x-ms-version-id: <DateTime> Version 2019-12-12 und höher. Identifiziert das Blob eindeutig anhand seiner Version. Sie können diesen undurchsichtigen Wert in nachfolgenden Anforderungen verwenden, um auf diese Version des Blobs zuzugreifen.
x-ms-client-request-id Kann verwendet werden, um Anfragen und entsprechende Antworten zu behandeln. Der Wert dieses Headers ist gleich dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist und der Wert höchstens 1.024 sichtbare ASCII-Zeichen aufweist. Wenn der x-ms-client-request-id-Header in der Anforderung nicht vorhanden ist, ist dieser Header in der Antwort nicht vorhanden.

Antwortkörper

Keiner.

Beispielantwort

Der folgende Code ist eine Beispielantwort für eine Anforderung zum Kopieren eines Blobs:

Response Status:  
HTTP/1.1 202 Accepted  
  
Response Headers:   
Last-Modified: <date>   
ETag: "0x8CEB669D794AFE2"  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2015-02-21  
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-copy-status: pending
x-ms-version-id: <DateTime>  
Date: <date>

Autorisierung

Die Autorisierung ist beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage erforderlich. In der folgenden Tabelle wird beschrieben, wie die Ziel- und Quellobjekte für einen Copy Blob Vorgang autorisiert werden können:

Objekttyp Microsoft Entra ID-Autorisierung SAS-Autorisierung (Shared Access Signature) Shared Key-Autorisierung (oder Shared Key Lite)
Zielblob Ja Ja Ja
Quellblob im selben Speicherkonto Ja Ja Ja
Quellblob in einem anderen Speicherkonto Nein Ja Nein

Wenn eine Anforderung Tags im x-ms-tags Anforderungsheader angibt, muss der Aufrufer die Autorisierungsanforderungen des Vorgangs Set Blob Tags erfüllen.

Sie können den Copy Blob Vorgang wie unten beschrieben autorisieren. Beachten Sie, dass ein Quellblob in einem anderen Speicherkonto separat über das SAS-Token mit der Berechtigung Read (r) autorisiert werden muss. Weitere Informationen zur Autorisierung von Quellblobs finden Sie in den Details zum Anforderungsheader x-ms-copy-source.

Von Bedeutung

Microsoft empfiehlt die Verwendung der Microsoft Entra-ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Die Microsoft Entra-ID bietet eine bessere Sicherheit und Benutzerfreundlichkeit im Vergleich zur Shared Key-Autorisierung.

Azure Storage unterstützt die Verwendung der Microsoft Entra-ID zum Autorisieren von Anforderungen an BLOB-Daten. Mit Der Microsoft Entra-ID können Sie azure role-based access control (Azure RBAC) verwenden, um Berechtigungen für einen Sicherheitsprinzipal zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine von Azure verwaltete Identität sein. Der Sicherheitsprinzipal wird von der Microsoft Entra-ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann dann verwendet werden, um eine Anforderung gegen den Blob-Dienst zu autorisieren.

Weitere Informationen zur Autorisierung mithilfe der Microsoft Entra-ID finden Sie unter Autorisieren des Zugriffs auf Blobs mithilfe von Microsoft Entra ID.

Erlaubnisse

Nachfolgend sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra-Benutzer, eine Gruppe, eine verwaltete Identität oder einen Dienstprinzipal erforderlich ist, um den Copy Blob Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle, die diese Aktion enthält:

Zielblob

Quellblob innerhalb desselben Speicherkontos

Weitere Informationen zum Zuweisen von Rollen mithilfe von Azure RBAC finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf BLOB-Daten.

Bemerkungen

In Version 2012-02-12 und höher kann der Copy Blob Vorgang asynchron beendet werden. Dieser Vorgang gibt eine Kopier-ID zurück, mit der Sie den Kopiervorgang überprüfen oder abbrechen können. Aufgrund der asynchronen Natur des Kopiervorgangs kopiert Blob Storage Blobs nach bestem Aufwand. Der Blob-Dienst kopiert Blobs, wenn die Serverressourcen nicht von anderen Aufgaben genutzt werden, sodass nicht garantiert werden kann, dass ein Kopiervorgang sofort gestartet oder in einem bestimmten Zeitrahmen abgeschlossen wird.

Bei dem Quellblob für einen Kopiervorgang kann es sich um ein Blockblob, ein Anfügeblob, ein Seitenblob oder eine Momentaufnahme handeln. Wenn das Zielblob bereits vorhanden ist, muss es vom gleichen Blobtyp wie das Quellblob sein. Alle vorhandenen Zielblobs werden überschrieben. Sie können das Zielblob nicht ändern, während ein Kopiervorgang ausgeführt wird.

In Version 2015-02-21 und höher kann die Quelle für den Kopiervorgang auch eine Datei in Azure Files sein. Wenn es sich bei der Quelle um eine Datei handelt, muss das Ziel ein Blockblob sein.

Mehrere ausstehende Copy Blob Vorgänge innerhalb eines Kontos können nacheinander verarbeitet werden. Ein Zielblob kann nur über einen ausstehenden Copy Blob Vorgang verfügen. Mit anderen Worten, ein Blob kann nicht das Ziel für mehrere ausstehende Copy Blob Vorgänge sein. Der Versuch, ein Blob in ein Zielblob zu kopieren, für das bereits ein Kopiervorgang aussteht, schlägt mit dem Statuscode 409 (Konflikt) fehl.

Nur Speicherkonten, die am oder nach dem 7. Juni 2012 erstellt wurden, lassen das Kopieren aus einem Copy Blob anderen Speicherkonto zu. Der Versuch, von einem anderen Speicherkonto in ein Konto zu kopieren, das vor dem 7. Juni 2012 erstellt wurde, schlägt mit dem Statuscode 400 (Ungültige Anforderung) fehl.

Der vorgang Copy Blob kopiert immer das gesamte Quell-BLOB oder die gesamte Datei. Das Kopieren eines Bytebereichs oder einer Gruppe von Blöcken wird nicht unterstützt.

Ein Copy Blob Vorgang kann eine der folgenden Formen annehmen:

  • Sie können ein Quellblob in ein Zielblob kopieren, das einen anderen Namen hat. Bei dem Zielblob kann es sich um ein vorhandenes Blob desselben Blobtyps (Block, Anfügung oder Seite) handeln, oder um ein neues Blob, das durch den Kopiervorgang erstellt wird.

  • Sie können ein Quellblob in ein Zielblob mit demselben Namen kopieren und so das Zielblob effektiv ersetzen. Ein solcher Kopiervorgang entfernt alle Blöcke, für die kein Commit ausgeführt wurde, und überschreibt die Metadaten des Blobs.

  • Sie können eine Quelldatei in Azure Files in ein Zielblob kopieren. Bei dem Zielblob kann es sich um ein vorhandenes Blockblob handeln, oder um ein neues Blockblob, das durch den Kopiervorgang erstellt wird. Das Kopieren von Dateien in Seitenblobs oder Anfügeblobs wird nicht unterstützt.

  • Sie können eine Momentaufnahme über das Basisblob kopieren. Indem Sie eine Momentaufnahme zu einem Basis-Blob heraufstufen, können Sie eine frühere Version eines Blobs wiederherstellen.

  • Sie können eine Momentaufnahme in ein Zielblob kopieren, das einen anderen Namen hat. Das resultierende Zielblob ist ein beschreibbares Blob und keine Momentaufnahme.

Wenn Sie aus einem Seitenblob kopieren, erstellt Blob Storage ein Zielseitenblob mit der Länge des Quellblobs. Anfänglich enthält das Seitenblob nur Nullen. Anschließend werden die Quellseitenbereiche aufgelistet, und nicht leere Bereiche werden kopiert.

Für ein Blockblob oder ein Anfügeblob erstellt Blob Storage ein Blob mit einem Commit der Länge Null, bevor es von diesem Vorgang zurückgegeben wird.

Wenn Sie aus einem Blockblob kopieren, werden alle Blöcke, für die ein Commit ausgeführt wurde, und ihre Block-IDs kopiert. Nicht festgeschriebene Blöcke werden nicht kopiert. Am Ende des Kopiervorgangs weist das Zielblob die gleiche Anzahl von Blöcken auf, für die ein Commit ausgeführt wurde, wie die Quelle.

Wenn Sie aus einem Anfügeblob kopieren, werden alle Blöcke, für die ein Commit ausgeführt wurde, kopiert. Am Ende des Kopiervorgangs verfügt das Zielblob über weniger als oder die gleiche Anzahl von Blöcken, für die ein Commit ausgeführt wurde, wie das Quellblob.

Für alle Blobtypen können Sie oder Get Blob Properties für das Zielblob aufrufenGet Blob, um den Status des Kopiervorgangs zu überprüfen. Für das endgültige Blob wird ein Commit ausgeführt, wenn der Kopiervorgang abgeschlossen ist.

Wenn die Quelle eines Kopiervorgangs Werte bereitstellt ETag , führen alle Änderungen an der Quelle, während der Kopiervorgang ausgeführt wird, dazu, dass dieser Vorgang fehlschlägt. Ein Versuch, das Zielblob zu ändern, während ein Kopiervorgang ausgeführt wird, schlägt mit dem Statuscode 409 (Konflikt) fehl. Wenn das Zielblob über eine unendliche Lease verfügt, muss die Lease-ID an Copy Blobübergeben werden. Mietverträge mit begrenzter Laufzeit sind nicht zulässig.

Der ETag Wert für ein Blockblob ändert sich, wenn der Copy Blob Vorgang gestartet und beendet wird. Der ETag Wert für ein Seitenblob ändert sich, wenn der Copy Blob Vorgang gestartet wird, und er ändert sich während des Kopiervorgangs weiterhin häufig. Der Inhalt eines Blockblobs ist erst nach Abschluss des vollständigen Kopiervorgangs durch einen Get Befehl sichtbar.

Kopieren von Blobeigenschaften, Tags und Metadaten

Wenn ein Blob kopiert wird, werden die folgenden Systemeigenschaften in das Zielblob kopiert, das die gleichen Werte aufweist:

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

  • x-ms-blob-sequence-number (nur für Seitenblobs)

  • x-ms-committed-block-count (nur für Anfügeblobs und nur für Version 2015-02-21)

Die Blockliste des Quellblobs, für die ein Commit ausgeführt wurde, wird ebenfalls in das Zielblob kopiert, wenn es sich bei dem Blob um ein Blockblob handelt. Nicht festgeschriebene Blöcke werden nicht kopiert.

Das Zielblob hat immer die gleiche Größe wie das Quellblob. Der Wert des Content-Length Headers für das Zielblob stimmt mit dem Wert dieses Headers für das Quellblob überein.

Wenn das Quellblob und das Zielblob identisch sind, werden alle Blöcke entfernt, Copy Blob für die kein Commit ausgeführt wurde. Wenn in diesem Fall Metadaten angegeben werden, werden die vorhandenen Metadaten mit den neuen Metadaten überschrieben.

Wenn der x-ms-tags Header Tags für das Zielblob bereitstellt, müssen diese abfragezeichenfolgencodiert sein. Tagschlüssel und -werte müssen den Benennungs- und Längenanforderungen entsprechen, die unter Festlegen von Blobtags angegeben sind.

Der x-ms-tags Header kann bis zu 2 Kilobit an Tags enthalten. Wenn Sie weitere Tags benötigen, verwenden Sie den Set Blob Tags Vorgang.

Wenn der x-ms-tags Header keine Tags bereitstellt, werden Tags nicht aus dem Quellblob kopiert.

Kopieren eines geleasten Blobs

Der Copy Blob Vorgang liest nur aus dem Quellblob, sodass der Leasestatus des Quellblobs keine Rolle spielt. Der Copy Blob Vorgang speichert jedoch den ETag Wert des Quellblobs, wenn der Kopiervorgang gestartet wird. Wenn sich der ETag Wert ändert, bevor der Kopiervorgang abgeschlossen ist, schlägt der Vorgang fehl. Sie können Änderungen am Quellblob verhindern, indem Sie es während des Kopiervorgangs leasen.

Wenn das Zielblob über eine aktive unendliche Lease verfügt, müssen Sie die Lease-ID im Aufruf des Copy Blob Vorgangs angeben. Wenn es sich bei der von Ihnen angegebenen Lease um eine aktive Lease mit begrenzter Dauer handelt, schlägt dieser Aufruf mit dem Statuscode 412 (Vorbedingung fehlgeschlagen) fehl. Während der Kopiervorgang aussteht, schlägt jeder Leasevorgang für das Zielblob mit dem Statuscode 409 (Konflikt) fehl. Eine unendliche Lease für das Zielblob wird während des Kopiervorgangs auf diese Weise gesperrt, unabhängig davon, ob Sie in ein Zielblob kopieren, das einen anderen Namen als die Quelle hat, in ein Zielblob kopieren, das denselben Namen wie die Quelle hat, oder eine Momentaufnahme über das Basisblob heraufstufen.

Wenn der Client eine Lease-ID für ein Blob angibt, das noch nicht vorhanden ist, gibt Blob Storage den Statuscode 412 (Vorbedingung fehlgeschlagen) für Anforderungen zurück, die für Version 2013-08-15 und höher gestellt werden. Für frühere Versionen gibt Blob Storage den Statuscode 201 (Erstellt) zurück.

Kopieren von Blobmomentaufnahmen

Wenn ein Quellblob kopiert wird, werden keine Momentaufnahmen oder Versionen des Quellblobs in das Ziel kopiert. Wenn ein Zielblob mit einer Kopie überschrieben wird, bleiben alle Momentaufnahmen oder Versionen, die dem Zielblob zugeordnet sind, unter seinem Namen intakt.

Sie können einen Kopiervorgang ausführen, um eine Momentaufnahme über das Basisblob heraufzustufen, solange es sich in einer Onlineebene (heiß oder kalt) befindet. Auf diese Weise können Sie eine frühere Version eines Blobs wiederherstellen. Der Snapshot bleibt erhalten, aber sein Ziel wird mit einer Kopie überschrieben, die sowohl gelesen als auch geschrieben werden kann.

Kopieren von Blobversionen

Sie können einen Kopiervorgang ausführen, um eine Version über das Basisblob heraufzustufen, solange es sich in einer Onlineebene (heiß oder kalt) befindet. Auf diese Weise können Sie eine frühere Version eines Blobs wiederherstellen. Die Version bleibt erhalten, aber ihr Ziel wird mit einer Kopie überschrieben, die sowohl gelesen als auch geschrieben werden kann.

Kopieren eines archivierten Blobs

Ab Version 2018-11-09 können Sie ein archiviertes Blob in ein neues Blob innerhalb desselben Speicherkontos kopieren. Das Quellblob verbleibt auf der Archivebene. Wenn es sich bei dem Quellblob um ein archiviertes Blob handelt, muss die Anforderung den x-ms-access-tier Header enthalten, der die Ebene des Zielblobs angibt. Das Zielblob muss sich auf einer Onlineebene befinden. Sie können nicht in ein Blob auf der Archivebene kopieren.

Ab Version 2021-02-12 können Sie ein archiviertes Blob auf eine Onlineebene in einem anderen Speicherkonto kopieren, solange sich das Zielkonto in derselben Region wie das Quellkonto befindet.

Die Anforderung schlägt möglicherweise fehl, wenn das Quellblob aktiviert wird.

Ausführliche Informationen zum Tiering auf Blockblobebene finden Sie unter Speicherebenen "Heiß", "Kalt" und "Archiv".

Arbeiten mit einem ausstehenden Kopiervorgang (Version 2012-02-12 und höher)

Wenn der Copy Blob Vorgang asynchron abgeschlossen wird, verwenden Sie die folgende Tabelle, um den nächsten Schritt basierend auf dem zurückgegebenen Statuscode zu bestimmen:

Statuscode Bedeutung
202 (Akzeptiert), x-ms-copy-status: success Der Kopiervorgang wurde erfolgreich abgeschlossen.
202 (Akzeptiert), x-ms-copy-status: ausstehend Der Kopiervorgang wurde nicht abgeschlossen. Rufen Sie das Zielblob ab Get Blob Properties , indem Sie den x-ms-copy-status Header untersuchen, bis der Vorgang abgeschlossen ist oder ein Fehler auftritt.
4xx, 500 oder 503 Der Kopiervorgang ist fehlgeschlagen.

Während und nach einem Copy Blob Vorgang enthalten die Eigenschaften des Zielblobs die Kopier-ID des Copy Blob Vorgangs und die URL des Quellblobs. Wenn der Vorgang abgeschlossen ist, schreibt Blob Storage den Zeit- und den Ergebniswert (success, failedoder aborted) in die Eigenschaften des Zielblobs. Wenn der Vorgang ein failed Ergebnis hat, enthält der x-ms-copy-status-description Header eine Fehlerdetailseite.

Ein ausstehender Copy Blob Vorgang hat ein zweiwöchiges Timeout. Bei einem Kopierversuch, der nach zwei Wochen noch nicht abgeschlossen wurde, tritt ein Timeout auf, und es bleibt ein leeres Blob zurück, bei dem das x-ms-copy-status Feld auf failed 500 und das x-ms-copy-status-description Feld auf 500 (OperationCancelled) festgelegt ist. Zeitweilige, nicht schwerwiegende Fehler, die während eines Kopiervorgangs auftreten können, beeinträchtigen den Fortschritt des Vorgangs, verursachen jedoch keinen Fehler. In diesen Fällen beschreibt x-ms-copy-status-description die zeitweiligen Fehler.

Jeder Versuch, das Zielblob während des Kopiervorgangs zu ändern oder eine Momentaufnahme zu erstellen, schlägt mit dem Statuscode 409 (Konflikt) fehl: "Copy Blob in Process".

Wenn Sie den Abort Copy Blob Vorgang aufrufen, wird eine x-ms-copy-status:aborted Kopfzeile angezeigt. Das Zielblob verfügt über intakte Metadaten und eine Bloblänge von 0 Byte. Sie können den ursprünglichen Aufruf von Copy Blob wiederholen, um den Kopiervorgang erneut zu versuchen.

Wenn der Copy Blob Vorgang synchron abgeschlossen wird, verwenden Sie die folgende Tabelle, um den Status des Kopiervorgangs zu bestimmen:

Statuscode Bedeutung
202 (Akzeptiert), x-ms-copy-status: success Der Kopiervorgang wurde erfolgreich abgeschlossen.
4xx, 500 oder 503 Der Kopiervorgang ist fehlgeschlagen.

Die Ebene wird für Storage Premium-Ebenen geerbt. Bei Blockblobs wird durch das Überschreiben des Zielblobs die heiße oder kalte Ebene vom Ziel geerbt, wenn x-ms-access-tier dies nicht angegeben wird. Beim Überschreiben eines archivierten Blobs tritt ein Fehler auf. Ausführliche Informationen zum Tiering auf Blockblobebene finden Sie unter Speicherebenen "Heiß", "Kalt" und "Archiv".

Abrechnung

Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die BLOB Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Diese Anforderungen anfallen Gebühren pro Transaktion. Der Transaktionstyp wirkt sich auf die Belastung des Kontos aus. Lesen Sie z. B. Transaktionen, die einer anderen Abrechnungskategorie als dem Schreiben von Transaktionen zugerechnet werden. Die folgende Tabelle zeigt die Abrechnungskategorie für Copy Blob Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Kopieren des Blobs (Zielkonto1) Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Schreibvorgänge
Kopieren des Blobs (Quellkonto2) Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Lesevorgänge

1Das Zielkonto wird mit einer Transaktion belastet, um den Schreibvorgang zu initiieren.
arabische ZifferWenn sich das Quellobjekt in einem anderen Konto befindet, führt das Quellkonto für jede Leseanforderung an das Quellobjekt eine Transaktion aus.

Weitere Informationen zu den Preisen für die angegebenen Abrechnungskategorien finden Sie unter Azure Blob Storage – Preise.

Für das Zielkonto fallen außerdem Transaktionskosten für jede Anforderung an, den Kopiervorgang abzubrechen (siehe Abbrechen des Kopierblobs) oder den Status des Kopiervorgangs zu überprüfen (siehe Abrufen von Blob oder Abrufen von Blobeigenschaften).

Wenn sich das Quell- und das Zielkonto in unterschiedlichen Regionen befinden (z. B. "USA, Norden" und "USA, Süden"), wird die Bandbreite, die Sie zum Übertragen der Anforderung verwenden, dem Quellspeicherkonto als ausgehender Datenverkehr in Rechnung gestellt. Der Ausgang zwischen Konten innerhalb derselben Region ist kostenlos.

Wenn Sie ein Quellblob in ein Zielblob kopieren, das innerhalb desselben Kontos einen anderen Namen hat, verwenden Sie zusätzliche Speicherressourcen für das neue Blob. Der Kopiervorgang führt dann zu einer Belastung der Kapazitätsauslastung des Speicherkontos für diese zusätzlichen Ressourcen. Wenn die Namen der Quell- und Zielblobs innerhalb desselben Kontos identisch sind (z. B. wenn Sie eine Momentaufnahme auf ihr Basisblob heraufstufen), fallen keine zusätzlichen Gebühren an, abgesehen von den zusätzlichen Kopiermetadaten, die in Version 2012-02-12 und höher gespeichert sind.

Wenn Sie eine Momentaufnahme heraufstufen, um das Basisblob zu ersetzen, werden die Momentaufnahme und das Basisblob identisch. Sie geben Blöcke oder Seiten gemeinsam frei, sodass der Kopiervorgang nicht zu einer zusätzlichen Belastung für die Kapazitätsauslastung des Speicherkontos führt. Wenn Sie jedoch eine Momentaufnahme in ein Zielblob kopieren, das einen anderen Namen hat, fallen für diesen Vorgang zusätzliche Gebühren für die Speicherressourcen an, die das resultierende neue Blob verwendet. Zwei Blobs mit unterschiedlichen Namen können keine Blöcke oder Seiten gemeinsam nutzen, selbst wenn sie identisch sind. Weitere Informationen zu Snapshot-Kostenszenarien finden Sie unter Verstehen, wie für Snapshots Gebühren anfallen.

Siehe auch

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes
Verstehen, wie für Snapshots Gebühren anfallen
Kopieren von Blobs abbrechen