Blob kopiëren
Met de Copy Blob bewerking wordt een blob gekopieerd naar een doel in het opslagaccount.
In versie 2012-02-12 en hoger kan de bron voor een Copy Blob bewerking een vastgelegde blob in elk Azure-opslagaccount zijn.
Vanaf versie 2015-02-21 kan de bron voor een Copy Blob bewerking een Azure-bestand in elk Azure-opslagaccount zijn.
Notitie
Alleen opslagaccounts die zijn gemaakt op of na 7 juni 2012, staan de Copy Blob bewerking toe om te kopiëren vanuit een ander opslagaccount.
Aanvraag
U kunt de Copy Blob aanvraag als volgt samenstellen. We raden HTTPS aan. Vervang myaccount door de naam van uw opslagaccount, mycontainer door de naam van uw container en myblob door de naam van uw doel-blob.
Vanaf versie 2013-08-15 kunt u een SAS (Shared Access Signature) opgeven voor de doel-blob als deze zich in hetzelfde account bevindt als de bron-blob. Vanaf versie 2015-04-05 kunt u ook een Shared Access Signature opgeven voor de doel-blob als deze zich in een ander opslagaccount bevinden.
| AANVRAAG-URI voor PUT-methode | HTTP-versie |
|---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob |
HTTP/1.1 |
URI voor de geëmuleerde opslagservice
Wanneer u een aanvraag voor de geëmuleerde opslagservice indient, geeft u de hostnaam van de emulator en Azure Blob Storage poort op als 127.0.0.1:10000, gevolgd door de naam van het geëmuleerde opslagaccount:
| AANVRAAG-URI voor PUT-methode | HTTP-versie |
|---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob |
HTTP/1.1 |
Zie Use the Azurite emulator for local Azure Storage development (De Azurite-emulator gebruiken voor lokale Azure Storage-ontwikkeling) voor meer informatie.
URI-parameters
U kunt de volgende aanvullende parameters opgeven voor de aanvraag-URI:
| Parameter | Beschrijving |
|---|---|
timeout |
Optioneel. De timeout parameter wordt uitgedrukt in seconden. Zie Time-outs instellen voor Blob Storage-bewerkingen voor meer informatie. |
Aanvraagheaders
In de volgende tabel worden vereiste en optionele aanvraagheaders beschreven:
| Aanvraagheader | Beschrijving |
|---|---|
Authorization |
Vereist. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening op. Zie Aanvragen autoriseren voor Azure Storage voor meer informatie. |
Date of x-ms-date |
Vereist. Geef de Coordinated Universal Time (UTC) op voor de aanvraag. Zie Aanvragen autoriseren voor Azure Storage voor meer informatie. |
x-ms-version |
Vereist voor alle geautoriseerde aanvragen. Zie Versiebeheer voor de Azure Storage-services voor meer informatie. |
x-ms-meta-name:value |
Optioneel. Hiermee geeft u een door de gebruiker gedefinieerd naam/waardepaar op dat is gekoppeld aan de blob. Als er geen naam-waardeparen zijn opgegeven, kopieert de bewerking de metagegevens van de bron-blob of het bronbestand naar de doel-blob. Als een of meer naam-/waardeparen zijn opgegeven, wordt de doel-blob gemaakt met de opgegeven metagegevens en worden metagegevens niet gekopieerd uit de bron-blob of het bronbestand. Vanaf versie 2009-09-19 moeten namen van metagegevens voldoen aan de naamgevingsregels voor C#-id's. Zie Containers, blobs en metagegevens een naam geven en hiernaar verwijzen voor meer informatie. |
x-ms-tags |
Optioneel. Hiermee stelt u de opgegeven query-tekenreeks gecodeerde tags op de blob. Tags worden niet gekopieerd uit de kopieerbron. Zie Opmerkingen voor meer informatie. Ondersteund in versie 2019-12-12 en hoger. |
x-ms-source-if-modified-since |
Optioneel. Een DateTime waarde. Geef deze voorwaardelijke header op om de blob alleen te kopiëren als de bron-blob is gewijzigd sinds de opgegeven datum/tijd. Als de bron-blob niet is gewijzigd, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). U kunt deze header niet opgeven als de bron een Azure-bestand is. |
x-ms-source-if-unmodified-since |
Optioneel. Een DateTime waarde. Geef deze voorwaardelijke header op om de blob alleen te kopiëren als de bron-blob niet is gewijzigd sinds de opgegeven datum/tijd. Als de bron-blob is gewijzigd, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). U kunt deze header niet opgeven als de bron een Azure-bestand is. |
x-ms-source-if-match |
Optioneel. Een ETag waarde. Geef deze voorwaardelijke header op om de bron-blob alleen te kopiëren als ETag de waarde overeenkomt met de opgegeven waarde. Als de waarden niet overeenkomen, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). U kunt deze header niet opgeven als de bron een Azure-bestand is. |
x-ms-source-if-none-match |
Optioneel. Een ETag waarde. Geef deze voorwaardelijke header op om de blob alleen te kopiëren als de ETag waarde niet overeenkomt met de opgegeven waarde. Als de waarden identiek zijn, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). U kunt deze header niet opgeven als de bron een Azure-bestand is. |
If-Modified-Since |
Optioneel. Een DateTime waarde. Geef deze voorwaardelijke header op om de blob alleen te kopiëren als de doel-blob is gewijzigd sinds de opgegeven datum/tijd. Als de doel-blob niet is gewijzigd, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). |
If-Unmodified-Since |
Optioneel. Een DateTime waarde. Geef deze voorwaardelijke header op om de blob alleen te kopiëren als de doel-blob niet is gewijzigd sinds de opgegeven datum/tijd. Als de doel-blob is gewijzigd, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). |
If-Match |
Optioneel. Een ETag waarde. Geef een ETag waarde op voor deze voorwaardelijke header om de blob alleen te kopiëren als de opgegeven ETag waarde overeenkomt met de ETag waarde voor een bestaande doel-blob. Als de waarden niet overeenkomen, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). |
If-None-Match |
Optioneel. Een ETag waarde of het jokerteken (*).Geef een ETag waarde op voor deze voorwaardelijke header om de blob alleen te kopiëren als de opgegeven ETag waarde niet overeenkomt met de ETag waarde voor de doel-blob.Geef het jokerteken (*) op om de bewerking alleen uit te voeren als de doel-blob niet bestaat. Als niet aan de opgegeven voorwaarde wordt voldaan, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). |
x-ms-copy-source:name |
Vereist. Hiermee geeft u de naam van de bron-blob of het bronbestand. Vanaf versie 2012-02-12 kan deze waarde een URL van maximaal 2 kibibytes (KiB) zijn die een blob aangeeft. De waarde moet een URL zijn die is gecodeerd zoals deze wordt weergegeven in een aanvraag-URI. De leesbewerking op een bron-blob in hetzelfde opslagaccount kan worden geautoriseerd via een gedeelde sleutel. Vanaf versie 2017-11-09 kunt u ook Microsoft Entra ID gebruiken om de leesbewerking op de bron-blob te autoriseren. Als de bron echter een blob in een ander opslagaccount is, moet de bron-blob openbaar zijn of moet de toegang tot de blob worden geautoriseerd via een shared access signature. Als de bron-blob openbaar is, is er geen autorisatie vereist om de kopieerbewerking uit te voeren. Vanaf versie 2015-02-21 kan het bronobject een bestand in Azure Files zijn. Als het bronobject een bestand is dat wordt gekopieerd naar een blob, moet het bronbestand worden geautoriseerd via een shared access signature, ongeacht of het zich in hetzelfde account of in een ander account bevindt. Alleen opslagaccounts die zijn gemaakt op of na 7 juni 2012, staan de Copy Blob bewerking toe om te kopiëren vanuit een ander opslagaccount.Hier volgen enkele voorbeelden van bronobject-URL's: - 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>Wanneer het bronobject een bestand in Azure Files is, gebruikt de bron-URL de volgende indeling. Houd er rekening mee dat de URL een geldig SAS-token voor het bestand moet bevatten. - https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastokenIn versies vóór 2012-02-12 kunnen blobs alleen worden gekopieerd binnen hetzelfde account en kan een bronnaam de volgende indelingen gebruiken: - Blob in benoemde container: /accountName/containerName/blobName- Momentopname in benoemde container: /accountName/containerName/blobName?snapshot=<DateTime>- Blob in hoofdcontainer: /accountName/blobName- Momentopname in hoofdcontainer: /accountName/blobName?snapshot=<DateTime> |
x-ms-lease-id:<ID> |
Vereist als de doel-blob een actieve lease heeft. De lease-id die voor deze header is opgegeven, moet overeenkomen met de lease-id van de doel-blob. Als de aanvraag de lease-id niet bevat of als de id niet geldig is, mislukt de bewerking met statuscode 412 (voorwaarde is mislukt). Als deze header is opgegeven en de doel-blob momenteel geen actieve lease heeft, mislukt de bewerking met statuscode 412 (voorwaarde mislukt). In versie 2012-02-12 en hoger moet deze waarde een actieve oneindige lease voor een geleasede blob opgeven. Een lease-id met een eindige duur mislukt met statuscode 412 (voorwaarde mislukt). |
x-ms-source-lease-id: <ID> |
Optioneel voor versies vóór 2012-02-12 (niet ondersteund in 2012-02-12 en hoger). Geef deze header op om de Copy Blob bewerking alleen uit te voeren als de opgegeven lease-id overeenkomt met de actieve lease-id van de bron-blob.Als deze header is opgegeven en de bron-blob momenteel geen actieve lease heeft, mislukt de bewerking met statuscode 412 (voorwaarde mislukt). |
x-ms-client-request-id |
Optioneel. Biedt een door de client gegenereerde, ondoorzichtige waarde met een limiet van 1 KiB die wordt vastgelegd in de logboeken wanneer logboekregistratie is geconfigureerd. We raden u ten zeerste aan deze header te gebruiken om activiteiten aan de clientzijde te correleren met aanvragen die de server ontvangt. |
x-ms-access-tier |
Optioneel. Hiermee geeft u de laag moet worden ingesteld op de doel-blob. Deze header is alleen voor pagina-blobs op een Premium-account met versie 2017-04-17 en hoger. Zie Premium Storage met hoge prestaties en beheerde schijven voor VM's voor een volledige lijst met ondersteunde lagen. Deze header wordt ondersteund op versie 2018-11-09 en hoger voor blok-blobs. Blok-blob-lagen worden ondersteund in Blob Storage- of Algemeen v2-accounts. Geldige waarden zijn Hot, Coolen ArchiveCold . Opmerking:Cold laag wordt ondersteund voor versie 2021-12-02 en hoger. Zie Dynamische, statische en archiefopslaglagen voor gedetailleerde informatie over opslaglagen voor blokblobs. |
x-ms-rehydrate-priority |
Optioneel. Geeft de prioriteit aan waarmee een gearchiveerde blob moet worden gerehydrateerd. Deze header wordt ondersteund op versie 2019-02-02 en hoger voor blok-blobs. Geldige waarden zijn High en Standard. U kunt de prioriteit voor een blob slechts eenmaal instellen. Deze header wordt genegeerd bij volgende aanvragen naar dezelfde blob. De standaardprioriteit zonder deze header is Standard. |
x-ms-seal-blob |
Optioneel. Ondersteund in versie 2019-12-12 of hoger. Deze header is alleen geldig voor toevoeg-blobs. Het verzegelt de doel-blob nadat de kopieerbewerking is voltooid. |
x-ms-immutability-policy-until-date |
Versie 2020-06-12 en hoger. Hiermee geeft u de retentie-tot-datum die moet worden ingesteld voor de blob. Dit is de datum totdat de blob kan worden beveiligd tegen wijziging of verwijdering. Het volgt RFC1123 indeling. |
x-ms-immutability-policy-mode |
Versie 2020-06-12 en hoger. Hiermee geeft u de beleidsmodus voor onveranderbaarheid op die moet worden ingesteld voor de blob. Geldige waarden zijn unlocked en locked. Een unlocked waarde geeft aan dat de gebruiker het beleid kan wijzigen door de retentie-tot-datum te verhogen of verlagen. Een locked waarde geeft aan dat deze acties niet zijn toegestaan. |
x-ms-legal-hold |
Versie 2020-06-12 en hoger. Hiermee geeft u de juridische bewaring moet worden ingesteld voor de blob. Geldige waarden zijn true en false. |
Deze bewerking ondersteunt de x-ms-if-tags voorwaardelijke headers en x-ms-source-if-tags alleen als aan de opgegeven voorwaarde wordt voldaan. Zie Voorwaardelijke headers opgeven voor Blob Storage-bewerkingen voor meer informatie.
Aanvraagbody
Geen.
Antwoord
Het antwoord bevat een HTTP-statuscode en een set antwoordheaders.
Statuscode
In versie 2012-02-12 en hoger retourneert een geslaagde bewerking statuscode 202 (Geaccepteerd).
In versies vóór 2012-02-12 retourneert een geslaagde bewerking statuscode 201 (Gemaakt).
Zie Status- en foutcodes voor meer informatie over statuscodes.
Antwoordheaders
Het antwoord voor deze bewerking bevat de volgende headers. Het antwoord kan ook extra standaard-HTTP-headers bevatten. Alle standaardheaders voldoen aan de HTTP/1.1-protocolspecificatie.
| Antwoordheader | Description |
|---|---|
ETag |
Als de kopie is voltooid in versie 2012-02-12 en hoger, bevat deze header de ETag waarde van de doel-blob. Als het kopiëren niet is voltooid, bevat de header de ETag waarde van de lege blob die is gemaakt aan het begin van de kopieerbewerking.In versies vóór 2012-02-12 retourneert deze header de ETag waarde voor de doel-blob.In versie 2011-08-18 en hoger staat de ETag waarde tussen aanhalingstekens. |
Last-Modified |
Retourneert de datum/tijd waarop de kopieerbewerking naar de doel-blob is voltooid. |
x-ms-request-id |
Uniek identificeert de aanvraag die is gedaan. U kunt deze header gebruiken om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossen voor meer informatie. |
x-ms-version |
Geeft de versie van Blob Storage aan die wordt gebruikt om de aanvraag uit te voeren. Deze header wordt geretourneerd voor aanvragen die zijn gedaan op basis van versie 2009-09-19 en hoger. |
Date |
Een UTC-datum/tijd-waarde die de tijd aangeeft waarop de service het antwoord heeft verzonden. |
x-ms-copy-id: <id> |
Versie 2012-02-12 en hoger. Biedt een tekenreeks-id voor deze kopieerbewerking. Gebruik met Get Blob of Get Blob Properties om de status van deze kopieerbewerking te controleren of geef door aan Abort Copy Blob om een in behandeling zijnde kopieerbewerking te annuleren. |
x-ms-copy-status: <success ¦ pending> |
Versie 2012-02-12 en hoger. Geeft de status van de kopieerbewerking aan met de volgende waarden: - success: de bewerking is voltooid.- pending: de bewerking wordt uitgevoerd. |
x-ms-version-id: <DateTime> |
Versie 2019-12-12 en hoger. Identificeert de blob op unieke wijze op basis van de versie. U kunt deze ondoorzichtige waarde gebruiken in volgende aanvragen voor toegang tot deze versie van de blob. |
x-ms-client-request-id |
Kan worden gebruikt om problemen met aanvragen en bijbehorende antwoorden op te lossen. De waarde van deze header is gelijk aan de waarde van de x-ms-client-request-id header, als deze aanwezig is in de aanvraag en de waarde maximaal 1024 zichtbare ASCII-tekens is. Als de x-ms-client-request-id header niet aanwezig is in de aanvraag, is deze header niet aanwezig in het antwoord. |
Hoofdtekst van de reactie
Geen.
Voorbeeldantwoord
De volgende code is een voorbeeldantwoord voor een aanvraag om een blob te kopiëren:
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>
Autorisatie
Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. In de volgende tabel wordt beschreven hoe de doel- en bronobjecten voor een Copy Blob bewerking kunnen worden geautoriseerd:
| Objecttype | Microsoft Entra ID autorisatie | SAS-autorisatie (Shared Access Signature) | Autorisatie van gedeelde sleutels (of Gedeelde sleutel Lite) |
|---|---|---|---|
| Doel-blob | Ja | Ja | Ja |
| Bron-blob in hetzelfde opslagaccount | Ja | Ja | Ja |
| Bron-blob in een ander opslagaccount | Nee | Ja | Nee |
Als een aanvraag tags opgeeft in de x-ms-tags aanvraagheader, moet de aanroeper voldoen aan de autorisatievereisten van de bewerking Blobtags instellen .
U kunt de Copy Blob bewerking autoriseren zoals hieronder wordt beschreven. Houd er rekening mee dat een bron-blob in een ander opslagaccount afzonderlijk moet worden geautoriseerd via een SAS-token met de machtiging Lezen (r). Zie de details voor de aanvraagheader voor meer informatie over bron-blob-autorisatie x-ms-copy-source.
Azure Storage ondersteunt het gebruik van Microsoft Entra ID om aanvragen voor blobgegevens te autoriseren. Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipal. De beveiligingsprincipal kan een gebruiker, groep, toepassingsservice-principal of beheerde Azure-identiteit zijn. De beveiligingsprincipal wordt geverifieerd door Microsoft Entra ID om een OAuth 2.0-token te retourneren. Het token kan vervolgens worden gebruikt om een aanvraag voor de Blob-service te autoriseren.
Zie Toegang tot blobs autoriseren met Microsoft Entra ID voor meer informatie over autorisatie met behulp van Microsoft Entra ID.
Machtigingen
Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra gebruiker, groep of service-principal om de Copy Blob bewerking aan te roepen, en de minst bevoorrechte ingebouwde Azure RBAC-rol die deze actie omvat:
Doel-blob
- Azure RBAC-actie:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (voor schrijven naar een bestaande blob) of Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (voor het schrijven van een nieuwe blob naar het doel)
- Ingebouwde rol met minimale bevoegdheden:Inzender voor opslagblobgegevens
Bron-blob binnen hetzelfde opslagaccount
- Azure RBAC-actie:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
- Ingebouwde rol met minimale bevoegdheden:Lezer voor opslagblobgegevens
Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.
Opmerkingen
In versie 2012-02-12 en hoger kan de Copy Blob bewerking asynchroon worden voltooid. Met deze bewerking wordt een kopieer-id geretourneerd die u kunt gebruiken om de kopieerbewerking te controleren of te annuleren. Vanwege de asynchrone aard van de kopieerbewerking kopieert Blob Storage naar beste vermogen blobs. De Blob-service kopieert blobs wanneer serverresources niet worden gebruikt door andere taken, dus een kopie wordt niet gegarandeerd onmiddellijk gestart of voltooid binnen een opgegeven periode.
De bron-blob voor een kopieerbewerking kan een blok-blob, een toevoeg-blob, een pagina-blob of een momentopname zijn. Als de doel-blob al bestaat, moet deze van hetzelfde blobtype zijn als de bron-blob. Elke bestaande doel-blob wordt overschreven. U kunt de doel-blob niet wijzigen terwijl er een kopieerbewerking wordt uitgevoerd.
In versie 2015-02-21 en hoger kan de bron voor de kopieerbewerking ook een bestand in Azure Files zijn. Als de bron een bestand is, moet het doel een blok-blob zijn.
Meerdere bewerkingen in behandeling Copy Blob binnen een account kunnen opeenvolgend worden verwerkt. Een doel-blob kan slechts één openstaande Copy Blob bewerking hebben. Met andere woorden, een blob kan niet de bestemming zijn voor meerdere bewerkingen die in behandeling zijn Copy Blob . Een poging om een blob te kopiëren naar een doel-blob waarvoor al een kopieerbewerking in behandeling is, mislukt met statuscode 409 (conflict).
Alleen opslagaccounts die zijn gemaakt op of na 7 juni 2012, staan de Copy Blob bewerking toe om te kopiëren vanuit een ander opslagaccount. Een poging om te kopiëren van een ander opslagaccount naar een account dat vóór 7 juni 2012 is gemaakt, mislukt met statuscode 400 (Ongeldige aanvraag).
Met de Copy Blob bewerking wordt altijd de hele bron-blob of het hele bronbestand gekopieerd. Het kopiëren van een bereik van bytes of een set blokken wordt niet ondersteund.
Een Copy Blob bewerking kan een van de volgende vormen hebben:
U kunt een bron-blob kopiëren naar een doel-blob met een andere naam. De doel-blob kan een bestaande blob zijn van hetzelfde blobtype (blok, toevoegen of pagina), of het kan een nieuwe blob zijn die door de kopieerbewerking wordt gemaakt.
U kunt een bron-blob kopiëren naar een doel-blob met dezelfde naam, waardoor de doel-blob in feite wordt vervangen. Met een dergelijke kopieerbewerking worden alle niet-doorgevoerde blokken verwijderd en worden de metagegevens van de blob overschreven.
U kunt een bronbestand in Azure Files kopiëren naar een doel-blob. De doel-blob kan een bestaande blok-blob zijn of een nieuwe blok-blob die door de kopieerbewerking wordt gemaakt. Kopiëren van bestanden naar pagina-blobs of toevoeg-blobs wordt niet ondersteund.
U kunt een momentopname over de basis-blob kopiëren. Door een momentopname te promoveren naar de positie van de basis-blob, kunt u een eerdere versie van een blob herstellen.
U kunt een momentopname kopiëren naar een doel-blob met een andere naam. De resulterende doel-blob is een beschrijfbare blob en geen momentopname.
Wanneer u kopieert vanaf een pagina-blob, maakt Blob Storage een doelpagina-blob met de lengte van de bron-blob. In eerste instantie bevat de pagina-blob alle nullen. Vervolgens worden de bronpaginabereiken geïnventariseerd en worden niet-lege bereiken gekopieerd.
Voor een blok-blob of een toevoeg-blob maakt Blob Storage een vastgelegde blob met de lengte nul voordat deze bewerking wordt geretourneerd.
Wanneer u kopieert vanuit een blok-blob, worden alle vastgelegde blokken en de bijbehorende blok-id's gekopieerd. Niet-verzonden blokken worden niet gekopieerd. Aan het einde van de kopieerbewerking heeft de doel-blob hetzelfde vastgelegde aantal blokken als de bron.
Wanneer u kopieert vanuit een toevoeg-blob, worden alle vastgelegde blokken gekopieerd. Aan het einde van de kopieerbewerking heeft de doel-blob minder dan of hetzelfde aantal vastgelegde blokken als de bron-blob.
Voor alle blobtypen kunt u of Get Blob Properties aanroepen Get Blob op de doel-blob om de status van de kopieerbewerking te controleren. De uiteindelijke blob wordt doorgevoerd wanneer de kopieerbewerking is voltooid.
Wanneer de bron van een kopieerbewerking waarden opbiedt ETag , zullen wijzigingen in de bron terwijl de kopieerbewerking wordt uitgevoerd, ervoor zorgen dat die bewerking mislukt. Een poging om de doel-blob te wijzigen terwijl een kopie wordt uitgevoerd, mislukt met statuscode 409 (conflict). Als de doel-blob een oneindige lease heeft, moet de lease-id worden doorgegeven aan Copy Blob. Leases met een eindige looptijd zijn niet toegestaan.
De ETag waarde voor een blok-blob verandert wanneer de Copy Blob bewerking wordt gestart en wanneer de bewerking is voltooid. De ETag waarde voor een pagina-blob verandert wanneer de Copy Blob bewerking wordt gestart en deze blijft regelmatig veranderen tijdens de kopieerbewerking. De inhoud van een blok-blob is pas zichtbaar via een Get opdracht nadat de volledige kopieerbewerking is voltooid.
Blob-eigenschappen, -tags en -metagegevens kopiëren
Wanneer een blob wordt gekopieerd, worden de volgende systeemeigenschappen gekopieerd naar de doel-blob die dezelfde waarden heeft:
Content-TypeContent-EncodingContent-LanguageContent-LengthCache-ControlContent-MD5Content-Dispositionx-ms-blob-sequence-number(alleen voor pagina-blobs)x-ms-committed-block-count(alleen voor toevoeg-blobs en alleen voor versie 2015-02-21)
De vastgelegde blokkeringslijst van de bron-blob wordt ook gekopieerd naar de doel-blob, als de blob een blok-blob is. Niet-doorgevoerde blokken worden niet gekopieerd.
De doel-blob heeft altijd dezelfde grootte als de bron-blob. De waarde van de Content-Length header voor de doel-blob komt overeen met de waarde van die header voor de bron-blob.
Wanneer de bron-blob en doel-blob hetzelfde zijn, Copy Blob verwijdert u eventuele niet-doorgevoerde blokken. Als in dit geval metagegevens worden opgegeven, worden de bestaande metagegevens overschreven met de nieuwe metagegevens.
Als de x-ms-tags header tags bevat voor de doel-blob, moeten deze worden gecodeerd met querytekenreeksen. Tagsleutels en -waarden moeten voldoen aan de vereisten voor naamgeving en lengte, zoals opgegeven in Blobtags instellen.
De x-ms-tags header kan maximaal 2 kilobits tags bevatten. Als u meer tags nodig hebt, gebruikt u de Set Blob Tags bewerking.
Als de x-ms-tags header geen tags bevat, worden tags niet gekopieerd uit de bron-blob.
Een geleasde blob kopiëren
De Copy Blob bewerking leest alleen uit de bron-blob, dus de leasestatus van de bron-blob maakt niet uit. De bewerking slaat echter Copy Blob de ETag waarde van de bron-blob op wanneer de kopieerbewerking wordt gestart. Als de ETag waarde verandert voordat de kopieerbewerking is voltooid, mislukt de bewerking. U kunt wijzigingen in de bron-blob voorkomen door deze tijdens de kopieerbewerking te leasen.
Als de doel-blob een actieve oneindige lease heeft, moet u de lease-id opgeven in de aanroep naar de Copy Blob bewerking. Als de lease die u opgeeft een actieve lease met een eindige duur is, mislukt deze aanroep met statuscode 412 (Voorwaarde mislukt). Terwijl de kopieerbewerking in behandeling is, mislukt elke leasebewerking op de doel-blob met statuscode 409 (conflict). Een oneindige lease op de doel-blob wordt op deze manier vergrendeld tijdens de kopieerbewerking, ongeacht of u kopieert naar een doel-blob met een andere naam dan de bron, kopieert naar een doel-blob met dezelfde naam als de bron of een momentopname promoveert over de basis-blob.
Als de client een lease-id opgeeft voor een blob die nog niet bestaat, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt) voor aanvragen die zijn gedaan in versie 2013-08-15 en hoger. Voor eerdere versies retourneert Blob Storage statuscode 201 (gemaakt).
Blob-momentopnamen kopiëren
Wanneer een bron-blob wordt gekopieerd, worden momentopnamen of versies van de bron-blob niet gekopieerd naar de bestemming. Wanneer een doel-blob wordt overschreven met een kopie, blijven momentopnamen of versies die zijn gekoppeld aan de doel-blob intact onder de naam.
U kunt een kopieerbewerking uitvoeren om een momentopname boven de basis-blob te plaatsen, zolang deze zich in een onlinelaag bevindt (dynamisch of statisch). Op deze manier kunt u een eerdere versie van een blob herstellen. De momentopname blijft behouden, maar de bestemming wordt overschreven met een kopie die zowel kan worden gelezen als geschreven.
Blob-versies kopiëren
U kunt een kopieerbewerking uitvoeren om een versie boven de basis-blob te verhogen, zolang deze zich in een onlinelaag (dynamisch of statisch) bevindt. Op deze manier kunt u een eerdere versie van een blob herstellen. De versie blijft behouden, maar de bestemming wordt overschreven met een kopie die zowel kan worden gelezen als geschreven.
Een gearchiveerde blob kopiëren
Vanaf versie 2018-11-09 kunt u een gearchiveerde blob kopiëren naar een nieuwe blob binnen hetzelfde opslagaccount. De bron-blob blijft in de archieflaag. Wanneer de bron-blob een gearchiveerde blob is, moet de aanvraag de x-ms-access-tier header bevatten, die de laag van de doel-blob aangeeft. De doel-blob moet zich in een onlinelaag bevinden. U kunt niet kopiëren naar een blob in de archieflaag.
Vanaf versie 2021-02-12 kunt u een gearchiveerde blob kopiëren naar een onlinelaag in een ander opslagaccount, mits het doelaccount zich in dezelfde regio bevindt als het bronaccount.
De aanvraag kan mislukken als de bron-blob wordt gerehydrateerd.
Zie Dynamische, statische en archiefopslaglagen voor gedetailleerde informatie over opslaglagen op blok-blobniveau.
Werken met een kopieerbewerking in behandeling (versie 2012-02-12 en hoger)
Als de Copy Blob bewerking asynchroon wordt voltooid, gebruikt u de volgende tabel om de volgende stap te bepalen op basis van de geretourneerde statuscode:
| Statuscode | Betekenis |
|---|---|
| 202 (Geaccepteerd), x-ms-copy-status: geslaagd | De kopieerbewerking is voltooid. |
| 202 (Geaccepteerd), x-ms-copy-status: in behandeling | De kopieerbewerking is niet voltooid. Peil de doel-blob met behulp van Get Blob Properties om de x-ms-copy-status header te onderzoeken totdat de bewerking is voltooid of mislukt. |
| 4xx, 500 of 503 | De kopieerbewerking is mislukt. |
Tijdens en na een Copy Blob bewerking bevatten de eigenschappen van de doel-blob de kopie-id van de Copy Blob bewerking en de URL van de bron-blob. Wanneer de bewerking is voltooid, schrijft Blob Storage de tijd- en resultaatwaarde (success, failedof aborted) naar de eigenschappen van de doel-blob. Als de bewerking een failed resultaat heeft, bevat de x-ms-copy-status-description header een foutdetailtekenreeks.
Een bewerking in behandeling Copy Blob heeft een time-out van twee weken. Een kopieerpoging die na twee weken nog niet is voltooid, treedt op en laat een lege blob achter met het x-ms-copy-status veld ingesteld op failed en de x-ms-copy-status-description waarde 500 (OperationCancelled). Onregelmatige, niet-fatale fouten die kunnen optreden tijdens een kopieerbewerking, kunnen de voortgang van de bewerking belemmeren, maar niet tot een fout leiden. In deze gevallen x-ms-copy-status-description worden de onregelmatige fouten beschreven.
Elke poging om de doel-blob tijdens de kopieerbewerking te wijzigen of er een momentopname van te maken, mislukt met statuscode 409 (conflict), 'Blob kopiëren wordt uitgevoerd'.
Als u de Abort Copy Blob bewerking aanroept, ziet u een x-ms-copy-status:aborted header. De doel-blob heeft intacte metagegevens en een bloblengte van 0 bytes. U kunt de oorspronkelijke aanroep naar Copy Blob herhalen om de kopieerbewerking opnieuw uit te voeren.
Als de Copy Blob bewerking synchroon wordt voltooid, gebruikt u de volgende tabel om de status van de kopieerbewerking te bepalen:
| Statuscode | Betekenis |
|---|---|
| 202 (Geaccepteerd), x-ms-copy-status: geslaagd | De kopieerbewerking is voltooid. |
| 4xx, 500 of 503 | De kopieerbewerking is mislukt. |
De laag wordt overgenomen voor Premium Storage-lagen. Voor blok-blobs neemt het overschrijven van de doel-blob de dynamische of statische laag over van de bestemming als x-ms-access-tier deze niet is opgegeven. Het overschrijven van een gearchiveerde blob mislukt. Zie Dynamische, statische en archiefopslaglagen voor gedetailleerde informatie over opslaglagen op blok-blobniveau.
Billing
Prijsaanvragen kunnen afkomstig zijn van clients die gebruikmaken van Blob Storage-API's, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Met deze aanvragen worden kosten per transactie in rekening gebracht. Het type transactie is van invloed op de manier waarop de rekening in rekening wordt gebracht. Leestransacties worden bijvoorbeeld toegevoegd aan een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Copy Blob aanvragen op basis van het type opslagaccount:
| Bewerking | Type opslagaccount | Factureringscategorie |
|---|---|---|
| Blob kopiëren (doelaccount1) | Premium-blok-blob Standard v2 voor algemeen gebruik Standard v1 voor algemeen gebruik |
Schrijfbewerkingen |
| Blob kopiëren (bronaccount2) | Premium-blok-blob Standard v2 voor algemeen gebruik Standard v1 voor algemeen gebruik |
Leesbewerkingen |
1Het doelaccount wordt in rekening gebracht voor één transactie om de schrijfbewerking te initiëren.
2Wanneer het bronobject zich in een ander account bevindt, maakt het bronaccount één transactie voor elke leesaanvraag naar het bronobject.
Zie prijzen voor Azure Blob Storage voor meer informatie over prijzen voor de opgegeven factureringscategorieën.
Voor het doelaccount worden ook transactiekosten in rekening gebracht voor elke aanvraag om de kopieerbewerking te annuleren (zie Copy Blob afbreken) of om de status van de kopieerbewerking te controleren (zie Blob ophalen of Blob-eigenschappen ophalen).
Als de bron- en doelaccounts zich in verschillende regio's bevinden (bijvoorbeeld VS - noord en VS - zuid), wordt de bandbreedte die u gebruikt om de aanvraag over te dragen, in rekening gebracht bij het bronopslagaccount als uitgaand verkeer. Uitgaand verkeer tussen accounts binnen dezelfde regio is gratis.
Wanneer u een bron-blob kopieert naar een doel-blob met een andere naam binnen hetzelfde account, gebruikt u extra opslagresources voor de nieuwe blob. De kopieerbewerking resulteert vervolgens in kosten ten opzichte van het capaciteitsgebruik van het opslagaccount voor deze extra resources. Als de namen van de bron- en doel-blobs echter hetzelfde zijn binnen hetzelfde account (bijvoorbeeld wanneer u een momentopname promoveert naar de basis-blob), worden er geen extra kosten in rekening gebracht, behalve de extra kopiemetagegevens die zijn opgeslagen in versie 2012-02-12 en hoger.
Wanneer u een momentopname promoveren om de basis-blob te vervangen, worden de momentopname en de basis-blob identiek. Ze delen blokken of pagina's, dus de kopieerbewerking leidt niet tot extra kosten voor het capaciteitsgebruik van het opslagaccount. Als u echter een momentopname kopieert naar een doel-blob met een andere naam, worden voor die bewerking extra kosten in rekening gebracht voor de opslagresources die de resulterende nieuwe blob gebruikt. Twee blobs met verschillende namen kunnen geen blokken of pagina's delen, zelfs niet als ze identiek zijn. Zie Begrijpen hoe momentopnamen kosten genereren voor meer informatie over scenario's met momentopnamekosten.
Zie ook
Aanvragen voor Azure Storage autoriseren
Status en foutcodes
Blob Storage-foutcodes
Inzicht in hoe momentopnamen kosten genereren
Blob kopiëren afbreken