Copy BLOB
Dieser Artikel wurde maschinell übersetzt. Wenn Sie die englische Version des Artikels anzeigen möchten, aktivieren Sie das Kontrollkästchen Englisch. Sie können den englischen Text auch in einem Popupfenster anzeigen, indem Sie den Mauszeiger über den Text bewegen.
Übersetzung
Englisch

Copy BLOB

 

Die Copy Blob Vorgang kopiert ein Blob in ein Ziel innerhalb des Speicherkontos. In Version 2012-02-12 und höher, die Quelle für einen Copy Blob-Vorgang kann in jeder Azure-Speicherkonto ein Blob mit ausgeführtem Commit.

Ab Version 2015-02-21, die Quelle für eine Copy Blob Vorgang kann eine Azure-Datei in ein Azure-Speicher-Konto sein.

System_CAPS_noteHinweis

Ermöglichen Sie nur Speicherkonten, die am oder nach dem 7. Juni 2012 erstellt die Copy Blob Vorgang aus einem anderen Speicherkonto kopiert.

Die Copy Blob -Anforderung kann wie folgt erstellt werden. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos mycontainer mit dem Namen des Containers und myblob mit dem Namen des Ziel-Blob.

Ab Version 2013-08-15 können Sie angeben eine SAS für das Ziel-Blob ist in das gleiche Konto wie das Quell-Blob. Ab Version 2015-04-05 können Sie auch angeben eine SAS für das Ziel-Blob ist in einem anderen Speicherkonto.

Anforderungs-URI für PUT-Methode

HTTP-Version

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

HTTP/1.1

Wenn eine Anforderung für den emulierten Speicherdienst ausführen, geben Sie den emulatorhostnamen und den Port des Blob-Dienst als 127.0.0.1:10000, gefolgt vom Namen 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 mithilfe der Azure-Speicheremulator für Entwicklungs- und.

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

Parameter

Beschreibung

timeout

Optional. Die 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 Versionskontrolle für 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, wird im Rahmen die Metadaten aus der Quell-Blob oder der Datei zum Ziel-Blob kopiert. Wenn ein oder mehrere Name-Wert-Paare angegeben sind, wird das Ziel-Blob mit den angegebenen Metadaten erstellt und Metadaten werden aus der Quell-Blob oder die Datei nicht kopiert.

Beachten Sie, dass ab Version 2009-09-19 Metadatennamen den Benennungsregeln für entsprechen müssen C#-Bezeichner. Finden Sie unter Benennen und verweisen auf Container, Blobs und Metadaten Weitere Informationen.

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. Dieser Header nicht angegeben werden, wenn die Quelle eine Azure-Datei handelt.

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). Dieser Header nicht angegeben werden, wenn die Quelle eine Azure-Datei handelt.

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. Dieser Header nicht angegeben werden, wenn die Quelle eine Azure-Datei handelt.

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. Dieser Header nicht angegeben werden, wenn die Quelle eine Azure-Datei handelt.

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 das Blob zu kopieren, nur dann, wenn der angegebene ETag-Wert entspricht der ETag -Wert für ein vorhandenes zielblob. Wenn das ETag für das Ziel-Blob nicht mit das ETag übereinstimmt If-Match, Blob-Dienst gibt den 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 oder der Datei.

Ab Version 2012-02-12 ist dieser Wert eine URL von bis zu 2 KB möglicherweise, die ein Blob angibt. Der Wert sollte so URL-codiert sein, wie er in einem Anforderungs-URI verwendet wird. Ein Quell-Blob im gleichen Speicherkonto kann über einen gemeinsamen Schlüssel authentifiziert werden. Jedoch ist die Quelle eines BLOBs in ein anderes Konto, das Quell-Blob muss öffentlich sein oder über eine SAS authentifiziert werden muss. Wenn das Quell-Blob Blob öffentlich ist, ist keine Authentifizierung erforderlich, um den Kopiervorgang auszuführen.

Ab Version 2015-02-21 möglicherweise das Quellobjekt eine Datei in der Azure-Dateidienst. Ist das Quellobjekt eine Datei, die auf ein Blob kopiert werden soll, muss die Quelldatei authentifizierten Verwenden des Hashwerts einer SAS sein, ob es im selben Konto oder unter einem anderen Konto befindet.

Ermöglichen Sie nur Speicherkonten, die am oder nach dem 7. Juni 2012 erstellt die Copy Blob Vorgang aus einem anderen Speicherkonto kopiert.

