Blob kopiëren

Artikel
08/29/2021
21 minuten om te lezen

Met Copy Blob deze bewerking wordt een blob gekopieerd naar een bestemming binnen het opslagaccount.

In versie 2012-02-12 en hoger kan de bron voor een kopieerblobbewerking een vastgelegde blob zijn in elk Azure-opslagaccount.

Vanaf versie 2015-02-21 kan de bron voor een bewerking een Copy Blob Azure-bestand zijn in elk Azure-opslagaccount.

Notitie

Alleen opslagaccounts die zijn gemaakt op of na 7 juni 2012 staan de bewerking toe om te Copy Blob kopiëren vanuit een ander opslagaccount.

Aanvraag

De Copy Blob aanvraag kan als volgt worden samengesteld. HTTPS wordt aanbevolen. Vervang myaccount door de naam van uw opslagaccount, door de naam van uw container en door de naam van mycontainer uw myblob doelblob.

Vanaf versie 2013-08-15 kunt u een shared access signature opgeven voor de doel-blob als deze zich in hetzelfde account als de bron-blob. Vanaf versie 2015-04-05 kunt u ook een Shared Access Signature voor de doelblob opgeven als deze zich in een ander opslagaccount.

AANVRAAG-URI put-methode	HTTP-versie
`https://myaccount.blob.core.windows.net/mycontainer/myblob`	HTTP/1.1

Geëmuleerde opslagservice-URI

Wanneer u een aanvraag indient voor de geëmuleerde opslagservice, geeft u de hostnaam van de emulator en Blob service-poort op als , gevolgd door de geëmuleerde 127.0.0.1:10000 opslagaccountnaam:

