Freigeben über

Kopieren von Blobs

  • Artikel

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 committetes Blob 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, erlauben das Copy Blob Kopieren aus einem anderen Speicherkonto.

Anforderung

Sie können die Copy Blob Anforderung wie folgt erstellen. Wir empfehlen HTTPS. 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 freigegebene Zugriffssignatur für das Zielblob angeben, wenn es sich in einem anderen Speicherkonto befindet.

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

URI für den emulierten Speicherdienst

Wenn Sie eine Anforderung für den emulierten Speicherdienst stellen, geben Sie den Emulatorhostnamen und Azure Blob Storage Port als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos:

PUT-Methodenanforderungs-URI 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 lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können im Anforderungs-URI die folgenden zusätzlichen Parameter angeben:

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

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben:

Anforderungsheader 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 (Coordinated Universal Time, 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-Speicherdienste.
x-ms-meta-name:value Optional. Gibt ein benutzerdefiniertes Name-Wert-Paar an, das dem Blob zugeordnet ist. Wenn keine Namen-Wert-Paare angegeben werden, kopiert der Vorgang die Metadaten aus dem Quellblob oder der Quelldatei in das Zielblob. Wenn mindestens ein Name/Wert-Paar angegeben wird, 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 Optional. Legt die angegebenen abfragezeichenfolgencodierten Tags für das Blob fest. Tags werden nicht aus der Kopierquelle kopiert. Weitere Informationen finden Sie unter Hinweise. Unterstützt in Version 2019-12-12 und höher.
x-ms-source-if-modified-since Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um das BLOB nur dann zu kopieren, wenn das Quell-BLOB seit dem angegebenen Datum bzw. der angegebenen Uhrzeit geändert wurde. Wenn das Quellblob nicht geändert wurde, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück. Sie können diesen Header nicht angeben, wenn die Quelle eine Azure-Datei ist.
x-ms-source-if-unmodified-since Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um das BLOB nur dann zu kopieren, wenn das Quell-BLOB seit dem angegebenen Datum bzw. der angegebenen Uhrzeit nicht geändert wurde. Wenn das Quellblob geändert wurde, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück. Sie können diesen Header nicht angeben, wenn die Quelle eine Azure-Datei ist.
x-ms-source-if-match Optional. Ein ETag-Wert. Geben Sie diesen bedingten Header an, um das Quellblob nur zu kopieren, wenn dessen ETag Wert dem angegebenen Wert entspricht. Wenn die Werte nicht übereinstimmen, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück. Sie können diesen Header nicht angeben, wenn die Quelle eine Azure-Datei ist.
x-ms-source-if-none-match Optional. 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 status Code 412 (Vorbedingung fehlgeschlagen) zurück. Sie können diesen Header nicht angeben, wenn die Quelle eine Azure-Datei ist.
If-Modified-Since Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um das BLOB nur dann zu kopieren, wenn das Ziel-BLOB seit dem angegebenen Datum bzw. der angegebenen Uhrzeit geändert wurde. Wenn das Zielblob nicht geändert wurde, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück.
If-Unmodified-Since Optional. Ein DateTime-Wert. Geben Sie diesen bedingten Header an, um das BLOB nur dann zu kopieren, wenn das Ziel-BLOB seit dem angegebenen Datum bzw. der angegebenen Uhrzeit nicht geändert wurde. Wenn das Zielblob geändert wurde, gibt Blob Storage status Code 412 (Fehler bei der Vorbedingung) zurück.
If-Match Optional. 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 status Code 412 (Vorbedingung fehlgeschlagen) zurück.
If-None-Match Optional. 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 Zielblob nicht vorhanden ist.

Wenn die angegebene Bedingung nicht erfüllt ist, gibt Blob Storage status Code 412 (Vorbedingung fehlgeschlagen) zurück.
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 Kibibytes (KiB) sein, die ein Blob angibt. Der Wert sollte urlcodiert 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 das Quellobjekt eine Datei ist, 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, ermöglichen das Copy Blob Kopieren aus einem anderen Speicherkonto.

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 das Quellobjekt eine Datei in Azure Files ist, 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 2012-02-12 können Blobs nur innerhalb desselben Kontos kopiert werden, und ein Quellname kann die folgenden Formate verwenden:

- Blob im benannten Container: /accountName/containerName/blobName
– Momentaufnahme im benannten Container: /accountName/containerName/blobName?snapshot=<DateTime>
- Blob im Stammcontainer: /accountName/blobName
– Momentaufnahme im Stammcontainer: /accountName/blobName?snapshot=<DateTime>
x-ms-lease-id:<ID> Erforderlich, wenn das Ziel-BLOB ü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 die Lease-ID nicht enthält oder die ID ungültig ist, schlägt der Vorgang mit status Code 412 (Vorbedingung fehlgeschlagen) fehl.

Wenn dieser Header angegeben ist und das Zielblob derzeit keine aktive Lease aufweist, schlägt der Vorgang mit status Code 412 (Vorbedingungsfehler) 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 für begrenzte Dauer schlägt mit status Code 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 keine aktive Lease aufweist, schlägt der Vorgang mit status Code 412 (Vorbedingungsfehler) fehl.
x-ms-client-request-id Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 KiB bereit, der in den Protokollen aufgezeichnet wird, wenn die Protokollierung konfiguriert ist. 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 Optional. 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 ab Version 2018-11-09 für Blockblobs unterstützt. Das Blockblobtiering wird für Blob Storage- oder Universell v2-Konten unterstützt. Gültige Werte sind Hot, CoolCold und Archive. Hinweis:Cold tier wird für Version 2021-12-02 und höher unterstützt. Ausführliche Informationen zum Blockblobtiering finden Sie unter Speicherebenen "Heiß", "Kalt" und "Archiv".
x-ms-rehydrate-priority Optional. Gibt die Priorität an, mit der ein archiviertes Blob aktiviert werden soll. Dieser Header wird ab Version 2019-02-02 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 Optional. Unterstützt ab 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 die Aufbewahrung bis zum Datum 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 den gesetzlichen Aufbewahrungsspeicher an, der für das Blob festgelegt werden soll. Gültige Werte sind true und false.

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

Anforderungstext

Keine.

Antwort

Die Antwort enthält den HTTP-Statuscode und einen Satz von Antwortheadern.

Statuscode

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

In Versionen bis 2012-02-12 wird bei einem erfolgreich ausgeführten Vorgang Statuscode 201 (Erstellt) zurückgeben.

Informationen zu status Codes finden Sie unter Status- und Fehlercodes.

Antwortheader

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort kann außerdem weitere HTTP-Standardheader enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Antwortheader BESCHREIBUNG
ETag In Version 2012-02-12 und höher enthält ETag dieser Header den Wert des Zielblobs, wenn die Kopie abgeschlossen ist. 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 2012-02-12 gibt dieser Header den ETag Wert für das Zielblob zurück.

In Version 2011-08-18 und höher befindet sich der ETag Wert in Anführungszeichen.
Last-Modified Gibt das Datum/die Uhrzeit zurück, an dem der Kopiervorgang in das Zielblob abgeschlossen wurde.
x-ms-request-id Identifiziert die durchgeführte Anforderung eindeutig. Sie können diesen Header verwenden, um probleme mit der 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 für Version 2009-09-19 und höher erfolgen.
Date Ein UTC-Datums-/Uhrzeitwert, der den Zeitpunkt angibt, zu dem 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. Verwenden Sie mit Get Blob oderGet Blob Properties, um die status dieses Kopiervorgangs zu überprüfen, oder übergeben Sie an, um Abort Copy Blob 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 zur Problembehandlung von Anforderungen und entsprechenden Antworten verwendet werden. 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 umfasst. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist dieser Header in der Antwort nicht vorhanden.

Antworttext

Keine.

Beispiel für eine Antwort

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>

Authorization

Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung 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) Autorisierung mit gemeinsam genutzten Schlüsseln (oder Gemeinsam genutzter Schlüssel Lite)
Zielblob Yes Yes Yes
Quellblob im selben Speicherkonto Yes Yes Yes
Quellblob in einem anderen Speicherkonto Nein Ja Nein

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

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