Hier sind einige Beispiele für URLs der Source-Objekt:

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

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

Wenn das Quellobjekt eine Datei in der Azure-Dateidienst ist, verwendet die Quell-URL im folgende Format. Beachten Sie, dass die URL für die Datei ein gültiges SAS-Token enthalten muss:

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

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 zum Ausführen der Copy Blob Vorgang nur dann, wenn die Lease-ID, die mit die aktiven Lease-ID des Quell-Blob entspricht.

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 bei Aktivierung der Speicheranalyse-Protokollierung in den Analyseprotokollen erfasst wird. Die Verwendung dieses Headers wird dringend empfohlen, um clientseitige Aktivitäten mit den vom Server empfangenen Anforderungen zu korrelieren. Weitere Informationen finden Sie unter Zur Protokollierung der Speicheranalyse und Azure-Protokollierung: Mithilfe von Protokollen zur Track-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.

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 bei 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 mit Get Blob oder Get Blob Properties Überprüfen Sie den Status des Kopiervorgangs oder an übergeben 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 gerade 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: <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 Date: <date>

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.

Zugriff auf die Quell-Blob oder die Datei wird in den Details für den Anforderungsheader beschrieben separat autorisiert x-ms-copy-source.

In der folgende Tabelle wird beschrieben, wie das Ziel und Quelle von Objekten für eine Copy Blob Operation authentifiziert werden kann.

Authentifizierung mit Shared Key/Shared Key Lite

Authentifizierung mit SAS

Öffentliche Objekte nicht eine Authentifizierung erfordert.

Ziel-blob

Ja 

Ja 

Nein

Quell-Blob unter demselben Konto

Ja 

Ja 

Ja 

Quell-Blob in ein anderes Konto

Nein

Ja 

Ja 

Quelldatei in das gleiche Konto oder ein anderes Konto

Nein

Ja 

Nicht zutreffend

In Version 2012-02-12 und höher ist die 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 möglicherweise ein Block-Blob, ein Blob anfügen oder ein Seiten-Blob oder eine Momentaufnahme. 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.

In Version 2015-02-21 und höher ist die Quelle für den Kopiervorgang kann auch eine Datei in der Azure-Dateidienst. Wenn die Quelle eine Datei ist, muss das Ziel ein Block-Blob sein.

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. Ein Blob kann nicht mit anderen Worten, das Ziel mehrerer ausstehender sein Copy Blob Vorgänge. Versuch, Copy Blob zu einem Ziel-Blob, die bereits eine Kopie ausstehende schlägt fehl mit Statuscode 409 (Konflikt).

Ermöglichen Sie nur Speicherkonten, die am oder nach dem 7. Juni 2012 erstellt die Copy Blob Vorgang aus einem anderen Speicherkonto kopiert. 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.

Die Copy Blob -Vorgang kopiert immer das gesamte Quell-Blob oder die Datei, das Kopieren eines Bereichs von Bytes oder eine Gruppe von Blöcken wird nicht unterstützt.

Ein Copy Blob Vorgang dauert eine der folgenden Formen:

  • Sie können ein Quell-BLOB zu einem Ziel-BLOB mit einem anderen Namen kopieren. Das Ziel-Blob kann ein vorhandenes Blob desselben Typs Blob (blockieren, Anfügen oder Seite), oder ein neues Blob, das durch den Kopiervorgang erstellt werden kann.

  • Sie können ein Quell-Blob zu einem Ziel-Blob mit dem gleichen Namen, kopieren, praktisch ersetzt das Ziel-Blob. 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 eine Ziel-Blob in der Azure-Dateidienst kopieren. Das Ziel-Blob kann ein vorhandenes Blockblob sein, oder ein neuer Block-Blob erstellt werden durch den Kopiervorgang. Kopieren von Dateien auf Seite Blobs oder Anfügen von Blobs wird nicht unterstützt.

  • 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.

Ein Block-Blob oder ein Blob anfügen erstellt der Blob-Dienst eine Blob mit ausgeführtem Commit der Länge Null vor der Rückgabe von diesem Vorgang.

Beim Kopieren eines Block-BLOBs festgeschrieben alle Blöcke und ihrer Block-IDs kopiert wurden. Blöcke werden nicht kopiert. Am Ende des Vorgangs zum Kopieren wird das Ziel-Blob die gleichen Commit blockieren Count als Quelle aufweisen.

