Blob kopiëren

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

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

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

Opmerking

Alleen opslagaccounts die op of na 7 juni 2012 zijn gemaakt, staan de bewerking toe om te Copy Blob kopiëren van 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-handtekening (Shared Access) 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 handtekening voor gedeelde toegang opgeven voor de doel-blob als deze zich in een ander opslagaccount bevindt.

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

URI voor de geëmuleerde opslagservice

Wanneer u een aanvraag indient voor de geëmuleerde opslagservice, geeft u de hostnaam van de emulator en de Azure Blob Storage-poort op als 127.0.0.1:10000, gevolgd door de naam van het geëmuleerde opslagaccount:

PUT methode URI aanvragen	HTTP-versie
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob`	HTTP/1.1

Zie De Azurite-emulator gebruiken voor lokale Azure Storage-ontwikkelingvoor meer informatie.

URI Parameters

U kunt de volgende aanvullende parameters opgeven voor de aanvraag-URI:

Kenmerk	Beschrijving
`timeout`	Facultatief. De parameter `timeout` wordt uitgedrukt in seconden. Zie Time-outs instellen voor Blob Storage-bewerkingen voor meer informatie.

Headers aanvragen

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

Header van het verzoek	Beschrijving
`Authorization`	Verplicht. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening op. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie.
`Date` of `x-ms-date`	Verplicht. Hiermee geeft u de Coordinated Universal Time (UTC) voor de aanvraag. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie.
`x-ms-version`	Vereist voor alle geautoriseerde aanvragen. Zie Versiebeheer voor de Azure Storage-servicesvoor meer informatie.
`x-ms-meta-name:value`	Facultatief. Hiermee geeft u een door de gebruiker gedefinieerd naam/waarde-paar op dat is gekoppeld aan de blob. Als er geen naam/waarde-paren zijn opgegeven, kopieert de bewerking de metagegevens van de bron-blob of het bestand naar de doel-blob. Als een of meer naam/waarde-paren 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 metagegevensnamen voldoen aan de naamgevingsregels voor C#-id's. Zie Containers, blobs en metagegevens een naam geven en ernaar verwijzen voor meer informatie.
`x-ms-tags`	Facultatief. Hiermee stelt u de opgegeven query-string-gecodeerde tags in op de blob. Tags worden niet gekopieerd van de kopiebron. Zie Opmerkingen voor meer informatie. Ondersteund in versie 2019-12-12 en hoger.
`x-ms-source-if-modified-since`	Facultatief. 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 koptekst niet opgeven als de bron een Azure-bestand is.
`x-ms-source-if-unmodified-since`	Facultatief. 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 koptekst niet opgeven als de bron een Azure-bestand is.
`x-ms-source-if-match`	Facultatief. Een `ETag` waarde. Geef deze voorwaardelijke kop op om de bron-blob alleen te kopiëren als de `ETag` waarde overeenkomt met de opgegeven waarde. Als de waarden niet overeenkomen, retourneert Blob Storage statuscode 412 (Voorvoorwaarde mislukt). U kunt deze koptekst niet opgeven als de bron een Azure-bestand is.
`x-ms-source-if-none-match`	Facultatief. Een `ETag` waarde. Geef deze voorwaardelijke koptekst 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 koptekst niet opgeven als de bron een Azure-bestand is.
`If-Modified-Since`	Facultatief. 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 (Voorvoorwaarde mislukt).
`If-Unmodified-Since`	Facultatief. 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`	Facultatief. Een `ETag` waarde. Geef een `ETag` waarde op voor deze voorwaardelijke koptekst 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 (Voorvoorwaarde mislukt).
`If-None-Match`	Facultatief. Een `ETag` waarde, of het jokerteken (). Geef een `ETag` waarde op voor deze voorwaardelijke koptekst 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`	Verplicht. Hiermee geeft u de naam van de bron-blob of het bronbestand op. Vanaf versie 2012-02-12 kan deze waarde een URL zijn van maximaal 2 kibibytes (KiB) lang die een blob aangeeft. De waarde moet URL-gecodeerd zijn zoals deze zou worden 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 is in een ander opslagaccount, moet de bron-blob openbaar zijn of moet de toegang ertoe worden geautoriseerd via een gedeelde toegangshandtekening. 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 zijn in Azure Files. Als het bronobject een bestand is dat naar een blob wordt gekopieerd, moet het bronbestand worden geautoriseerd via een gedeelde toegangshandtekening, ongeacht of het zich in hetzelfde account of in een ander account bevindt. Alleen opslagaccounts die op of na 7 juni 2012 zijn gemaakt, staan de bewerking toe om te `Copy Blob` kopiëren van een ander opslagaccount. Hier volgen enkele voorbeelden van URL's voor 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 is in Azure Files, wordt de bron-URL gebruikt 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 binnen hetzelfde account worden gekopieerd 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 root container: `/accountName/blobName` - Snapshot in root container: `/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 de id 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 met statuscode 412 (Precondition Failed). In versie 2012-02-12 en hoger moet deze waarde een actieve oneindige lease voor een gehuurde blob opgeven. Een lease-ID met een eindige looptijd mislukt met statuscode 412 (Voorvoorwaarde mislukt).
`x-ms-source-lease-id: <ID>`	Optioneel voor versies vóór 2012-02-12 (niet ondersteund in 2012-02-12 en later). Geef deze koptekst 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 (Voorvoorwaarde mislukt).
`x-ms-client-request-id`	Facultatief. Biedt een door de client gegenereerde, ondoorzichtige waarde met een limiet van 1 KiB-tekens 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`	Facultatief. Hiermee geeft u de laag op die moet worden ingesteld op de doel-blob. Deze koptekst is alleen bedoeld voor pagina-blobs op een Premium-account met versie 2017-04-17 en hoger. Zie High-performance premium storage 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 blokblobs. Blokbloblagen worden ondersteund op Blob Storage- of General Purpose v2-accounts. Geldige waarden zijn `Hot`, `Cool`, `Cold` en `Archive`. Opmerking:`Cold` laag wordt ondersteund voor versie 2021-12-02 en hoger. Zie Hot, Cool en archiefopslaglagen voor gedetailleerde informatie over blokbloblagen.
`x-ms-rehydrate-priority`	Facultatief. Geeft de prioriteit aan waarmee een gearchiveerde blob moet worden gerehydrateerd. Deze header wordt ondersteund op versie 2019-02-02 en hoger voor blokblobs. Geldige waarden zijn `High` en `Standard`. U kunt de prioriteit voor een blob slechts één keer instellen. Deze header wordt genegeerd bij volgende aanvragen naar dezelfde blob. De standaardprioriteit zonder deze kop is `Standard`.
`x-ms-seal-blob`	Facultatief. Ondersteund op versie 2019-12-12 of hoger. Deze koptekst is alleen geldig voor het toevoegen van blobs. De doel-blob wordt verzegeld nadat de kopieerbewerking is voltooid.
`x-ms-immutability-policy-until-date`	Versie 2020-06-12 en later. Hiermee geeft u de retentie-tot-datum op die op de blob moet worden ingesteld. Dit is de datum tot wanneer de blob kan worden beveiligd tegen wijziging of verwijdering. Het volgt RFC1123 formaat.
`x-ms-immutability-policy-mode`	Versie 2020-06-12 en later. Hiermee geeft u de beleidsmodus voor onveranderlijkheid op die op de blob moet worden ingesteld. 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 later. Hiermee geeft u de wettelijke bewaring op die op de blob moet worden ingesteld. Geldige waarden zijn `true` en `false`.

Deze bewerking ondersteunt de x-ms-if-tags voorwaardelijke x-ms-source-if-tags headers om alleen te slagen als aan de opgegeven voorwaarde wordt voldaan. Zie Voorwaardelijke headers opgeven voor Blob Storage-bewerkingenvoor meer informatie.

Inhoud van het verzoek

Geen.

Reactie

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 12-02-2012 retourneert een geslaagde bewerking statuscode 201 (gemaakt).

Zie Status en foutcodesvoor meer informatie over statuscodes.

Antwoordkopteksten

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`	In versie 2012-02-12 en hoger, als de kopie compleet is, bevat deze koptekst de `ETag` waarde van de doel-blob. Als de kopie niet volledig is, bevat de koptekst de `ETag` waarde van de lege blob die aan het begin van de kopieerbewerking is gemaakt. 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`	Identificeer de aanvraag die is gedaan, uniek. U kunt deze header gebruiken om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossenvoor 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 later. 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 `Abort Copy Blob` door om een in behandeling zijnde kopieerbewerking te annuleren.
`x-ms-copy-status: <success ¦ pending>`	Versie 2012-02-12 en later. Geeft de status van de kopieerbewerking aan, met de volgende waarden: - `success`: De bewerking is met succes voltooid. - `pending`: De bewerking is aan de gang.
`x-ms-version-id: <DateTime>`	Versie 2019-12-12 en later. Identificeert de blob op unieke wijze aan de hand van de versie. U kunt deze ondoorzichtige waarde gebruiken in volgende aanvragen om toegang te krijgen 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 bevat. Als de `x-ms-client-request-id` header niet aanwezig is in de aanvraag, is deze header niet aanwezig in het antwoord.

Antwoordlichaam

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:

Objectsoort	Microsoft Entra ID-autorisatie	Autorisatie voor Shared Access Signature (SAS)	Autorisatie voor gedeelde sleutels (of Shared Key Lite)
Bestemmings-blob	Ja	Ja	Ja
Bron-blob in hetzelfde opslagaccount	Ja	Ja	Ja
Bron-blob in een ander opslagaccount	Nee.	Ja	Nee.

Als in een aanvraag tags worden opgegeven in de x-ms-tags aanvraagkop, 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 SAS-token met de machtiging Lezen (r). Zie de details van de aanvraagheader x-ms-copy-sourcevoor meer informatie over de autorisatie van bron-blob.

Belangrijk

Microsoft raadt aan om 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.

Microsoft Entra-id (aanbevolen)
Sas- (Shared Access Signatures)
gedeelde sleutel

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 beveiligingsprincipaal. De beveiligingsprincipaal kan een door een gebruiker, groep, toepassingsservice-principal of door Azure beheerde identiteit zijn. De beveiligingsprincipaal wordt geverifieerd door Microsoft Entra ID om een OAuth 2.0-token terug te geven. Het token kan vervolgens worden gebruikt om een aanvraag te autoriseren voor de Blob-service.

Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra IDvoor 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 minst bevoorrechte ingebouwde Azure RBAC-rol die deze actie omvat:

Bestemmings-blob

Azure RBAC-actie:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (voor het 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 minste bevoegdheden:Storage Blob Data Reader

Zie Een Azure-rol toewijzen voor toegang tot blobgegevensvoor 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, tot welke machtigingen deze resources beschikken en hoe lang de SAS geldig is.

De bewerking ondersteunt drie typen handtekeningen voor gedeelde toegang: SAS-voor gebruikersdelegering, SAS-van service en SAS--account-.

Het is raadzaam om microsoft Entra-referenties te gebruiken in plaats van de sleutel van het opslagaccount, wat gemakkelijker kan worden aangetast. Als voor uw toepassingsontwerp handtekeningen voor gedeelde toegang zijn vereist, gebruikt u Microsoft Entra-referenties om, indien mogelijk, een SAS voor gebruikersdelegatie te maken.

Wanneer toegang tot gedeelde sleutels niet is toegestaan voor het opslagaccount, is een SAS-token van de service of een SAS-accounttoken niet toegestaan bij een aanvraag naar Blob Storage. Zie Begrijpen hoe de toewijzing van gedeelde sleutels van invloed is op SAS-tokensvoor meer informatie.

Gebruikersdelegatie SAS

Een SAS voor gebruikersdelegering wordt beveiligd door middel van Microsoft Entra-referenties en door 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 blobresource, is de volgende machtiging vereist als onderdeel van het SAS-token voor gebruikersoverdracht.

Operatie	Objectsoort	Ondertekende machtiging
Blob kopiëren	Doel-blob (nieuw)	Maken (c) of schrijven (w)
Blob kopiëren	Doel-blob (bestaand)	Schrijven (w)
Blob kopiëren	Bron-blob (binnen hetzelfde opslagaccount)	Lees (r)
Blob kopiëren	Bron-blob (in een ander opslagaccount)	Lees (r)

Zie Sas voor gebruikersdelegering makenvoor meer informatie over de SAS voor gebruikersdelegering.

Service-SAS

Een service-SAS wordt beveiligd met de sleutel van het opslagaccount. Een service-SAS delegeert de 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 blobresource, is de volgende machtiging vereist als onderdeel van het SAS-token van de service.

Operatie	Objectsoort	Ondertekende machtiging
Blob kopiëren	Doel-blob (nieuw)	Maken (c) of schrijven (w)
Blob kopiëren	Doel-blob (bestaand)	Schrijven (w)
Blob kopiëren	Bron-blob (binnen hetzelfde opslagaccount)	Lees (r)
Blob kopiëren	Bron-blob (in een ander opslagaccount)	Lees (r)

Zie Een service-SAS-maken 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 gebruikersdelegering-SAS, zijn ook beschikbaar via een account-SAS.

De volgende tabel geeft het ondertekende resourcetype en de ondertekende machtigingen aan die moeten worden opgegeven bij het delegeren van toegang:

Operatie	Objectsoort	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Blob kopiëren	Doel-blob (nieuw)	Klodder (b)	Voorwerp (o)	Maken (c) of schrijven (w)
Blob kopiëren	Doel-blob (bestaand)	Klodder (b)	Voorwerp (o)	Schrijven (w)
Blob kopiëren	Bron-blob (binnen hetzelfde opslagaccount)	Klodder (b)	Voorwerp (o)	Lees (r)
Blob kopiëren	Bron-blob (in een ander opslagaccount)	Klodder (b)	Voorwerp (o)	Lees (r)

Zie Een SAS-account makenvoor 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 binnen een opgegeven tijdsbestek wordt voltooid.

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 zijn in Azure Files. Als de bron een bestand is, moet de bestemming een blok-blob zijn.

Meerdere bewerkingen in behandeling Copy Blob binnen een account kunnen opeenvolgend worden verwerkt. Een doel-blob kan slechts één uitstekende Copy Blob bewerking hebben. Met andere woorden, een blob kan niet de bestemming zijn voor meerdere bewerkingen die in behandeling Copy Blob zijn. 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 op of na 7 juni 2012 zijn gemaakt, staan de bewerking toe om te Copy Blob kopiëren van 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 (Ongeldig verzoek).

De Copy Blob bewerking kopieert altijd de hele bron-blob of het hele bestand. 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 aannemen:

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, toevoeging 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-vastgelegde blokken verwijderd en worden de metadata 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 het kan een nieuwe blok-blob zijn die door de kopieerbewerking wordt gemaakt. Het kopiëren van bestanden naar pagina-blobs of het toevoegen van blobs wordt niet ondersteund.
U kunt een momentopname kopiëren over 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 beschrijfbare blob en geen momentopname.

Wanneer u kopieert uit 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-blob of een toevoeg-blob maakt Blob Storage een vastgelegde blob met een lengte van nul voordat deze bewerking wordt uitgevoerd.

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

Wanneer u kopieert uit 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 op de doel-blob aanroepen Get BlobGet Blob Properties om de status van de kopieerbewerking te controleren. De laatste blob wordt vastgelegd wanneer de kopieerbewerking is voltooid.

Wanneer de bron van een kopieerbewerking waarden bevat ETag , zal die bewerking mislukken door wijzigingen in de bron terwijl de kopieerbewerking wordt uitgevoerd. 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. Huurovereenkomsten van bepaalde duur zijn niet toegestaan.

De ETag waarde voor een blok-blob verandert wanneer de Copy Blob bewerking wordt gestart en wanneer de bewerking wordt voltooid. De ETag waarde voor een pagina-blob verandert wanneer de Copy Blob bewerking wordt gestart en 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.

Blobeigenschappen, -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 blobs toevoegen en alleen voor versie 2015-02-21)

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

De doel-blob is altijd even groot als de bron-blob. De waarde van de Content-Length koptekst voor de doel-blob komt overeen met de waarde van die koptekst voor de bron-blob.

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

Als de x-ms-tags koptekst tags bevat voor de doel-blob, moeten deze zijn gecodeerd met een querytekenreeks. Tagsleutels en -waarden moeten voldoen aan de naamgevings- en lengtevereisten, zoals gespecificeerd in Blob-codes instellen.

De x-ms-tags header kan maximaal 2 kilobits aan tags bevatten. Als u meer tags nodig heeft, gebruikt u de Set Blob Tags operatie.

Als de x-ms-tags koptekst geen tags bevat, worden tags niet gekopieerd van de bron-blob.

Een gehuurde blob kopiëren

De Copy Blob bewerking leest alleen uit de bron-blob, dus de leasestatus van de bron-blob doet er niet toe. De Copy Blob bewerking slaat echter 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 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 een statuscode 412 (Voorvoorwaarde mislukt). Terwijl de kopieerbewerking in behandeling is, mislukt elke leasebewerking op de doel-blob met statuscode 409 (conflict). Een oneindige lease voor 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, kopieert naar een doel-blob met dezelfde naam als de bron, of een momentopname promoot over de basis-blob.

Als de client een lease-id opgeeft voor een blob die nog niet bestaat, retourneert Blob Storage statuscode 412 (Voorvoorwaarde mislukt) voor aanvragen die zijn ingediend op basis van 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 naar het doel gekopieerd. Wanneer een doel-blob wordt overschreven met een kopie, blijven alle momentopnamen of versies die aan de doel-blob zijn gekoppeld, intact onder de naam.

U kunt een kopieerbewerking uitvoeren om een momentopname te promoveren via de basisblob, zolang deze zich in een onlinelaag bevindt (hot of cool). Op deze manier kunt u een eerdere versie van een blob herstellen. De momentopname blijft staan, maar de bestemming wordt overschreven door een kopie die zowel gelezen als geschreven kan worden.

Blob-versies kopiëren

U kunt een kopieerbewerking uitvoeren om een versie te promoveren via de basisblob, zolang deze zich in een onlinelaag bevindt (hot of cool). Op deze manier kunt u een eerdere versie van een blob herstellen. De versie blijft staan, maar de bestemming wordt overschreven door een kopie die zowel gelezen als geschreven kan worden.

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, zolang het doelaccount zich in dezelfde regio bevindt als het bronaccount.

Het verzoek kan mislukken als de bron-blob opnieuw wordt gehydrateerd.

Zie Warme, koele en archiefopslaglagen voor gedetailleerde informatie over lagen op blokblobniveau.

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 door `Get Blob Properties` de `x-ms-copy-status` koptekst 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 de resultaatwaarde (success, failed, of 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 in behandeling zijnde Copy Blob bewerking heeft een time-out van twee weken. Bij een kopieerpoging die na twee weken nog niet is voltooid, treedt een time-out op en er blijft een lege blob achter met het x-ms-copy-status veld ingesteld op failed en de x-ms-copy-status-description set ingesteld op 500 (OperationCancelled). Onregelmatige, niet-fatale fouten die kunnen optreden tijdens een kopieerbewerking, kunnen de voortgang van de bewerking belemmeren, maar niet tot een storing leiden. In deze gevallen beschrijft x-ms-copy-status-description de onregelmatige fouten.

Elke poging om de doel-blob tijdens de kopieerbewerking te wijzigen of een momentopname te maken, mislukt met statuscode 409 (conflict), 'Kopieer-blob in uitvoering'.

Als u de Abort Copy Blob bewerking aanroept, ziet u een x-ms-copy-status:aborted koptekst. De doel-blob heeft intacte metagegevens en een bloblengte van 0 bytes. U kunt de oorspronkelijke aanroep herhalen om Copy Blob 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 opslaglagen. Voor blok-blobs wordt bij het overschrijven van de doel-blob de warme of koele laag van het doel overgenomen als x-ms-access-tier deze niet is opgegeven. Het overschrijven van een gearchiveerde blob mislukt. Zie Warme, koele en archiefopslaglagen voor gedetailleerde informatie over lagen op blokblobniveau.

Facturatie

Prijsaanvragen kunnen afkomstig zijn van clients die Blob Storage-API's gebruiken, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Deze aanvragen maken kosten per transactie. Het type transactie is van invloed op de manier waarop het account in rekening wordt gebracht. Leestransacties worden bijvoorbeeld opgebouwd tot een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Copy Blob aanvragen op basis van het type opslagaccount:

Operatie	Type opslagaccount	Factureringscategorie
Blob kopiëren (doelaccount¹)	Premium blok-blob Standaard algemeen gebruik v2 Standaard algemeen gebruik v1	Schrijfbewerkingen
Kopieer Blob (bronaccount²)	Premium blok-blob Standaard algemeen gebruik v2 Standaard algemeen gebruik v1	Leesbewerkingen

¹Het bestemmingsaccount wordt in rekening gebracht voor één transactie om het schrijven te starten.
^{Arabisch cijfer}Wanneer het bronobject zich in een ander account bevindt, voert het bronaccount één transactie uit voor elke leesaanvraag naar het bronobject.

Zie Prijzen voor Azure Blob Storage voor meer informatie over de prijzen voor de opgegeven factureringscategorieën.

Het bestemmingsaccount brengt ook transactiekosten met zich mee voor elke aanvraag om de kopieerbewerking te annuleren (zie Blob kopiëren) of om de status van de kopieerbewerking te controleren (zie Eigenschappen van Blob ophalen of Blob 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, bovendien in rekening gebracht voor 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 opslagbronnen voor de nieuwe blob. De kopieerbewerking resulteert vervolgens in kosten voor het capaciteitsgebruik van het opslagaccount voor die 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 promoot 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, brengt die bewerking extra kosten met zich mee voor de opslagbronnen 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 Inzicht in hoe kosten voor momentopnamen in rekening worden gebracht voor meer informatie over kostenscenario's voor momentopnamen.

Zie ook

aanvragen autoriseren voor Azure Storage
status en foutcodes
Blob Storage-foutcodes
Inzicht in hoe kosten voor momentopnamen worden gegenereerd
Blob kopiëren afbreken

Last updated on 2025-06-12

Delen via