Wichtig

Microsoft empfiehlt die Verwendung von Microsoft Entra ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Microsoft Entra ID bietet im Vergleich zur Autorisierung mit gemeinsam genutzten Schlüsseln eine höhere Sicherheit und Benutzerfreundlichkeit.

Azure Storage unterstützt die Verwendung von Microsoft Entra ID zum Autorisieren von Anforderungen für Blobdaten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) verwenden, um einem Sicherheitsprinzipal Berechtigungen zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Azure-Identität sein. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann anschließend zum Autorisieren einer Anforderung an den Blob-Dienst verwendet werden.

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

Berechtigungen

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 mit den geringsten Berechtigungen, 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 Blobdaten.

Hinweise

In Version 2012-02-12 und höher kann der Copy Blob Vorgang asynchron abgeschlossen werden. Dieser Vorgang gibt eine Kopier-ID zurück, die Sie zum Überprüfen oder Abbrechen des Kopiervorgangs verwenden können. Aufgrund der asynchronen Natur des Kopiervorgangs kopiert Blob Storage Blobs auf der Grundlage der bestmöglichen Leistung. Der Blobdienst kopiert Blobs, wenn Serverressourcen nicht von anderen Aufgaben verwendet werden, sodass nicht garantiert wird, dass eine Kopie sofort gestartet oder innerhalb eines angegebenen Zeitrahmens abgeschlossen wird.

