(0) exportieren Drucken
Alle erweitern

Copy BLOB

Letzte Aktualisierung: November 2013

Der Copy Blob-Vorgang kopiert ein BLOB in ein Ziel innerhalb des Speicherkontos. Ab Version 2012-02-12 kann die Quelle eines Copy Blob-Vorgangs ein BLOB mit Commit in einem beliebigen Azure-Speicherkonto sein.

noteHinweis
Das Kopieren aus einem anderen Speicherkonto durch den Copy Blob-Vorgang wird jedoch nur für Speicherkonten unterstützt, die ab dem 7. Juni 2012 erstellt wurden.

Die Copy Blob-Anforderung kann wie folgt erstellt werden. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos, mycontainer durch den Namen des Containers und myblob durch den Namen Ihres Ziel-BLOBs. Ab Version 2013-08-15 können Sie eine SAS für das Ziel-BLOB angeben.

 

  Anforderungs-URI für PUT-Methode HTTP-Version

https://myaccount.blob.core.windows.net/mycontainer/myblob

HTTP/1.1

Wenn Sie eine Anforderung für den emulierten Speicherdienst ausführen, geben Sie den Emulatorhostnamen und den Port des Blob-Diensts mit 127.0.0.1:10000 an, gefolgt vom Namen des emulierten Speicherkontos:

 

  Anforderungs-URI für PUT-Methode HTTP-Version

http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob

HTTP/1.1

Weitere Informationen finden Sie unter Einsatz des Azure-Speicheremulators für Entwicklung und Tests.

Im Anforderungs-URI können die folgenden zusätzlichen Parameter angegeben werden.

 

Parameter Beschreibung

timeout

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

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

 

Anforderungsheader Beschreibung

Authorization

Erforderlich. Gibt das Authentifizierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Authentifizierung für die Azure-Speicherdienste.

Date - oder - x-ms-date

Erforderlich. Gibt die Uhrzeit der Anforderung in koordinierter Weltzeit (UTC) an. Weitere Informationen finden Sie unter Authentifizierung für die Azure-Speicherdienste.

x-ms-version

Erforderlich für alle authentifizierten 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 Name-Wert-Paare angegeben sind, werden vom Vorgang die Metadaten des Quell-BLOB in das Ziel-BLOB kopiert. Wenn ein oder mehrere Name-Wert-Paare angegeben sind, wird das Ziel-BLOB mit den angegebenen Metadaten erstellt, und die Metadaten werden nicht aus dem Quell-BLOB kopiert.

Beachten Sie, dass ab Version 2009-09-19 Metadatennamen den Benennungsregeln für C#-Bezeichner entsprechen müssen. Weitere Informationen finden Sie unter Benennen von Containern, BLOBs und Metadaten und Verweisen auf diese.

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 Quell-BLOB nicht geändert wurde, gibt der Blob-Dienst Statuscode 412 (Vorbedingung nicht erfüllt) zurück.

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 Quell-BLOB geändert wurde, gibt der Blob-Dienst Statuscode 412 zurück (Vorbedingung nicht erfüllt).

x-ms-source-if-match

Optional. Ein ETag-Wert. Geben Sie diesen bedingten Header an, um das Quell-BLOB nur dann zu kopieren, wenn sein ETag dem angegebenen Wert entspricht. Bei nicht übereinstimmenden ETag-Werten gibt der Blob-Dienst Statuscode 412 (Vorbedingung nicht erfüllt) zurück.

x-ms-source-if-none-match

