Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Der Copy Blob From URL Vorgang kopiert ein Blob synchron in ein Ziel innerhalb des Speicherkontos für Quellblobgrößen von bis zu 256 Mebibyte (MiB). Diese API ist ab Version 2018-03-28 verfügbar.
Die Quelle für einen Copy Blob From URL Vorgang kann ein beliebiges Blockblob mit Commit in einem beliebigen Azure-Speicherkonto sein, das entweder öffentlich oder mit einer Shared Access Signature autorisiert ist.
Anfrage
Sie können die Copy Blob From URL 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.
| 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-encryption-scope |
Wahlfrei. Gibt den Verschlüsselungsbereich für die Verschlüsselung des Anforderungsinhalts an. Dieser Header wird in Version 2020-12-06 und höher unterstützt. |
x-ms-tags |
Wahlfrei. Legt 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-copy-source-tag-option |
Wahlfrei. Mögliche Werte sind REPLACE und COPY (Groß-/Kleinschreibung beachten). Der Standardwert ist REPLACE.Wenn COPY angegeben ist, werden die Tags aus dem Quellblob in das Zielblob kopiert. Das Quellblob muss privat sein, und die Anforderung muss über die Berechtigung für den Vorgang Get Blob Tags für das Quellblob und den Set Blob Tags Operation für das Zielblob verfügen. Dies führt zu einem zusätzlichen Aufruf des Get Blob Tags Vorgangs für das Quellkonto.REPLACE legt Tags fest, die der x-ms-tags Header für das Zielblob angibt. Wenn x-ms-tags angegeben REPLACE und keine Tags vorhanden sind, werden keine Tags für das Zielblob festgelegt. Die Angabe von COPY und x-ms-tags führt zu einem Fehler 409 (Konflikt).Unterstützt in Version 2021-04-10 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 Quellblob 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-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 (Vorbedingung fehlgeschlagen) zurück. 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 Zielblob geändert wurde, gibt Blob Storage den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück. |
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 Zielblob nicht vorhanden ist. Wenn die angegebene Bedingung nicht erfüllt ist, gibt Blob Storage den Statuscode 412 (Vorbedingung fehlgeschlagen) zurück. |
x-ms-copy-source:name |
Erforderlich. Gibt die URL des Quellblobs an. Bei dem Wert kann es sich um eine URL mit einer Länge von bis zu 2 Kibibyte (KiB) handeln, die ein Blob angibt. Der Wert sollte URL-codiert sein, wie er in einem Anforderungs-URI angezeigt wird. Das Quellblob muss entweder öffentlich sein oder über eine Shared Access Signature autorisiert sein. Wenn das Quellblob öffentlich ist, ist keine Autorisierung erforderlich, um den Vorgang auszuführen. Wenn die Größe des Quellblobs größer als 256 MiB ist, schlägt die Anforderung mit dem Fehler 409 (Konflikt) fehl. Der Blobtyp des Quellblobs muss Blockblob sein. 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> |
x-ms-copy-source-authorization: <scheme> <signature> |
Wahlfrei. Gibt das Autorisierungsschema und die Signatur für die Kopierquelle an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage. Nur der Schematräger wird für Microsoft Entra unterstützt. Dieser Header wird in Version 2020-10-02 und höher unterstützt. |
x-ms-requires-sync:true |
Erforderlich. Gibt an, dass es sich um einen synchronen Copy Blob From URL Vorgang und nicht um einen asynchronen Copy Blob Vorgang handelt. |
x-ms-source-content-md5 |
Wahlfrei. Gibt einen MD5-Hash des Blobinhalts aus dem URI an. Dieser Hash wird verwendet, um die Integrität des Blobs während des Transports der Daten aus dem URI zu überprüfen. Wenn dieser Header angegeben wird, vergleicht der Speicherdienst den Hash des Inhalts, der von der Kopierquelle eingegangen ist, mit diesem Headerwert. Der MD5-Hash wird nicht mit dem Blob gespeichert. Wenn die beiden Hashes nicht übereinstimmen, schlägt der Vorgang mit dem Fehlercode 400 (Ungültige Anforderung) fehl. |
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 die Lease-ID nicht enthält oder ungültig ist, schlägt der Vorgang mit dem Statuscode 412 (Vorbedingung fehlgeschlagen) fehl. 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-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, Cool, Coldund Archive.
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-file-request-intent |
Erforderlich, wenn x-ms-copy-source es sich bei dem Header um eine Azure-Datei-URL handelt und x-ms-copy-source-authorization der Header ein OAuth-Token angibt. Zulässiger Wert ist backup. Dieser Header gibt an, dass die Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action oder Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action gewährt werden sollen, wenn sie in der RBAC-Richtlinie enthalten sind, die der Identität zugewiesen ist, die mithilfe des x-ms-copy-source-authorization-Headers autorisiert ist. Verfügbar für Version 2025-07-05 und höher. |
Anfragekörper
Keiner.
Antwort
Die Antwort enthält einen HTTP-Statuscode und eine Reihe von Antwortheadern.
Statuscode
Ein erfolgreicher Vorgang gibt den Statuscode 202 (Akzeptiert) 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 abgeschlossen ist, enthält es den ETag Wert des Zielblobs. Wenn der Kopiervorgang nicht abgeschlossen ist, enthält er den ETag Wert des leeren Blobs, das am Anfang des Kopiervorgangs erstellt wurde.Der ETag Wert wird 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 es 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. |
Date |
Ein UTC-Datums-/Uhrzeitwert, der die Uhrzeit angibt, zu der der Dienst die Antwort gesendet hat. |
x-ms-copy-id: <id> |
Zeichenfolgenbezeichner für diesen Kopiervorgang. |
x-ms-copy-status: <success> |
Gibt den Status des Kopiervorgangs an. Der Wert gibt an success , dass der Vorgang erfolgreich abgeschlossen wurde. |
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. |
x-ms-request-server-encrypted: true/false |
Legen Sie fest, true ob der Inhalt der Anforderung erfolgreich durch den angegebenen Algorithmus verschlüsselt wurde. Andernfalls ist falseder Wert . |
x-ms-encryption-scope |
Wird zurückgegeben, wenn die Anforderung einen Verschlüsselungsbereich verwendet hat, damit der Client sicherstellen kann, dass der Inhalt der Anforderung erfolgreich über den Verschlüsselungsbereich verschlüsselt wird. |
Antwortkörper
Keiner.
Beispielantwort
Im Folgenden finden Sie 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: 2018-03-28
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5
x-ms-copy-status: success
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 From URL Vorgang autorisiert werden können:
| Objekttyp | Microsoft Entra ID-Autorisierung | SAS-Autorisierung (Shared Access Signature) | Shared Key-Autorisierung (oder Shared Key Lite) |
|---|---|---|---|
| Zielblockblob | Ja | Ja | Ja |
| Quellblockblob im selben Speicherkonto | Ja | Ja | Ja |
| Quellblockblob 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 From URL 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 From URL Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle, die diese Aktion enthält:
Zielblob
- Azure RBAC-Aktion:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (zum Schreiben in ein vorhandenes Blob) oder Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (zum Schreiben eines neuen Blobs in das Ziel)
- Rolle mit den geringsten Rechten:
Quellblob innerhalb desselben Speicherkontos
- Azure RBAC-Aktion:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
- Integrierte Rolle mit den geringsten Berechtigungen:Storage-Blobdatenleser
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
Das Quell- und Zielblob für einen Copy Blob From URL Vorgang muss ein Blockblob sein.
In Version 2020-10-02 und höher wird die Microsoft Entra-Autorisierung für die Quelle des Kopiervorgangs unterstützt.
Der Vorgang Copy Blob From URL kopiert immer das gesamte Quellblob. Das Kopieren eines Bytebereichs oder einer Gruppe von Blöcken wird nicht unterstützt.
Sie können ein Quellblob in ein Zielblob kopieren, das einen anderen Namen hat. Bei dem Zielblob kann es sich um ein vorhandenes Blockblob handeln, oder um ein neues Blob, das durch den Kopiervorgang erstellt 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.
Der ETag Wert für ein Blockblob ändert sich, wenn der Copy Blob From URL Vorgang gestartet und beendet wird.
Kopieren von Blobeigenschaften und Metadaten
Wenn ein Blockblob kopiert wird, werden die folgenden Systemeigenschaften mit denselben Werten in das Zielblob kopiert:
Content-TypeContent-EncodingContent-LanguageContent-LengthCache-ControlContent-MD5Content-Disposition
Die Blockliste des Quellblobs, für die ein Commit ausgeführt wurde, wird ebenfalls in das Zielblob kopiert. Nicht festgeschriebene Blöcke werden nicht kopiert.
Das Zielblob hat immer die gleiche Größe wie das Quellblob, sodass der Wert des Content-Length Headers für das Zielblob mit dem Wert dieses Headers für das Quellblob übereinstimmt.
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 im Vorgang Set Blob Tags 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 From URL Vorgang liest nur aus dem Quellblob, sodass der Leasestatus des Quellblobs keine Rolle spielt.
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 From URL Anforderungen basierend auf dem Speicherkontotyp:
| Vorgang | Speicherkontotyp | Abrechnungskategorie |
|---|---|---|
| Kopieren des Blobs aus der URL (Zielkonto1) | Premium, Blockblob Standard „Allgemein v2“ Standard „Allgemein v1“ |
Schreibvorgänge |
| Kopieren des Blobs aus URL (Quellkonto2) | Premium, Blockblob Standard „Allgemein v2“ Standard „Allgemein v1“ |
Lesevorgänge |
1Das Zielkonto wird mit einer Transaktion belastet, um den Schreibvorgang zu initiieren.
arabische ZifferDas Quellkonto führt 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.
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.
Siehe auch
Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes
Verstehen, wie für Snapshots Gebühren anfallen