Das Quellblob für einen Kopiervorgang kann ein Blockblob, ein Anfügeblob, ein Seitenblob oder ein Momentaufnahme sein. Wenn das Zielblob bereits vorhanden ist, muss es von demselben Blobtyp wie das Quellblob sein. Ein eventuell vorhandenes Zielblob wird ü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 die Quelle eine Datei ist, muss das Ziel ein Blockblob sein.

Mehrere ausstehende Copy Blob-Vorgänge innerhalb eines Kontos können nacheinander verarbeitet werden. Ein Zielblob kann nur einen ausstehenden Copy Blob Vorgang aufweisen. Anders ausgedrückt: Ein Blob kann nicht das Ziel für mehrere ausstehende Copy Blob Vorgänge sein. Beim Versuch, ein Blob in ein Zielblob zu kopieren, für das bereits ein Kopiervorgang aussteht, schlägt status Code 409 (Konflikt) fehl.

Nur Speicherkonten, die am oder nach dem 7. Juni 2012 erstellt wurden, ermöglichen das Copy Blob Kopieren aus einem anderen Speicherkonto. Beim Versuch, aus einem anderen Speicherkonto in ein Konto zu kopieren, das vor dem 7. Juni 2012 erstellt wurde, schlägt status Code 400 (ungültige Anforderung) fehl.

Der Copy Blob Vorgang kopiert immer das gesamte Quellblob oder die gesamte Quelldatei. Das Kopieren eines Bytebereichs oder einer Gruppe von Blöcken wird nicht unterstützt.

Ein Copy Blob-Vorgang kann wie folgt erfolgen:

  • Sie können ein Quellblob in ein Zielblob mit einem anderen Namen kopieren. Das Zielblob kann ein vorhandenes Blob desselben Blobtyps (block, append oder page) sein, oder es kann sich um ein neues Blob handeln, das vom Kopiervorgang erstellt wird.

  • Sie können ein Quellblob in ein Zielblob mit demselben Namen kopieren und das Zielblob effektiv ersetzen. Bei einem solchen Kopiervorgang werden alle Blöcke ohne ausgeführten Commit entfernt, und die Metadaten des BLOB werden überschrieben.

  • Sie können eine Quelldatei in Azure Files in ein Zielblob kopieren. Das Zielblob kann ein vorhandenes Blockblob oder ein neues Blockblob sein, das vom Kopiervorgang erstellt wird. Das Kopieren von Dateien in Seitenblobs oder Anfügeblobs wird nicht unterstützt.

  • Sie können eine Momentaufnahme über das zugehörige Basis-Blob 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 mit einem anderen Namen kopieren. Das resultierende Zielblob ist ein beschreibbares Blob und keine Momentaufnahme.

Wenn Sie aus einem Seitenblob kopieren, erstellt Blob Storage ein Zielseitenblob der Länge des Quellblobs. Anfangs enthält das Seitenblob alle Nullen. Anschließend werden die Quellseitenbereiche aufgezählt, und nicht leere Bereiche werden kopiert.