Optional. Ein ETag-Wert. Geben Sie diesen bedingten Header an, um das Quell-BLOB nur dann zu kopieren, wenn sein ETag nicht dem angegebenen Wert entspricht. Bei übereinstimmenden Werten gibt der Blob-Dienst den Statuscode 412 (Vorbedingung nicht erfüllt) zurück.

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 Ziel-BLOB nicht geändert wurde, gibt der Blob-Dienst Statuscode 412 (Vorbedingung nicht erfüllt) 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 Ziel-BLOB geändert wurde, gibt der Blob-Dienst Statuscode 412 (Vorbedingung nicht erfüllt) 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 dem ETag-Wert für ein vorhandenes Ziel-BLOB entspricht. Wenn das ETag für das Ziel-BLOB nicht mit dem ETag übereinstimmt, das für If-Match angegeben wurde, gibt der Blob-Dienst Statuscode 412 (Vorbedingung nicht erfüllt) 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 dem ETag-Wert für das Ziel-BLOB entspricht.

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

Wenn die angegebene Bedingung nicht erfüllt ist, gibt der Blob-Dienst Statuscode 412 (Vorbedingung nicht erfüllt) zurück.

x-ms-copy-source:name

Erforderlich. Gibt den Namen des Quell-BLOB an.

Ab Version 2012-02-12 ist dieser Wert eine URL mit einer Länge von bis zu 2 KB, die ein BLOB angibt. Ein Quell-BLOB unter demselben Konto kann privat sein. Ein BLOB in einem anderen Konto muss jedoch öffentlich sein oder die in dieser URL enthaltenen Anmeldeinformationen akzeptieren, z. B. eine SAS. Das Kopieren aus einem anderen Speicherkonto durch den Copy Blob-Vorgang wird jedoch nur für Speicherkonten unterstützt, die ab dem 7. Juni 2012 erstellt wurden. Microsoft empfiehlt, nach Möglichkeit HTTPS zu verwenden. Beispiele:

  • https://myaccount.blob.core.windows.net/mycontainer/myblob

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

In Versionen vor 2012-02-12 können BLOBs lediglich innerhalb desselben Kontos kopiert werden, und ein Quellenname kann die folgenden Formate aufweisen:

  • BLOB in benanntem Container: /accountName/containerName/blobName

  • Momentaufnahme in benanntem Container: /accountName/containerName/blobName?snapshot=<DateTime>

  • BLOB in Stammcontainer: /accountName/blobName

  • Momentaufnahme in 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 nicht die Lease-ID enthält oder diese ungültig ist, schlägt der Vorgang mit Statuscode 412 (Vorbedingung nicht erfüllt) fehl.

Wenn dieser Header angegeben ist und das Ziel-BLOB derzeit über keine aktive Lease verfügt, schlägt der Vorgang ebenfalls mit Statuscode 412 (Vorbedingung nicht erfüllt) fehl.

Ab Version 2012-02-12 muss dieser Wert eine aktive Lease mit unbegrenzter Dauer für ein geleastes BLOB angeben. Bei einer ID für eine Lease mit begrenzter Dauer tritt ein Fehler (Vorbedingung nicht erfüllt) auf.

x-ms-source-lease-id: <ID>

Optional, Versionen bis 2012-02-12 (nicht unterstützt in 2012-02-12 und neueren Versionen). Geben Sie diesen Header an, um den Copy Blob-Vorgang nur dann auszuführen, wenn die angegebene Lease-ID mit der aktiven Lease-ID des Quell-BLOB übereinstimmt.

Wenn dieser Header angegeben ist und das Quell-BLOB derzeit über keine aktive Lease verfügt, schlägt der Vorgang ebenfalls mit Statuscode 412 (Vorbedingung nicht erfüllt) fehl.

x-ms-client-request-id

Optional. Stellt einen vom Client generierten, nicht transparenten Wert mit einer Zeichenbeschränkung von 1 KB bereit, der in den Analyseprotokollen erfasst wird, wenn die Protokollierung der Speicheranalyse aktiviert ist. Die Verwendung dieses Headers wird dringend empfohlen, um clientseitige Aktivitäten mit den vom Server empfangenen Anforderungen zu korrelieren. Weitere Informationen finden Sie unter Informationen zur Protokollierung durch die Speicheranalyse und Windows Azure-Protokollierung: Verwenden von Protokollen zur Nachverfolgung von Speicheranforderungen.

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

Ab Version 2012-02-12 gibt ein erfolgreicher Vorgang Statuscode 202 zurück (Akzeptiert).

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