Beim Kopieren eines Append-BLOBs werden alle Blöcke mit ausgeführtem Commit kopiert. Am Ende des Vorgangs zum Kopieren wird das Ziel-Blob die gleichen Commit blockieren Count als Quelle aufweisen.

Für alle Typen blob, rufen Sie Get Blob oder Get Blob Properties im Ziel-Blob zum Überprüfen des Status des Kopiervorgangs. 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 eine unbegrenzte Lease verfügt, muss die Lease-ID übergeben werden, um Copy Blob. Leases mit begrenzter Dauer sind nicht zulässig.

Das ETag für ein Block-Blob wird geändert, wenn die Copy Blob Vorgang initiiert wird, und wenn der Kopiervorgang abgeschlossen ist. Das ETag für ein Seiten-Blob wird geändert, wenn die Copy Blob Vorgang initiiert wird, und wird fortgesetzt, während des Kopiervorgangs zu ändern. 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)

  • x-ms- committed-block-count (for append blobs only, and for version 2015-02-21 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 ist immer dieselbe Größe wie das Quell-Blob, also den Wert von der Content-Length -Header für das Ziel-Blob entspricht, für das Quell-Blob.

Wenn das Quell-Blob und Ziel-Blob identisch sind Copy Blob entfernt alle Blöcke. Wenn in einem solchen Fall Metadaten angegeben sind, werden die vorhandenen Metadaten mit den neuen Metadaten überschrieben.

Kopieren eines geleasten BLOB

Die Copy Blob Vorgang wird nur aus der Quell-Blob liest, damit der Leasezustand des Quell-Blob keine Rolle spielt. Allerdings die Copy Blob Vorgang speichert das ETag des Quell-Blob aus, wenn der Kopiervorgang initiiert wird. 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 eine unbegrenzte aktive Lease verfügt, müssen Sie seine Lease-ID angeben, im Aufruf der Copy Blob Vorgang. 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)

Die Copy Blob Vorgang schließt den Kopiervorgang asynchron. Mithilfe der folgenden Tabelle bestimmen den nächsten Schritt basierend auf den vom zurückgegebenen Statuscode Copy Blob:

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. Abrufen der Ziel-Blob mit Get Blob Properties X-ms-Copy-Status zu untersuchen, bis der Kopiervorgang abgeschlossen wird oder fehlschlägt.

4xx, 500 oder 503

Kopiervorgang fehlgeschlagen.

Während und nach einem Copy Blob Operation, die Eigenschaften des Ziel-Blob enthalten die Kopie-ID des der Copy Blob Vorgang und die URL des Quell-Blob. Bei Abschluss des Kopiervorgangs, Blob-Dienst schreibt den Datums- und Ergebniswert-Wert (success, failed, oder aborted) an die Ziel-Blob-Eigenschaften. Wenn der Vorgang failed, die x-ms-copy-status-description -Header enthält eine Zeichenfolge mit Fehlerdetails.

Ein ausstehender Copy Blob Vorgang ist einen Timeout von zwei Wochen. Einem Kopierversuch, die nach zwei Wochen nicht abgeschlossen wurde, ein Timeout auftritt und ein leeres BLOB mit dem x-ms-copy-status Feld failed und die x-ms-copy-status-description 500 (OperationCancelled) festgelegt. 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 x-ms-copy-status-description auftretende Fehler beschreibt.

Jeder Versuch, zu ändern oder Snapshot das Ziel-Blob während des Kopiervorgangs schlägt mit 409 (Konflikt) Copy Blob läuft.

Aufrufen der Abort Copy Blob -Vorgang, sehen Sie eine x-ms-copy-status:aborted -Header und das Ziel-Blob intakte Metadaten und einen Blob-Länge von NULL Bytes haben. Wiederholen Sie den ursprünglichen Aufruf von Copy Blob die Kopie erneut zu versuchen.

Abrechnung

Dem Zielkonto ein Copy Blob Vorgang wird eine Transaktion für das Initiieren des Kopiervorgangs berechnet, und zudem fällt eine Transaktion für jede Anforderung abbrechen oder den Status des Kopiervorgangs angefordert werden.

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 Snapshot Kosten finden Sie unter Verstehen, wie Ermittlung der Gebühren für Momentaufnahmen.

Anzeigen:
© 2016 Microsoft