Blob kopiëren

Artikel
04/06/2023

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 naar een blob wordt gekopieerd, 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?sastoken` In versies vóór 2012-02-12 kunnen blobs alleen worden gekopieerd binnen hetzelfde account en kan een bronnaam deze 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 is mislukt). In versie 2012-02-12 en hoger moet deze waarde een actieve oneindige lease voor een geleasde 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 die moet worden ingesteld op de doel-blob. Deze koptekst is alleen voor pagina-blobs op een Premium-account met versie 2017-04-17 en hoger. Zie Premium-opslag 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-bloblagen worden ondersteund voor Blob Storage- of Algemeen v2-accounts. Geldige waarden zijn `Hot`, `Cool`en `ArchiveCold` . Opmerking:`Cold` laag wordt ondersteund voor versie 2021-12-02 en hoger. Zie Dynamische, statische en archiefopslaglagen voor gedetailleerde informatie over blok-bloblagen.
`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 op versie 2019-12-12 of hoger. Deze header is alleen geldig voor toevoeg-blobs. De doel-blob wordt verzegeld 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 op 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 op 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 te verlagen. Een `locked` waarde geeft aan dat deze acties verboden zijn.
`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`	In versie 2012-02-12 en hoger, als het kopiëren is voltooid, 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`	Identificeert op unieke wijze 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 in versie 2009-09-19 en hoger.
`Date`	Een UTC-datum/tijd-waarde die het tijdstip 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 Shared Key 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.

Belangrijk

Microsoft raadt aan Microsoft Entra ID met beheerde identiteiten te gebruiken om aanvragen voor Azure Storage te autoriseren. Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak in vergelijking met autorisatie van gedeelde sleutels.

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 door Azure beheerde 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 behulp van 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, beheerde identiteit of service-principal om de Copy Blob bewerking aan te roepen, en de ingebouwde Azure RBAC-rol met de minste bevoegdheden 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 de bestemming)
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.

Een Shared Access Signature (SAS) biedt beveiligde gedelegeerde toegang tot resources in een opslagaccount. Met een SAS hebt u gedetailleerde controle over hoe een client toegang heeft tot gegevens. U kunt opgeven tot welke resource de client toegang heeft, welke machtigingen ze hebben voor deze resources en hoe lang de SAS geldig is.

De Copy Blob bewerking ondersteunt drie typen handtekeningen voor gedeelde toegang: SAS voor gebruikersdelegatie, service-SAS en account-SAS.

Als best practice voor beveiliging raden we u aan Microsoft Entra referenties te gebruiken in plaats van de opslagaccountsleutel, die gemakkelijker kan worden aangetast. Als voor uw toepassingsontwerp handtekeningen voor gedeelde toegang zijn vereist, gebruikt u indien mogelijk Microsoft Entra referenties om een SAS voor gebruikersdelegatie te maken.

Wanneer toegang tot gedeelde sleutel niet is toegestaan voor het opslagaccount, is een service-SAS-token of een ACCOUNT-SAS-token niet toegestaan op een aanvraag voor Blob Storage. Zie Begrijpen hoe het niet toewijzen van gedeelde sleutel van invloed is op SAS-tokens voor meer informatie.

SAS voor gebruikersdelegering

Een SAS voor gebruikersdelegatie wordt beveiligd met Microsoft Entra referenties en ook met de machtigingen die zijn opgegeven voor de SAS.

Voor het aanroepen van de Copy Blob bewerking met behulp van een SAS-token dat is gedelegeerd aan een blob-resource, is de volgende machtiging vereist als onderdeel van het SAS-token voor gebruikersdelegatie.

Bewerking	Objecttype	Ondertekende machtiging
Blob kopiëren	Doel-blob (nieuw)	Creatie (c) of Schrijven (w)
Blob kopiëren	Doel-blob (bestaand)	Schrijven (w)
Blob kopiëren	Bron-blob (binnen hetzelfde opslagaccount)	Lezen (r)
Blob kopiëren	Bron-blob (in een ander opslagaccount)	Lezen (r)

Zie een SAS voor gebruikersdelegering Creatie voor meer informatie over de SAS voor gebruikersdelegatie.

Service-SAS

Een service-SAS wordt beveiligd met de sleutel van het opslagaccount. Een service-SAS delegeert toegang tot een resource in één Azure Storage-service, zoals blobopslag.

Voor het aanroepen van de Copy Blob bewerking met behulp van een SAS-token dat is gedelegeerd aan een blob-resource, is de volgende machtiging vereist als onderdeel van het service-SAS-token.

Bewerking	Objecttype	Ondertekende machtiging
Blob kopiëren	Doel-blob (nieuw)	Creatie (c) of Schrijven (w)
Blob kopiëren	Doel-blob (bestaand)	Schrijven (w)
Blob kopiëren	Bron-blob (binnen hetzelfde opslagaccount)	Lezen (r)
Blob kopiëren	Bron-blob (in een ander opslagaccount)	Lezen (r)

Zie een service-SAS Creatie voor meer informatie over de service-SAS.

Account-SAS

Een account-SAS wordt beveiligd met de sleutel van het opslagaccount. Een account-SAS delegeert toegang tot resources in een of meer van de opslagservices. Alle bewerkingen die beschikbaar zijn via een service- of gebruikersdelegatie-SAS zijn ook beschikbaar via een account-SAS.

In de volgende tabel ziet u het ondertekende resourcetype en de ondertekende machtigingen die moeten worden opgegeven bij het delegeren van toegang:

Bewerking	Objecttype	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Blob kopiëren	Doel-blob (nieuw)	Blob (b)	Object (o)	Creatie (c) of Schrijven (w)
Blob kopiëren	Doel-blob (bestaand)	Blob (b)	Object (o)	Schrijven (w)
Blob kopiëren	Bron-blob (binnen hetzelfde opslagaccount)	Blob (b)	Object (o)	Lezen (r)
Blob kopiëren	Bron-blob (in een ander opslagaccount)	Blob (b)	Object (o)	Lezen (r)

Zie een account-SAS Creatie voor meer informatie over de account-SAS.

Opmerkingen

In versie 2012-02-12 en hoger kan de Copy Blob bewerking asynchroon worden voltooid. Deze bewerking retourneert een kopie-id die u kunt gebruiken om de kopieerbewerking te controleren of te annuleren. Vanwege de asynchrone aard van de kopieerbewerking kopieert Blob Storage blobs naar beste vermogen. De Blob-service kopieert blobs wanneer serverresources niet worden gebruikt door andere taken, zodat een kopie niet gegarandeerd onmiddellijk wordt 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 een ander opslagaccount te kopiëren naar een account dat is gemaakt vóór 7 juni 2012, 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 van hetzelfde blobtype zijn (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 vanuit 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 opgesomd en worden niet-lege bereiken gekopieerd.

Voor een blok- of toevoeg-blob maakt Blob Storage een toegewezen blob met een lengte van 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-doorgevoerde blokken worden niet gekopieerd. Aan het einde van de kopieerbewerking heeft de doel-blob hetzelfde aantal vastgelegde 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 biedt ETag , zullen wijzigingen in de bron tijdens de kopieerbewerking ertoe leiden 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 duur zijn niet toegestaan.

De ETag waarde voor een blok-blob wordt gewijzigd 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 met dezelfde waarden:

Content-Type
Content-Encoding
Content-Language
Content-Length
Cache-Control
Content-MD5
Content-Disposition
x-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. Eventuele niet-doorgevoerde blokken worden niet gekopieerd.

De doel-blob is altijd even groot 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- en doel-blob hetzelfde zijn, Copy Blob worden alle niet-doorgevoerde blokken verwijderd. Als in dit geval metagegevens worden opgegeven, worden de bestaande metagegevens overschreven met de nieuwe metagegevens.

Als de x-ms-tags header tags voor de doel-blob bevat, moeten deze worden gecodeerd met queryreeksen. 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 geleasede blob kopiëren

De Copy Blob bewerking leest alleen uit de bron-blob, dus de leasestatus van de bron-blob is niet van belang. 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 van 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 die een andere naam heeft 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 alle 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 (doelaccount¹)	Premium-blok-blob Standard v2 voor algemeen gebruik Standard v1 voor algemeen gebruik	Schrijfbewerkingen
Blob kopiëren (bronaccount²)	Premium-blok-blob Standard v2 voor algemeen gebruik Standard v1 voor algemeen gebruik	Leesbewerkingen

¹Het doelaccount wordt in rekening gebracht voor één transactie om de schrijfbewerking te initiëren.
²Wanneer 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

Delen via