Für ein Blockblob oder ein Anfügeblob erstellt Blob Storage ein committetes Blob mit der Länge 0 (null), bevor aus diesem Vorgang zurückgegeben wird.

Beim Kopieren aus einem Blockblob werden alle committeten Blöcke und die zugehörigen Block-IDs kopiert. Nicht commitierte Blöcke werden nicht kopiert. Am Ende des Kopiervorgangs weist das Zielblob die gleiche Anzahl von Commits auf wie die Quelle.

Beim Kopieren aus einem Anfügeblob werden alle committeten Blöcke kopiert. Am Ende des Kopiervorgangs verfügt das Zielblob über weniger als oder die gleiche Anzahl von committeten Blöcken wie das Quellblob.

Für alle Blobtypen können Sie oder Get Blob Properties im Zielblob aufrufenGet Blob, um die status des Kopiervorgangs zu überprüfen. Das endgültige Blob wird committet, 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 eine Kopie ausgeführt wird, schlägt mit status Code 409 (Konflikt) fehl. Wenn das Ziel-BLOB über eine unbegrenzte Lease verfügt, muss die Lease-ID an Copy Blob übergeben werden. Leases mit begrenzter Dauer sind nicht zulässig.

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

Kopieren von Blobeigenschaften, Tags und Metadaten

Wenn ein Blob kopiert wird, werden die folgenden Systemeigenschaften in das Zielblob mit denselben Werten kopiert:

  • 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 Commit-Blockliste des Quellblobs wird auch in das Zielblob kopiert, wenn es sich um ein Blockblob handelt. Blöcke ohne ausgeführten Commit werden nicht kopiert.

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

Wenn das Quell-BLOB und das Ziel-BLOB identisch sind, werden von Copy Blob alle Blöcke ohne ausgeführten Commit entfernt. Wenn in einem solchen Fall Metadaten angegeben sind, 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, wie unter Festlegen von Blobtags angegeben.

Der x-ms-tags Header kann bis zu 2 Kilobits 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 Quell-BLOB verhindern, indem Sie es während des Kopiervorgangs leasen.

Wenn das Ziel-BLOB über eine aktive Lease von unbegrenzter Dauer verfügt, müssen Sie die entsprechende Lease-ID im Aufruf des Copy Blob-Vorgangs angeben. Wenn die von Ihnen angegebene Lease eine aktive Lease mit endlicher Dauer ist, schlägt dieser Aufruf mit dem status Code 412 (Vorbedingungsfehler) fehl. Während der Kopiervorgang aussteht, schlägt jeder Leasevorgang im Zielblob mit status Code 409 (Konflikt) fehl. Eine unbegrenzte 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 status Code 412 (Vorbedingungsfehler) für Anforderungen zurück, die für Version 2013-08-15 und höher gestellt wurden. Für frühere Versionen gibt Blob Storage status Code 201 (Erstellt) zurück.

Kopieren von Blobmomentaufnahmen

Wenn ein Quellblob kopiert wird, werden alle Momentaufnahmen oder Versionen des Quellblobs nicht an 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. Die Momentaufnahme bleibt erhalten, ihr Ziel wird jedoch mit einer Kopie überschrieben, die gelesen und geschrieben werden kann.

Kopieren von Blobversionen

Sie können einen Kopiervorgang ausführen, um eine Version über das Basisblob heraufzustufen, solange sie 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, ihr Ziel wird jedoch 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 das Quellblob ein archiviertes Blob ist, muss die Anforderung den x-ms-access-tier Header enthalten, der die Ebene des Zielblobs angibt. Das Zielblob muss sich in einer Onlineebene befinden. Sie können kein Blob auf der Archivebene kopieren.

Ab Version 2021-02-12 können Sie ein archiviertes Blob in 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 rehydriert wird.

Ausführliche Informationen zum Tiering auf Blockblobebene finden Sie unter Speicherebene "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 status Code zu ermitteln:

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