Weitere Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

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

Ab Version 2012-02-12 ist bei einem abgeschlossenen Kopiervorgang das ETag des Ziel-BLOB enthalten. Wenn der Kopiervorgang nicht abgeschlossen wurde,ist das ETag des leeren BLOB enthalten, das zu Beginn des Kopiervorgangs erstellt wurde.

In Versionen bis 2012-02-12 wird das ETag für das Ziel-BLOB zurückgegeben.

In Versionen ab 2011-08-18 ist der ETag-Wert in Anführungszeichen eingeschlossen.

Last-Modified

Gibt den Zeitpunkt (Datum/Uhrzeit) zurück, zu dem der Kopiervorgang zum Ziel-BLOB abgeschlossen wurde.

x-ms-request-id

Dieser Header identifiziert die erfolgte Anforderung eindeutig und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.

x-ms-version

Gibt die Version des Blob-Diensts an, der zum Ausführen der Abfrage verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher erfolgen.

Date

Ein vom Dienst generierter Datums-/Uhrzeitwert in UTC, der angibt, wann die Antwort initiiert wurde.

x-ms-copy-id: <id>

Version 2012-02-12 und höher. Zeichenfolgenbezeichner für diesen Kopiervorgang. Verwenden Sie diesen mit Get Blob oder Get Blob Properties, um den Status des Kopiervorgangs zu überprüfen, oder übergeben Sie ihn an Abort Copy Blob, um einen ausstehenden Kopiervorgang abzubrechen.

x-ms-copy-status: <success | pending>

Version 2012-02-12 und höher. Status des Kopiervorgangs, mit den folgenden Werten:

  • success: Der Kopiervorgang wurde erfolgreich abgeschlossen.

  • pending: Der Kopiervorgang wird derzeit ausgeführt.

Keiner.

Im Folgenden ist eine Beispielantwort für eine Anforderung zum Kopieren eines BLOB dargestellt:

Response Status:
HTTP/1.1 202 Accepted
Response Headers: 
Last-Modified: Thu, 09 Feb 2012 23:30:19 GMT 
ETag: "0x8CEB669D794AFE2"
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402
x-ms-version: 2012-02-12
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5
x-ms-copy-status: pending
Date: Thu, 09 Feb 2012 23:30:18 GMT

Dieser Vorgang kann vom Kontobesitzer aufgerufen werden. Bei Anforderungen, die für Version 2013-08-15 und höher ausgeführt werden, werden für eine SAS, die über eine Schreibberechtigung für das Ziel-BLOB bzw. für dessen Container verfügt, Kopiervorgänge innerhalb desselben Kontos unterstützt. Beachten Sie, dass die für die Anforderung angegebene SAS nur für das Ziel-BLOB gilt. Der Zugriff auf das Quell-BLOB wird separat autorisiert. Eine detaillierte Beschreibung finden Sie in den Erläuterungen zum x-ms-copy-source-Anforderungsheader.

Ab Version 2012-02-12 kann der Copy Blob-Vorgang asynchron abgeschlossen werden. Dieser Vorgang gibt eine Kopie-ID zurück, anhand derer Sie den Kopiervorgang überprüfen oder abbrechen können. Der Blob-Dienst kopiert BLOBs auf Grundlage der besten Leistung.

Das Quell-BLOB für einen Kopiervorgang kann ein Block-BLOB oder ein Seitenblob bzw. eine Momentaufnahme davon darstellen. Wenn das Ziel-BLOB bereits vorhanden ist, muss es vom selben BLOB-Typ wie das Quell-BLOB sein. Jedes vorhandene Ziel-BLOB wird überschrieben. Das Ziel-BLOB kann nicht geändert werden, während ein Kopiervorgang ausgeführt wird.