AANVRAAG-URI put-methode	HTTP-versie
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob`	HTTP/1.1

Zie Using the Azure Storage Emulator for Development and Testing (De Azure Storage Emulator voor ontwikkeling en testen) voor meer informatie.

URI-parameters

De volgende aanvullende parameters kunnen worden opgegeven op de aanvraag-URI.

Parameter	Beschrijving
`timeout`	Optioneel. De `timeout` parameter wordt uitgedrukt in seconden. Zie Setting Timeouts for Blob Service Operations (Time-outs instellen voor blobservicebewerkingen) voor meer informatie.

Aanvraagheaders

In de volgende tabel worden de vereiste en optionele aanvraagheaders beschreven.

Aanvraagkoptekst	Beschrijving
`Authorization`	Vereist. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening op. Zie Aanvragen voor toegang tot Azure Storage voor meer Azure Storage.
`Date` of `x-ms-date`	Vereist. Geef de Coordinated Universal Time (UTC) op voor de aanvraag. Zie Aanvragen voor toegang tot Azure Storage voor meer Azure Storage.
`x-ms-version`	Vereist voor alle geautoriseerde aanvragen. Zie Versioning for the Azure Storage Services (Versie 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 doelblob. Als een of meer naam-waardeparen zijn opgegeven, wordt de doel-blob gemaakt met de opgegeven metagegevens en worden metagegevens niet gekopieerd uit de bronblob of het bronbestand. Vanaf versie 2009-09-19 moeten namen van metagegevens voldoen aan de naamgevingsregels voor C#-id's. Zie Naming and Referencing Containers, Blobs, and Metadata (Containers, blobs en metagegevens een naam geven en hier naar verwijzen) voor meer informatie.
`x-ms-tags`	Optioneel. Hiermee stelt u de opgegeven met queryreeks gecodeerde tags in op de blob. Tags worden niet gekopieerd uit de kopieerbron. Zie de 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 service statuscode 412 (Voorwaarde mislukt). Deze header kan niet worden opgegeven 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 sinds de opgegeven datum/tijd niet is gewijzigd. Als de bron-blob is gewijzigd, retourneert Blob service statuscode 412 (Voorwaarde mislukt). Deze header kan niet worden opgegeven 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 de ETag overeenkomt met de opgegeven waarde. Als de ETag-waarden niet overeenkomen, retourneert Blob service statuscode 412 (Voorwaarde mislukt). Deze header kan niet worden opgegeven 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 niet met de opgegeven waarde komt. Als de waarden identiek zijn, retourneert Blob service statuscode 412 (Voorwaarde mislukt). Deze header kan niet worden opgegeven 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 service 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 sinds de opgegeven datum/tijd niet is gewijzigd. Als de doel-blob is gewijzigd, retourneert Blob service 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 waarde `ETag` voor een bestaande doel-blob. Als de ETag voor de doelblob niet overeen komt met de ETag die is opgegeven voor , retourneert `If-Match` Blob service 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 overeen komt met de ETag-waarde voor de doelblob. Geef het jokerteken ( ) op om de bewerking alleen uit te voeren als de doelblob niet bestaat. Als niet aan de opgegeven voorwaarde wordt voldaan, retourneert Blob service statuscode 412 (Voorwaarde mislukt).
`x-ms-copy-source:name`	Vereist. Hiermee geeft u de naam van de bron-blob of het bronbestand op. Vanaf versie 2012-02-12 kan deze waarde een URL van maximaal 2 KiB zijn die een blob specificeert. De waarde moet URL-gecodeerd zijn zoals deze wordt weergegeven in een aanvraag-URI. Een bron-blob in hetzelfde opslagaccount kan worden geautoriseerd via een gedeelde sleutel. Als de bron echter een blob in een ander account is, moet de bron-blob openbaar zijn of 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 is het bronobject mogelijk een bestand in de Azure File-service. Als het bronobject een bestand is dat moet worden gekopieerd naar een blob, moet het bronbestand worden geautoriseerd met behulp van 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 bewerking toe om te `Copy Blob` kopiëren vanuit een ander opslagaccount. Hier zijn enkele voorbeelden van url's van bronobjecten: - `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 de Azure File-service 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 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 is opgegeven voor deze header moet overeenkomen met de lease-id van de doel-blob. Als de aanvraag de lease-id niet bevat of niet geldig is, mislukt de bewerking met statuscode 412 (Voorwaarde mislukt). Als deze header is opgegeven en de doel-blob momenteel geen actieve lease heeft, mislukt de bewerking ook met statuscode 412 (Hoofdvoorwaarde 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 beperkte duur mislukt met 412 (voorwaarde is mislukt).
`x-ms-source-lease-id: <ID>`	Optioneel, versies vóór 2012-02-12 (niet ondersteund in 2012-02-12 en hoger). Geef deze header op om de bewerking alleen `Copy Blob` 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 ook met statuscode 412 (Hoofdvoorwaarde 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 analyselogboeken wanneer logboekregistratie van opslaganalyse is ingeschakeld. Het gebruik van deze header wordt ten zeerste aanbevolen voor het correleren van activiteiten aan clientzijde met aanvragen die door de server worden ontvangen. Zie About Storage Analytics Logging and Azure Logging: Using Logs to Track Storage Requests voor meer informatie.
`x-ms-access-tier`	Optioneel. Hiermee geeft u de laag moet worden ingesteld op de doel-blob. Alleen voor pagina-blobs in een Premium-account met versie 2017-04-17 en hoger. Controleer High Performance Premium Storage beheerde schijven voor VM's voor een volledige lijst met ondersteunde lagen. Versie 2018-11-09 en hoger voor blok-blobs. Blok-blob-opslaglagen worden ondersteund in Blob Storage- of v2-accounts voor algemeen gebruik. Geldige waarden zijn `Hot` / `Cool` / `Archive` . Zie Opslaglagen voor Hot, Cool en Archive voor gedetailleerde informatie over blok-bloblagen.
`x-ms-rehydrate-priority`	Optioneel. Geeft de prioriteit aan waarmee een gearchiveerde blob moet worden gerehydrateerd. Ondersteund op versie 2019-02-02 en hoger voor blok-blobs. Geldige waarden zijn `High` / `Standard` . De prioriteit kan slechts één keer worden ingesteld voor een blob. Deze header wordt genegeerd bij volgende aanvragen voor dezelfde blob. De standaardprioriteit zonder deze header is `Standard` .
`x-ms-seal-blob`	Optioneel. Ondersteund op versie 2019-12-12 of hoger. Alleen geldig voor app-blobs. 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 datum 'retentie tot' op die moet worden ingesteld voor de blob. Dit is de datum tot de blob kan worden beveiligd tegen wijzigingen of verwijderen. Volgt de RFC1123-indeling.
`x-ms-immutability-policy-mode`	Versie 2020-06-12 en hoger. Hiermee geeft u de onveranderbaarheid beleidsmodus moet worden ingesteld op de blob. Geldige waarden zijn `unlocked` / `locked` . `unlocked` geeft aan dat de gebruiker het beleid kan wijzigen door de bewaarperiode tot heden te verhogen of te verlagen. `locked` geeft aan dat deze acties niet zijn toegestaan.
`x-ms-legal-hold`	Versie 2020-06-12 en hoger. Hiermee geeft u de juridische blokwaarde op die moet worden ingesteld voor de blob. Geldige waarden zijn `true/false` .

Deze bewerking ondersteunt de x-ms-if-tags voorwaardelijke x-ms-source-if-tags headers en alleen om te slagen als aan de opgegeven voorwaarde wordt voldaan. Zie Specifying Conditional Headers for Blob Service Operations (Voorwaardelijke headers opgeven voor blobservicebewerkingen) 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 aanvullende standaard HTTP-headers bevatten. Alle standaardheaders voldoen aan de HTTP/1.1-protocolspecificatie.

Antwoordheader	Beschrijving
`ETag`	Als het kopiëren is voltooid, bevat versie 2012-02-12 en hoger de ETag van de doel-blob. Als de kopie niet is voltooid, bevat de ETag van de lege blob die aan het begin van de kopie is gemaakt. In versies vóór 2012-02-12 retourneert de ETag 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 doelblob is voltooid.
`x-ms-request-id`	Deze header identificeert op unieke manier de aanvraag die is gemaakt en kan worden gebruikt voor het oplossen van problemen met de aanvraag. Zie Troubleshooting API Operations (Problemen met API-bewerkingen oplossen) voor meer informatie.
`x-ms-version`	Geeft de versie aan van de Blob service gebruikt om de aanvraag uit te voeren. Deze header wordt geretourneerd voor aanvragen voor versie 2009-09-19 en hoger.
`Date`	Een UTC-datum/tijd-waarde die wordt gegenereerd door de service die het tijdstip aangeeft waarop het antwoord is gestart.
`x-ms-copy-id: <id>`	Versie 2012-02-12 en hoger. Tekenreeks-id voor deze kopieerbewerking. Gebruik met of om de status van deze kopieerbewerking te controleren of door te geven aan om `Get Blob` een in behandeling zijnde kopie af te `Get Blob Properties` `Abort Copy Blob` breken.
`x-ms-copy-status: <success \| pending>`	Versie 2012-02-12 en hoger. Status van de kopieerbewerking, met deze waarden: - `success`: de kopie is voltooid. - `pending`: de kopie wordt uitgevoerd.
`x-ms-version-id: <DateTime>`	Versie 2019-12-12 en hoger. Een datum/tijd-waarde die wordt geretourneerd door de service die de blob uniek identificeert. De waarde van deze header geeft de blobversie aan en kan worden gebruikt in volgende aanvragen om toegang te krijgen tot deze versie van de blob. Deze waarde moet worden behandeld als ondoorzichtig.
`x-ms-client-request-id`	Deze header 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 header als deze aanwezig is in de aanvraag en de waarde uit `x-ms-client-request-id` 1024 zichtbare ASCII-tekens bestaat. Als de `x-ms-client-request-id` header niet aanwezig is in de aanvraag, is deze header niet aanwezig in het antwoord.

Antwoord body

Geen.

Voorbeeldreactie

Hier volgt een voorbeeld van een antwoord 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

Deze bewerking kan worden aangeroepen door de accounteigenaar. Voor aanvragen die zijn gedaan op versie 2013-08-15 en hoger, wordt een shared access signature met machtigingen voor het schrijven naar de doel-blob of de container ondersteund voor kopieerbewerkingen binnen hetzelfde account. Houd er rekening mee dat de shared access signature die is opgegeven in de aanvraag alleen van toepassing is op de doel-blob.

Toegang tot de bron-blob of het bronbestand wordt afzonderlijk geautoriseerd, zoals beschreven in de details voor de aanvraagheader x-ms-copy-source .

In de volgende tabel wordt beschreven hoe de doel- en bronobjecten voor een kopieerblobbewerking kunnen worden geautoriseerd.

Blob	Autorisatie met gedeelde sleutel/shared key Lite	Autorisatie met Shared Access Signature	Openbaar object vereist geen autorisatie
Doel-blob	Ja	Ja	Nee
Bron-blob in hetzelfde account	Ja	Ja	Ja
Bron-blob in een ander account	Nee	Ja	Ja
Bronbestand in hetzelfde account of een ander account	Nee	Ja	N.v.t.

Als een aanvraag tags met de aanvraagheader specificeert, moet de aanroeper voldoen aan de autorisatievereisten x-ms-tags van de bewerking Blob-tags instellen.

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 af te breken. Met Blob service worden blobs gekopieerd op basis van de beste inspanning.

De bron-blob voor een kopieerbewerking kan een blok-blob, een toevoegende blob, een pagina-blob of een momentopname zijn. Als de doel-blob al bestaat, moet deze van hetzelfde blobtype zijn als de bron-blob. Alle bestaande doel-blobs worden overschreven. De doel-blob kan niet worden gewijzigd terwijl een kopieerbewerking wordt uitgevoerd.

In versie 2015-02-21 en hoger kan de bron voor de kopieerbewerking ook een bestand in de Azure File-service zijn. Als de bron een bestand is, moet het doel een blok-blob zijn.

Meerdere in behandeling zijnde bewerkingen binnen een account kunnen Copy Blob opeenvolgend worden verwerkt. Een doel-blob kan slechts één openstaande kopieerblobbewerking hebben. Met andere woorden, een blob kan niet de bestemming zijn voor meerdere bewerkingen die in behandeling Copy Blob zijn. Een poging om naar een doel-blob te gaan die al een kopie in behandeling Copy Blob heeft, mislukt met statuscode 409 (Conflict).

Alleen opslagaccounts die zijn gemaakt op of na 7 juni 2012 staan de bewerking toe om te Copy Blob kopiëren vanuit een ander opslagaccount. Een poging om te kopiëren van een ander opslagaccount naar een account dat is gemaakt vóór 7 juni 2012 mislukt met statuscode 400 (Slechte aanvraag).

De bewerking kopieert altijd de hele bron-blob of het hele bestand; het kopiëren van een bereik van bytes of een set blokken Copy Blob wordt niet ondersteund.

Een Copy Blob bewerking kan een van de volgende vormen aannemen:

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 kan een nieuwe blob zijn die is gemaakt door de kopieerbewerking.
U kunt een bron-blob kopiëren naar een doel-blob met dezelfde naam, zodat de doel-blob effectief wordt vervangen. Met een dergelijke kopieerbewerking worden niet-opgenomen blokken verwijderd en worden de metagegevens van de blob overschreven.
U kunt een bronbestand in de Azure File-service kopiëren naar een doel-blob. De doel-blob kan een bestaande blok-blob zijn of een nieuwe blok-blob die door de kopieerbewerking is gemaakt. Kopiëren van bestanden naar pagina-blobs of toevoegen van blobs wordt niet ondersteund.
U kunt een momentopname kopiëren naar de basisblob. 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 schrijfbare blob en geen momentopname.

Bij het kopiëren vanuit een pagina-blob maakt Blob service een doelpagina-blob met de lengte van de bronblob, die in eerste instantie alle nullen bevat. Vervolgens worden de bronpaginabereiken geïndefeerd en worden niet-lege reeksen gekopieerd.

Voor een blok-blob of een append-blob maakt de Blob service een vastgelegde blob met een lengte van nul voordat deze bewerking wordt uitgevoerd.

Wanneer u vanaf een blok-blob kopieert, worden alle vastgelegde blokken en de blok-ID's gekopieerd. Niet-doorgestuurde blokken worden niet gekopieerd. Aan het einde van de kopieerbewerking heeft de doel-blob hetzelfde vastgelegde blok aantal als de bron.

Bij het kopiëren vanuit een append-blob worden alle vastgelegde blokken gekopieerd. Aan het einde van de kopieerbewerking heeft de doel-blob hetzelfde vastgelegde blok aantal als de bron.

Voor alle blobtypen kunt u of Get Blob aanroepen Get Blob Properties op de doelblob om de status van de kopieerbewerking te controleren. De uiteindelijke blob wordt vastgelegd wanneer de kopie is voltooid.

Wanneer de bron van een kopieerbewerking ETags levert en er wijzigingen in de bron zijn terwijl de kopie wordt uitgevoerd, mislukt de kopie. Een poging om de doel-blob te wijzigen terwijl een kopie wordt uitgevoerd, mislukt met 409 Conflict. Als de doel-blob een oneindige lease heeft, moet de lease-id worden doorgegeven aan Copy Blob . Leases met een beperkte duur zijn niet toegestaan.

De ETag voor een blok-blob verandert wanneer Copy Blob de bewerking wordt gestart en wanneer de kopie is uitgevoerd. De ETag voor een pagina-blob wordt gewijzigd wanneer de bewerking wordt gestart en blijft Copy Blob regelmatig veranderen tijdens het kopiëren. De inhoud van een blok-blob is alleen zichtbaar met behulp van een GET nadat de volledige kopie is voltooid.

Blobeigenschappen, tags en metagegevens kopiëren

Wanneer een blob wordt gekopieerd, worden de volgende systeemeigenschappen met dezelfde waarden naar de doelblob gekopieerd:

Content-Type
Content-Encoding
Content-Language
Content-Length
Cache-Control
Content-MD5
Content-Disposition
x-ms-blob-sequence-number (for page blobs only)
x-ms-committed-block-count (for append blobs only, and for version 2015-02-21 only)

De lijst met vastgelegde blokkeringen van de bron-blob wordt ook gekopieerd naar de doel-blob, als de blob een blok-blob is. Niet-doorgestuurde blokken worden niet gekopieerd.

De doel-blob heeft altijd dezelfde grootte als de bron-blob, dus de waarde van de header voor de doel-blob komt overeen met die Content-Length voor de bron-blob.

Wanneer de bron-blob en doel-blob hetzelfde zijn, Copy Blob worden alle niet-doorgestuurde blokken verwijderd. Als in dit geval metagegevens zijn opgegeven, worden de bestaande metagegevens overschreven met de nieuwe metagegevens.

Als tags voor de doel-blob worden opgegeven in de header, moeten ze worden gecodeerd met x-ms-tags een queryreeks. Tagsleutels en -waarden moeten voldoen aan de naamgevings- en lengtevereisten zoals opgegeven in Blob-tags instellen. Bovendien kan x-ms-tags de header maximaal 2 kB tags bevatten. Als er meer tags vereist zijn, gebruikt u de bewerking Blob-tags instellen.

Als tags niet worden opgegeven in de x-ms-tags header, worden ze niet gekopieerd uit de bron-blob.

Een geleasde blob kopiëren

De Copy Blob bewerking leest alleen uit de bron-blob, dus de lease-status van de bron-blob is niet van belang. De bewerking slaat Copy Blob echter de ETag van de bronblob op wanneer de kopie wordt gestart. Als de ETag-waarde verandert voordat de kopie is voltooid, mislukt de kopie. U kunt wijzigingen in de bron-blob voorkomen door deze te leasen tijdens de kopieerbewerking.

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 kopie in behandeling is, mislukt elke leasebewerking op de doelblob met statuscode 409 (Conflict). Een oneindige lease op de doel-blob wordt op deze manier vergrendeld tijdens de kopieerbewerking, of u nu kopieert naar een doel-blob met een andere naam dan de bron, naar een doel-blob kopieert met dezelfde naam als de bron of een momentopname promovert via de basisblob. Als de client een lease-id op een blob specificeert die nog niet bestaat, retourneert de Blob service statuscode 412 (Voorwaarde mislukt) voor aanvragen die zijn gedaan op basis van versie 2013-08-15 en hoger; voor eerdere versies retourneert Blob service de statuscode 201 (Gemaakt).

Momentopnamen kopiëren

Wanneer een bron-blob wordt gekopieerd, worden momentopnamen of versies van de bron-blob niet gekopieerd naar het doel. 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 het promoveren van een momentopnameblob boven de basis-blob. Op deze manier kunt u een eerdere versie van een blob herstellen. De momentopname blijft bestaan, maar de bestemming ervan wordt overschreven met een kopie die zowel kan worden gelezen als geschreven.

Versies kopiëren

U kunt een kopieerbewerking uitvoeren om een versie-blob boven de basis-blob te promoveren. Op deze manier kunt u een eerdere versie van een blob herstellen. De versie blijft bestaan, maar de bestemming wordt overschreven met een kopie die zowel kan worden gelezen als geschreven.

Gearchiveerde blob kopiëren (versie 2018-11-09 en hoger)

Een gearchiveerde blob kan worden gekopieerd naar een nieuwe blob binnen hetzelfde opslagaccount. Hierdoor blijft de aanvankelijk gearchiveerde blob zoals deze is. Wanneer u een gearchiveerde blob als bron kopieert, moet de aanvraag de header bevatten die de laag van de x-ms-access-tier doel-blob aangeeft. De gegevens worden uiteindelijk gekopieerd naar de doelblob.

De kopieerbron en het doel moeten hetzelfde opslagaccount zijn wanneer de bron wordt gearchiveerd. De aanvraag mislukt met Conflict als de bron van de kopie nog steeds de status Rehydrateren in behandeling heeft.

Zie Opslaglagen voor Hot, Cool en Archive voor gedetailleerde informatie over opslaglagen op blok-blobniveau.

Werken met een kopie in behandeling (versie 2012-02-12 en hoger)

Als de bewerking de kopie asynchroon voltooit, gebruikt u de volgende tabel om de volgende stap te bepalen op basis van de Copy Blob statuscode die wordt geretourneerd door Copy Blob :

Statuscode	Betekenis
202 (geaccepteerd), x-ms-copy-status: geslaagd	Kopiëren is voltooid.
202 (Geaccepteerd), x-ms-copy-status: in behandeling	Het kopiëren is niet voltooid. Poll de doel-blob met `Get Blob Properties` om de x-ms-copy-status te controleren totdat het kopiëren is voltooid of mislukt.
4xx, 500 of 503	Kopiëren is mislukt.

Tijdens en na een Copy Blob bewerking bevatten de eigenschappen van de doel-blob de kopieer-id van de bewerking en URL van de Copy Blob bron-blob. Wanneer de kopie is voltooid, Blob service de waarde voor tijd en resultaat ( , of ) naar de success failed aborted doelblobeigenschappen. Als de bewerking failed , bevat de header een x-ms-copy-status-description tekenreeks met foutdetails.

Een bewerking Copy Blob die in behandeling is, heeft een time-out van twee weken. Een kopieerpoging die na 2 weken niet is voltooid, heeft een times-out en laat een lege blob achter met het veld ingesteld op en de x-ms-copy-status failed op x-ms-copy-status-description 500 (OperationCancelled). Onregelmatige, niet-fatale fouten die zich tijdens een kopie kunnen voordoen, kunnen de voortgang van de kopie belemmeren, maar niet leiden tot een fout. In deze gevallen x-ms-copy-status-description beschrijft de onregelmatige fouten.

Elke poging om de doelblob te wijzigen of een momentopname te maken tijdens het kopiëren mislukt met 409 (Conflict) Blob kopiëren wordt uitgevoerd.

Als u de bewerking aanroept, ziet u een header en bevat de doel-blob intacte metagegevens en een Abort Copy Blob x-ms-copy-status:aborted bloblengte van nul bytes. U kunt de oorspronkelijke aanroep herhalen om Copy Blob het kopiëren opnieuw uit te proberen.

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	Kopiëren is voltooid.
4xx, 500 of 503	Kopiëren is mislukt.

Laag wordt overgenomen voor Premium Storage-lagen. Voor blok-blobs neemt het overschrijven van de doel-blob de hot/cool-laag over van de bestemming als x-ms-access-tier niet is opgegeven. Het overschrijven van een gearchiveerde blob mislukt. Zie Opslaglagen voor Hot, Cool en Archive voor gedetailleerde informatie over opslaglagen op blok-blobniveau.

Facturering

Het doelaccount van een bewerking wordt in rekening gebracht voor één transactie om de kopie te initiëren, en er wordt ook één transactie in rekening gebracht voor elke aanvraag om de status van de kopieerbewerking af te breken of aan Copy Blob te vragen.

Wanneer de bron-blob zich in een ander account, worden voor het bronaccount transactiekosten in rekening brengen. Als de bron- en doelaccounts zich bovendien in verschillende regio's bevinden (bijvoorbeeld VS - noord en VS - zuid), wordt de bandbreedte die wordt gebruikt voor het overdragen van de aanvraag in rekening gebracht bij het bronopslagaccount als een egress. Egress 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 opslagbronnen voor de nieuwe blob, zodat de kopieerbewerking resulteert in kosten voor het capaciteitsgebruik van het opslagaccount voor die extra resources. Als de naam van de bron- en doelblob echter hetzelfde is binnen hetzelfde account (bijvoorbeeld wanneer u een momentopname naar de basisblob promovert), worden er alleen extra kosten in rekening gebracht voor de extra kopiemetagegevens die zijn opgeslagen in versie 2012-02-12 en hoger.

Wanneer u een momentopname promovert ter vervanging van de basis-blob, worden de momentopname en basis-blob identiek. Ze delen blokken of pagina's, zodat de kopieerbewerking niet leidt tot extra kosten voor het capaciteitsgebruik van het opslagaccount. Als u echter een momentopname kopieert naar een doel-blob met een andere naam, worden er extra kosten in rekening gebracht voor de opslagbronnen die worden gebruikt door de nieuwe blob die het resultaat is. Twee blobs met verschillende namen kunnen geen blokken of pagina's delen, zelfs niet als ze identiek zijn. Zie Understanding How Snapshots Accrue Charges (Hoe momentopnamen kosten genereren) voor meer informatie over scenario's met momentopnamekosten.

Zie ook

Aanvragen voor Azure Storage
Status- en foutcodes
Blob Service-foutcodes
Inzicht in hoe momentopnamen kosten genereren
Kopie-blob afbreken