Während eines Copy Blob-Vorgangs und danach enthalten die Eigenschaften des Ziel-BLOB die Kopie-ID des Copy Blob-Vorgangs sowie die URL des Quell-BLOB. Nach Abschluss des Vorgangs schreibt Blob Storage den Zeit- und 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 weist ein Timeout von zwei Wochen auf. Bei einem Kopierversuch, der nach zwei Wochen nicht abgeschlossen ist, wird ein leerer Blob mit festgelegtem x-ms-copy-status Feld auf failed und auf x-ms-copy-status-description 500 (OperationCancelled) festgelegt. Zeitweilige, nicht schwerwiegende Fehler, die während eines Kopiervorgangs auftreten können, können den Fortschritt des Vorgangs beeinträchtigen, aber nicht dazu führen, dass er fehlschlägt. In diesen Fällen werden die vorübergehenden Fehler von x-ms-copy-status-description beschrieben.

Jeder Versuch, das Zielblob während des Kopiervorgangs zu ändern oder zu Momentaufnahme, schlägt mit status Code 409 (Konflikt), "Blob kopieren in Bearbeitung" fehl.

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

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

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

Die Ebene wird für Storage Premium-Tarife geerbt. Bei Blockblobs erbt das Überschreiben des Zielblobs die heiße oder kalte Ebene vom Ziel, falls x-ms-access-tier nicht angegeben. Beim Überschreiben eines archivierten Blobs tritt ein Fehler auf. Ausführliche Informationen zum Tiering auf Blockblobebene finden Sie unter Speicherebene "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. Für diese Anforderungen fallen Gebühren pro Transaktion an. Die Art der Transaktion wirkt sich auf die Belastung des Kontos aus. Beispielsweise werden Lesetransaktionen in eine andere Abrechnungskategorie als das Schreiben von Transaktionen angewendet. Die folgende Tabelle zeigt die Abrechnungskategorie für Copy Blob Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Blob kopieren (Zielkonto1) Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Schreibvorgänge
Blob kopieren (Quellkonto2) Premium, Blockblob
Standard „Allgemein v2“
Standard „Allgemein v1“		 Dient zum Lesen von Vorgängen.

1Das Zielkonto wird für eine Transaktion in Rechnung gestellt, um den Schreibvorgang zu initiieren.
2Wenn sich das Quellobjekt in einem anderen Konto befindet, führt das Quellkonto eine Transaktion für jede Leseanforderung an das Quellobjekt aus.

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

Das Zielkonto verursacht auch Transaktionskosten für jede Anforderung zum Abbrechen des Kopiervorgangs (siehe Abbrechen des Kopierblobs) oder zum Überprüfen der status des Kopiervorgangs (siehe Abrufen von Blob- oder Get Blob-Eigenschaften).

Wenn sich die Quell- und Zielkonten in verschiedenen Regionen befinden (z. B. USA, Norden und USA, Süden), wird außerdem die Bandbreite, die Sie für die Übertragung der Anforderung verwenden, dem Quellspeicherkonto als ausgehend in Rechnung gestellt. Der Ausgang zwischen Konten innerhalb derselben Region ist kostenlos.

Wenn Sie ein Quellblob in ein Zielblob kopieren, das einen anderen Namen innerhalb desselben Kontos hat, verwenden Sie zusätzliche Speicherressourcen für das neue Blob. Der Kopiervorgang führt dann zu einer Gebühr für die Kapazitätsauslastung des Speicherkontos für diese zusätzlichen Ressourcen. Wenn die Namen der Quell- und Zielblobs jedoch innerhalb desselben Kontos identisch sind (z. B. wenn Sie ein Momentaufnahme auf das 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 ihr zugrunde liegendes BLOB zu ersetzen, sind Momentaufnahme und zugrunde liegendes BLOB anschließend identisch. Blöcke oder Seiten werden gemeinsam genutzt, sodass durch den Kopiervorgang keine zusätzlichen Gebühren für die Kapazitätsauslastung des Speicherkontos berechnet werden. Wenn Sie jedoch eine Momentaufnahme in ein Zielblob mit einem anderen Namen kopieren, 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 freigeben, auch wenn sie identisch sind. Weitere Informationen zu Momentaufnahme Kostenszenarien finden Sie unter Grundlegendes zum Ansammeln von Gebühren für Momentaufnahmen.

Weitere Informationen

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes
Grundlegendes zur Erfassung von Gebühren für Momentaufnahmen
Abort Copy Blob