Mehrere ausstehende Copy Blob-Vorgänge innerhalb eines Kontos können nacheinander verarbeitet werden. Ein Ziel-BLOB kann nur über einen ausstehenden BLOB-Kopiervorgang verfügen. Mit anderen Worten, ein BLOB kann nicht das Ziel mehrerer ausstehender Copy Blob-Vorgänge sein. Der Versuch, Copy Blob für ein Ziel-BLOB auszuführen, das bereits über einen ausstehenden Kopiervorgang verfügt, schlägt mit Statuscode 409 (Konflikt) fehl.

Das Kopieren aus einem anderen Speicherkonto durch den Copy Blob-Vorgang wird jedoch nur für Speicherkonten unterstützt, die ab dem 7. Juni 2012 erstellt wurden. Der Versuch, aus einem anderen Speicherkonto in ein vor dem 7. Juni 2012 erstelltes Konto zu kopieren, schlägt mit Statuscode 400 (Ungültige Anforderung) fehl.

Der Copy Blob-Vorgang kopiert immer das gesamte Quell-BLOB; das Kopieren eines Bereichs von Bytes oder einer Reihe von Blöcken wird nicht unterstützt.

Ein Copy Blob-Vorgang kann wie folgt erfolgen:

  • Sie können ein Quell-BLOB zu einem Ziel-BLOB mit einem anderen Namen kopieren. Das Ziel-BLOB kann ein vorhandenes BLOB desselben Typs (Block-BLOB oder Seitenblob) sein, oder es kann ein neues BLOB sein, das durch den Kopiervorgang erstellt wird.

  • Sie können ein Quell-BLOB zu einem Ziel-BLOB mit demselben Namen kopieren, wodurch das Quell-BLOB praktisch ersetzt wird. Bei einem solchen Kopiervorgang werden alle Blöcke ohne ausgeführten Commit entfernt, und die Metadaten des BLOB werden überschrieben.

  • Sie können eine Momentaufnahme auf das zugehörige Basis-BLOB kopieren. Wenn Sie eine Momentaufnahme zu einem Basis-BLOB heraufstufen, können Sie so eine frühere Version eines BLOB wiederherstellen.

  • Sie können eine Momentaufnahme zu einem Ziel-BLOB mit einem anderen Namen kopieren. Das resultierende Ziel-BLOB ist ein schreibbares BLOB und keine Momentaufnahme.

Beim Kopieren aus einem Seitenblob erstellt der Blob-Dienst ein Ziel-Seitenblob von der Länge des Quell-BLOB, das anfänglich ausschließlich Nullen enthält. Anschließend werden die Quellseitenbereiche aufgezählt, und nicht leere Bereiche werden kopiert. Beim Kopieren aus einem Block-BLOB werden alle Blöcke mit ausgeführtem Commit und deren Block-IDs kopiert. Nicht mit Commit bestätigte Blöcke werden nicht kopiert. Für ein Block-BLOB erstellt der Blob-Dienst ein BLOB mit ausgeführtem Commit der Länge 0, bevor er aus diesem Vorgang zurückkehrt. Für beide BLOB-Typen können Sie Get Blob oder Get Blob Properties im Ziel-BLOB aufrufen, um den Status des Kopiervorgangs zu überprüfen. Für das endgültige BLOB wird bei Abschluss des Kopiervorgangs ein Commit ausgeführt.

Wenn die Quelle eines Kopiervorgangs ETags bereitstellt und bei laufendem Kopiervorgang Änderungen an der Quelle auftreten, schlägt der Kopiervorgang fehl. Der Versuch, das Ziel-BLOB bei laufendem Kopiervorgang zu ändern, schlägt mit dem Fehlercode 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.

Das ETag für ein Block-BLOB wird geändert, wenn der Copy Blob-Vorgang initiiert und der Kopiervorgang abgeschlossen wird. Das ETag für ein Seitenblob wird geändert, wenn der Copy Blob-Vorgang initiiert wird, und es ändert sich fortlaufend während des Kopiervorgangs. Der Inhalt eines Block-BLOB ist unter Verwendung eines GET erst dann sichtbar, nachdem der Kopiervorgang vollständig abgeschlossen wurde.

Kopieren von BLOB-Eigenschaften und -Metadaten

Beim Kopieren eines BLOB werden die folgenden Systemeigenschaften mit den gleichen Werten zum Ziel-BLOB kopiert:

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

  • x-ms-blob-sequence-number (for page blobs only)

Die Liste der Blöcke mit ausgeführtem Commit des Quell-BLOB wird ebenfalls zum Ziel-BLOB kopiert, wenn es sich bei dem BLOB um einen Block-BLOB handelt. Blöcke ohne ausgeführten Commit werden nicht kopiert.

Das Ziel-BLOB weist stets dieselbe Größe wie das Quell-BLOB auf, sodass der Wert des Content-Length-Headers für das Ziel-BLOB dem des Quell-BLOB entspricht.

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.

Kopieren eines geleasten BLOB

Der Copy Blob-Vorgang liest nur aus dem Quell-BLOB; daher ist der Leasestatus des Quell-BLOB irrelevant. Der Copy Blob-Vorgang speichert jedoch beim Starten des Kopiervorgangs das ETag des Quell-BLOB. Wenn der Wert des ETags vor Abschluss des Kopiervorgangs geändert wird, schlägt der Kopiervorgang 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 es sich bei der angegebenen Lease um eine aktive Lease mit begrenzter Dauer handelt, schlägt dieser Aufruf mit Statuscode 412 (Vorbedingung nicht erfüllt) fehl. Bei ausstehendem Kopiervorgang schlägt jeder Leasevorgang für das Ziel-BLOB mit Statuscode 409 (Konflikt) fehl. Eine Lease mit unbegrenzter Dauer im Ziel-BLOB wird auf diese Weise während des Kopiervorgangs gesperrt, wenn Sie zu einem Ziel-BLOB mit anderem Namen als die Quelle kopieren, wenn Sie zu einem Ziel-BLOB mit demselben Namen wie die Quelle kopieren oder wenn Sie eine Momentaufnahme über ihren zugrunde liegenden BLOB heraufstufen. Wenn der Client eine Lease-ID für ein BLOB angibt, das noch nicht vorhanden ist, gibt der Blob-Dienst den Statuscode 412 (Vorbedingung nicht erfüllt) für Anforderungen zurück, die für Version 2013-08-15 und höher ausgeführt werden; für frühere Versionen gibt der Blob-Dienst den Statuscode 201 (Erstellt) zurück.

Kopieren von Momentaufnahmen

Wenn ein Quell-BLOB kopiert wird, werden ggf. vorhandene Momentaufnahmen des Quell-BLOB nicht mit an das Ziel kopiert werden. Wenn ein Ziel-BLOB mit einer Kopie überschrieben wird, bleiben alle dem Ziel-BLOB zugeordneten Momentaufnahmen unter dem Namen des BLOB erhalten.

Sie können einen Kopiervorgang ausführen, um ein Momentaufnahme-BLOB über ihren zugrunde liegenden BLOB heraufzustufen. Auf diese Weise können Sie eine frühere Version eines BLOB wiederherstellen. Die Momentaufnahme bleibt erhalten, ihr Ziel wird jedoch mit einer Kopie überschrieben, die gelesen und geschrieben werden kann.

Arbeiten mit einem ausstehenden Kopiervorgang (ab Version 2012-02-12)

Der Copy Blob-Vorgang schließt den Kopiervorgang asynchron ab. Bestimmen Sie mithilfe der folgenden Tabelle den nächsten Schritt, je nachdem, welcher Statuscode von Copy Blob zurückgegeben wurde:

 

Statuscode Bedeutung

202 (Akzeptiert), x-ms-copy-status: success

Der Kopiervorgang wurde erfolgreich abgeschlossen.

202 (Akzeptiert), x-ms-copy-status: pending

500 oder 503

Der Kopiervorgang wurde nicht abgeschlossen. Fragen Sie das Ziel-BLOB mit Get Blob Properties ab, um den x-ms-copy-status zu untersuchen, bis der Kopiervorgang abgeschlossen wird oder fehlschlägt.

4xx, 500 oder 503

Kopiervorgang fehlgeschlagen.

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. Bei Abschluss des Kopiervorgangs schreibt der Blob-Dienst den Datums- und Ergebniswert (success, failed oder aborted) in die Eigenschaften des Ziel-BLOB. Beim Wert failed für den Vorgang enthält der x-ms-copy-status-description-Header eine Zeichenfolge mit Fehlerdetails.

Ein ausstehender Copy Blob-Vorgang weist ein Timeout von zwei Wochen auf. Bei einem Kopierversuch, der nach zwei Wochen nicht abgeschlossen wurde, tritt ein Timeout auf. Das Ergebnis ist ein leeres BLOB, bei dem das Feld x-ms-copy-status auf failed und x-ms-copy-status-description auf 500 (OperationCancelled) festgelegt ist. Vorübergehende, nicht schwerwiegende Fehler, die während eines Kopiervorgangs auftreten können, können den Fortschritt des Kopiervorgangs beeinträchtigen, sie führen jedoch nicht zu einem Fehler. In diesen Fällen werden die vorübergehenden Fehler von x-ms-copy-status-description beschrieben.

Jeder Versuch, das Ziel-BLOB während des Kopiervorgangs zu ändern oder eine Momentaufnahme des Ziel-BLOB zu erstellen, schlägt mit 409 (Konflikt), BLOB-Kopiervorgang wird ausgeführt fehl.

Wenn Sie den Abort Copy Blob-Vorgang aufrufen, wird ein x-ms-copy-status:aborted-Header angezeigt, und das Ziel-BLOB enthält intakte Metadaten und weist eine BLOB-Länge von null Bytes auf. Sie können den ursprünglichen Aufruf von Copy Blob wiederholen, um den Kopiervorgang erneut auszuführen.

Abrechnung

Dem Zielkonto eines Copy Blob-Vorgangs wird eine Transaktion für das Initiieren des Kopiervorgangs berechnet; zudem fällt eine Transaktion für jede Anforderung zum Abbruch sowie jede Anforderung des Status des Kopiervorgangs an.

Wenn sich das Quell-BLOB in einem anderen Konto befindet, werden die Transaktionskosten für das Quellkonto berechnet. Wenn sich Quellkonto und Zielkonto in unterschiedlichen Regionen (z. B. USA Norden und USA Süden) befinden, wird die Bandbreite zum Übertragen der Anforderung für das Quellspeicherkonto als Ausgangsgebühren berechnet. Der Ausgang zwischen Konten innerhalb derselben Region ist kostenlos.

Wenn Sie ein Quell-BLOB zu einem Ziel-BLOB mit einem anderen Namen innerhalb desselben Kontos kopieren, verwenden Sie zusätzliche Speicherressourcen für das neue BLOB, sodass für den Kopiervorgang in Bezug auf die zusätzlichen Ressourcen Gebühren für die Kapazitätsauslastung des Speicherkontos anfallen. Wenn jedoch der Name des Quell-BLOB und des Ziel-BLOB innerhalb desselben Kontos identisch sind (wenn Sie z. B. eine Momentaufnahme auf ihren zugrunde liegenden BLOB heraufstufen), fallen außer für die zusätzlich kopierten, ab Version 2012-02-12 gespeicherten Metadaten keine zusätzlichen Gebühren an.

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 zu einem Ziel-BLOB mit einem anderen Namen kopieren, fallen zusätzliche Gebühren für die Speicherressourcen an, die vom erhaltenen neuen BLOB belegt werden. Zwei BLOBs mit unterschiedlichen Namen können nicht Blöcke oder Seiten gemeinsam nutzen, selbst wenn sie identisch sind. Weitere Informationen zu Szenarien mit anfallenden Momentaufnahmekosten finden Sie unter Grundlegendes zur Ermittlung der Gebühren für Momentaufnahmen.

Anzeigen:
© 2014 Microsoft