Kopiera blob
Åtgärden Copy Blob kopierar en blob till ett mål i lagringskontot.
I version 2012-02-12 och senare kan källan för en Copy Blob åtgärd vara en checkad blob i valfritt Azure-lagringskonto.
Från och med version 2015-02-21 kan källan för en Copy Blob åtgärd vara en Azure-fil i valfritt Azure-lagringskonto.
Anteckning
Endast lagringskonton som skapats den 7 juni 2012 eller senare tillåter Copy Blob att åtgärden kopieras från ett annat lagringskonto.
Förfrågan
Du kan skapa begäran på Copy Blob följande sätt. Vi rekommenderar HTTPS. Ersätt myaccount med namnet på ditt lagringskonto, mycontainer med namnet på din container och myblob med namnet på din målblob.
Från och med version 2013-08-15 kan du ange en signatur för delad åtkomst (SAS) för målbloben om den finns i samma konto som källbloben. Från och med version 2015-04-05 kan du också ange en signatur för delad åtkomst för målbloben om den finns i ett annat lagringskonto.
| URI för PUT-metodbegäran | HTTP-version |
|---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob |
HTTP/1.1 |
URI för den emulerade lagringstjänsten
När du gör en begäran mot den emulerade lagringstjänsten anger du emulatorns värdnamn och Azure Blob Storage port som 127.0.0.1:10000, följt av namnet på det emulerade lagringskontot:
| URI för PUT-metodbegäran | HTTP-version |
|---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob |
HTTP/1.1 |
Mer information finns i Använda Azurite-emulatorn för lokal Azure Storage-utveckling.
URI-parametrar
Du kan ange följande ytterligare parametrar på begärande-URI:n:
| Parameter | Beskrivning |
|---|---|
timeout |
Valfritt. Parametern timeout uttrycks i sekunder. Mer information finns i Ange tidsgränser för Blob Storage-åtgärder. |
Begärandehuvuden
I följande tabell beskrivs obligatoriska och valfria begärandehuvuden:
| Begärandehuvud | Beskrivning |
|---|---|
Authorization |
Krävs. Anger auktoriseringsschema, kontonamn och signatur. Mer information finns i Auktorisera begäranden till Azure Storage. |
Date eller x-ms-date |
Krävs. Anger Coordinated Universal Time (UTC) för begäran. Mer information finns i Auktorisera begäranden till Azure Storage. |
x-ms-version |
Krävs för alla auktoriserade begäranden. Mer information finns i Versionshantering för Azure Storage-tjänsterna. |
x-ms-meta-name:value |
Valfritt. Anger ett användardefinierat namn/värde-par som är associerat med bloben. Om inga namn/värde-par anges kopierar åtgärden metadata från källbloben eller -filen till målbloben. Om ett eller flera namn/värde-par anges skapas målbloben med angivna metadata och metadata kopieras inte från källbloben eller -filen. Från och med version 2009-09-19 måste metadatanamn följa namngivningsreglerna för C#-identifierare. Mer information finns i Namnge och referera till containrar, blobar och metadata. |
x-ms-tags |
Valfritt. Anger de angivna query-string-kodade taggarna på bloben. Taggar kopieras inte från kopieringskällan. Mer information finns i Kommentarer. Stöds i version 2019-12-12 och senare. |
x-ms-source-if-modified-since |
Valfritt. Ett DateTime värde. Ange den här villkorliga rubriken för att kopiera bloben endast om källbloben har ändrats sedan det angivna datumet/tiden. Om källbloben inte har ändrats returnerar Blob Storage statuskod 412 (förhandsvillkoret misslyckades). Du kan inte ange det här huvudet om källan är en Azure-fil. |
x-ms-source-if-unmodified-since |
Valfritt. Ett DateTime värde. Ange den här villkorliga rubriken för att kopiera bloben endast om källbloben inte har ändrats sedan det angivna datumet/tiden. Om källbloben har ändrats returnerar Blob Storage statuskod 412 (förhandsvillkoret misslyckades). Du kan inte ange det här huvudet om källan är en Azure-fil. |
x-ms-source-if-match |
Valfritt. Ett ETag värde. Ange den här villkorliga rubriken för att kopiera källbloben endast om dess ETag värde matchar det angivna värdet. Om värdena inte matchar returnerar Blob Storage statuskoden 412 (förhandsvillkoret misslyckades). Du kan inte ange det här huvudet om källan är en Azure-fil. |
x-ms-source-if-none-match |
Valfritt. Ett ETag värde. Ange den här villkorliga rubriken för att kopiera bloben endast om dess ETag värde inte matchar det angivna värdet. Om värdena är identiska returnerar Blob Storage statuskod 412 (förhandsvillkoret misslyckades). Du kan inte ange det här huvudet om källan är en Azure-fil. |
If-Modified-Since |
Valfritt. Ett DateTime värde. Ange den här villkorliga rubriken för att kopiera bloben endast om målbloben har ändrats sedan det angivna datumet/tiden. Om målbloben inte har ändrats returnerar Blob Storage statuskoden 412 (förhandsvillkoret misslyckades). |
If-Unmodified-Since |
Valfritt. Ett DateTime värde. Ange den här villkorliga rubriken för att kopiera bloben endast om målbloben inte har ändrats sedan det angivna datumet/tiden. Om målbloben har ändrats returnerar Blob Storage statuskod 412 (förhandsvillkoret misslyckades). |
If-Match |
Valfritt. Ett ETag värde. Ange ett ETag värde för den här villkorliga rubriken för att kopiera bloben endast om det angivna ETag värdet matchar ETag värdet för en befintlig målblob. Om värdena inte matchar returnerar Blob Storage statuskoden 412 (förhandsvillkoret misslyckades). |
If-None-Match |
Valfritt. Ett ETag värde eller jokertecknet (*).Ange ett ETag värde för den här villkorliga rubriken för att kopiera bloben endast om det angivna ETag värdet inte matchar ETag värdet för målbloben.Ange jokertecknet (*) för att utföra åtgärden endast om målbloben inte finns. Om det angivna villkoret inte uppfylls returnerar Blob Storage statuskod 412 (förhandsvillkoret misslyckades). |
x-ms-copy-source:name |
Krävs. Anger namnet på källbloben eller -filen. Från och med version 2012-02-12 kan det här värdet vara en URL på upp till 2 kibibyte (KiB) som anger en blob. Värdet ska vara URL-kodat som det skulle visas i en begärande-URI. Läsåtgärden på en källblob i samma lagringskonto kan auktoriseras via en delad nyckel. Från och med version 2017-11-09 kan du också använda Microsoft Entra ID för att auktorisera läsåtgärden på källbloben. Men om källan är en blob i ett annat lagringskonto måste källbloben vara offentlig, eller så måste åtkomst till den auktoriseras via en signatur för delad åtkomst. Om källbloben är offentlig krävs ingen auktorisering för att utföra kopieringsåtgärden. Från och med version 2015-02-21 kan källobjektet vara en fil i Azure Files. Om källobjektet är en fil som ska kopieras till en blob måste källfilen auktoriseras via en signatur för delad åtkomst, oavsett om den finns i samma konto eller i ett annat konto. Endast lagringskonton som skapats den 7 juni 2012 eller senare tillåter Copy Blob att åtgärden kopieras från ett annat lagringskonto.Här följer några exempel på URL:er för källobjekt: - 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>När källobjektet är en fil i Azure Files använder käll-URL:en följande format. Observera att URL:en måste innehålla en giltig SAS-token för filen. - https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastokenI versioner före 2012-02-12 kan blobar endast kopieras inom samma konto och ett källnamn kan använda följande format: – Blob i namngiven container: /accountName/containerName/blobName– Ögonblicksbild i namngiven container: /accountName/containerName/blobName?snapshot=<DateTime>– Blob i rotcontainern: /accountName/blobName– Ögonblicksbild i rotcontainern: /accountName/blobName?snapshot=<DateTime> |
x-ms-lease-id:<ID> |
Krävs om målbloben har ett aktivt lån. Låne-ID:t som angetts för den här rubriken måste matcha låne-ID:t för målbloben. Om begäran inte innehåller låne-ID:t eller om ID:t inte är giltigt misslyckas åtgärden med statuskoden 412 (Förhandsvillkoret misslyckades). Om det här huvudet har angetts och målbloben för närvarande inte har något aktivt lån misslyckas åtgärden med statuskoden 412 (förhandsvillkoret misslyckades). I version 2012-02-12 och senare måste det här värdet ange ett aktivt oändligt lån för en hyrd blob. Ett låne-ID med begränsad varaktighet misslyckas med statuskod 412 (förhandsvillkoret misslyckades). |
x-ms-source-lease-id: <ID> |
Valfritt för versioner före 2012-02-12 (stöds inte 2012-02-12 och senare). Ange det här huvudet för att utföra Copy Blob åtgärden endast om det angivna låne-ID:t matchar källblobens aktiva låne-ID.Om det här huvudet anges och källbloben för närvarande inte har något aktivt lån misslyckas åtgärden med statuskoden 412 (förhandsvillkoret misslyckades). |
x-ms-client-request-id |
Valfritt. Tillhandahåller ett klientgenererat, täckande värde med en gräns på 1 KiB-tecken som registreras i loggarna när loggningen har konfigurerats. Vi rekommenderar starkt att du använder det här huvudet för att korrelera aktiviteter på klientsidan med begäranden som servern tar emot. |
x-ms-access-tier |
Valfritt. Anger den nivå som ska anges för målbloben. Den här rubriken är endast avsedd för sidblobar på ett Premium-konto med version 2017-04-17 och senare. En fullständig lista över nivåer som stöds finns i Premium-lagring med höga prestanda och hanterade diskar för virtuella datorer. Det här huvudet stöds i version 2018-11-09 och senare för blockblobar. Blockblobnivåindelning stöds på Blob Storage- eller Generell användning v2-konton. Giltiga värden är Hot, CoolCold och Archive.
Observera:Cold -nivån stöds för version 2021-12-02 och senare. Detaljerad information om blockblobnivåer finns i Lagringsnivåer för frekvent, lågfrekvent lagring och arkivlagring. |
x-ms-rehydrate-priority |
Valfritt. Anger med vilken prioritet en arkiverad blob ska extraheras. Det här huvudet stöds i version 2019-02-02 och senare för blockblobar. Giltiga värden är High och Standard. Du kan bara ange prioriteten för en blob en gång. Det här huvudet ignoreras vid efterföljande begäranden till samma blob. Standardprioritet utan det här huvudet är Standard. |
x-ms-seal-blob |
Valfritt. Stöds i version 2019-12-12 eller senare. Det här huvudet är endast giltigt för tilläggsblobar. Den förseglar målbloben när kopieringsåtgärden är klar. |
x-ms-immutability-policy-until-date |
Version 2020-06-12 och senare. Anger det kvarhållningsdatum som ska anges för bloben. Det här är det datum fram till vilket bloben kan skyddas från ändringar eller borttagning. Det följer RFC1123 format. |
x-ms-immutability-policy-mode |
Version 2020-06-12 och senare. Anger det oföränderlighetsprincipläge som ska anges för bloben. Giltiga värden är unlocked och locked. Ett unlocked värde anger att användaren kan ändra principen genom att öka eller minska kvarhållningsdatumet tills dess. Ett locked värde anger att dessa åtgärder är förbjudna. |
x-ms-legal-hold |
Version 2020-06-12 och senare. Anger det bevarande av juridiska skäl som ska anges för bloben. Giltiga värden är true och false. |
Den här åtgärden stöder x-ms-if-tagsx-ms-source-if-tags och villkorsstyrda huvuden för att lyckas endast om det angivna villkoret är uppfyllt. Mer information finns i Ange villkorsstyrda rubriker för Blob Storage-åtgärder.
Begärandetext
Inga.
Svarsåtgärder
Svaret innehåller en HTTP-statuskod och en uppsättning svarshuvuden.
Statuskod
I version 2012-02-12 och senare returnerar en lyckad åtgärd statuskod 202 (godkänd).
I versioner före 2012-02-12 returnerar en lyckad åtgärd statuskod 201 (skapad).
Information om statuskoder finns i Status och felkoder.
Svarshuvuden
Svaret för den här åtgärden innehåller följande rubriker. Svaret kan även innehålla ytterligare HTTP-standardhuvuden. Alla standardhuvuden överensstämmer med http/1.1-protokollspecifikationen.
| Svarsrubrik | Description |
|---|---|
ETag |
I version 2012-02-12 och senare, om kopian är klar, innehåller ETag den här rubriken värdet för målbloben. Om kopieringen inte är klar innehåller rubriken värdet för den ETag tomma blob som skapades i början av kopieringsåtgärden.I versioner före 2012-02-12 returnerar ETag den här rubriken värdet för målbloben.I version 2011-08-18 och senare ETag är värdet inom citattecken. |
Last-Modified |
Returnerar datum/tid då kopieringsåtgärden till målbloben slutfördes. |
x-ms-request-id |
Identifierar begäran som gjordes unikt. Du kan använda det här huvudet för att felsöka begäran. Mer information finns i Felsöka API-åtgärder. |
x-ms-version |
Anger vilken version av Blob Storage som används för att köra begäran. Det här huvudet returneras för begäranden som görs mot version 2009-09-19 och senare. |
Date |
Ett datum-/tidsvärde för UTC som anger den tid då tjänsten skickade svaret. |
x-ms-copy-id: <id> |
Version 2012-02-12 och senare. Tillhandahåller en strängidentifierare för den här kopieringsåtgärden. Använd med Get Blob eller Get Blob Properties för att kontrollera status för den här kopieringsåtgärden eller skicka till för att Abort Copy Blob avbryta en väntande kopieringsåtgärd. |
x-ms-copy-status: <success ¦ pending> |
Version 2012-02-12 och senare. Anger kopieringsåtgärdens tillstånd med följande värden: - success: Åtgärden har slutförts.- pending: Åtgärden pågår. |
x-ms-version-id: <DateTime> |
Version 2019-12-12 och senare. Identifierar bloben unikt med dess version. Du kan använda det här täckande värdet i efterföljande begäranden för att få åtkomst till den här versionen av bloben. |
x-ms-client-request-id |
Kan användas för att felsöka begäranden och motsvarande svar. Värdet för det här huvudet är lika med värdet x-ms-client-request-id för rubriken, om det finns i begäran och värdet är högst 1 024 synliga ASCII-tecken. Om huvudet x-ms-client-request-id inte finns i begäran kommer det här huvudet inte att finnas i svaret. |
Själva svaret
Inga.
Exempelsvar
Följande kod är ett exempelsvar för en begäran om att kopiera en blob:
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>
Auktorisering
Auktorisering krävs när du anropar en dataåtkomståtgärd i Azure Storage. I följande tabell beskrivs hur mål- och källobjekt för en Copy Blob åtgärd kan auktoriseras:
| Objekttyp | Microsoft Entra ID auktorisering | Sas-auktorisering (signatur för delad åtkomst) | Auktorisering av delad nyckel (eller lite för delad nyckel) |
|---|---|---|---|
| Målblob | Ja | Ja | Yes |
| Källblob i samma lagringskonto | Ja | Ja | Yes |
| Källblob i ett annat lagringskonto | Inga | Ja | Inga |
Om en begäran anger taggar i x-ms-tags begärandehuvudet måste anroparen uppfylla auktoriseringskraven för åtgärden Ange blobtaggar .
Du kan auktorisera åtgärden enligt beskrivningen Copy Blob nedan. Observera att en källblob i ett annat lagringskonto måste auktoriseras separat via SAS-token med läsbehörighet (r). Mer information om auktorisering av källblobar finns i informationen för begärandehuvudet x-ms-copy-source.
Viktigt
Microsoft rekommenderar att du använder Microsoft Entra ID med hanterade identiteter för att auktorisera begäranden till Azure Storage. Microsoft Entra ID ger överlägsen säkerhet och användarvänlighet jämfört med auktorisering med delad nyckel.
Azure Storage stöder användning av Microsoft Entra ID för att auktorisera begäranden till blobdata. Med Microsoft Entra ID kan du använda rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att bevilja behörigheter till ett säkerhetsobjekt. Säkerhetsobjektet kan vara en användare, grupp, programtjänstens huvudnamn eller en hanterad Azure-identitet. Säkerhetsobjektet autentiseras av Microsoft Entra ID för att returnera en OAuth 2.0-token. Token kan sedan användas för att auktorisera en begäran mot Blob-tjänsten.
Mer information om auktorisering med Microsoft Entra ID finns i Auktorisera åtkomst till blobar med hjälp av Microsoft Entra ID.
Behörigheter
Nedan visas den RBAC-åtgärd som krävs för att en Microsoft Entra användare, grupp, hanterad identitet eller tjänstens huvudnamn ska anropa Copy Blob åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som innehåller den här åtgärden:
Målblob
- Azure RBAC-åtgärd:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (för att skriva till en befintlig blob) eller Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (för att skriva en ny blob till målet)
- Minsta privilegierade inbyggda roll:Storage Blob Data-deltagare
Källblob i samma lagringskonto
- Azure RBAC-åtgärd:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
- Minsta privilegierade inbyggda roll:Storage Blob Data Reader
Mer information om hur du tilldelar roller med hjälp av Azure RBAC finns i Tilldela en Azure-roll för åtkomst till blobdata.
Kommentarer
I version 2012-02-12 och senare Copy Blob kan åtgärden slutföras asynkront. Den här åtgärden returnerar ett kopierings-ID som du kan använda för att kontrollera eller avbryta kopieringsåtgärden. På grund av kopieringsåtgärdens asynkrona karaktär kopierar Blob Storage blobar på bästa sätt. Blobtjänsten kopierar blobar när serverresurser inte används av andra uppgifter, så en kopia är inte garanterad att starta omedelbart eller slutföras inom en angiven tidsram.
Källbloben för en kopieringsåtgärd kan vara en blockblob, en tilläggsblob, en sidblob eller en ögonblicksbild. Om målbloben redan finns måste den vara av samma blobtyp som källbloben. Alla befintliga målblobar skrivs över. Du kan inte ändra målbloben när en kopieringsåtgärd pågår.
I version 2015-02-21 och senare kan källan för kopieringsåtgärden också vara en fil i Azure Files. Om källan är en fil måste målet vara en blockblob.
Flera väntande Copy Blob åtgärder i ett konto kan bearbetas sekventiellt. En målblob kan bara ha en enastående Copy Blob åtgärd. Med andra ord kan en blob inte vara målet för flera väntande Copy Blob åtgärder. Ett försök att kopiera en blob till en målblob som redan har en väntande kopieringsåtgärd misslyckas med statuskoden 409 (konflikt).
Endast lagringskonton som skapats den 7 juni 2012 eller senare tillåter Copy Blob att åtgärden kopieras från ett annat lagringskonto. Ett försök att kopiera från ett annat lagringskonto till ett konto som skapades före den 7 juni 2012 misslyckas med statuskoden 400 (felaktig begäran).
Åtgärden Copy Blob kopierar alltid hela källbloben eller -filen. Det går inte att kopiera ett byteintervall eller en uppsättning block.
En Copy Blob åtgärd kan ha något av följande formulär:
Du kan kopiera en källblob till en målblob som har ett annat namn. Målbloben kan vara en befintlig blob av samma blobtyp (block, tillägg eller sida), eller så kan det vara en ny blob som kopieringsåtgärden skapar.
Du kan kopiera en källblob till en målblob som har samma namn och effektivt ersätta målbloben. En sådan kopieringsåtgärd tar bort alla icke-obligatoriska block och skriver över blobens metadata.
Du kan kopiera en källfil i Azure Files till en målblob. Målbloben kan vara en befintlig blockblob eller en ny blockblob som kopieringsåtgärden skapar. Kopiering från filer till sidblobar eller tilläggsblobar stöds inte.
Du kan kopiera en ögonblicksbild över dess basblob. Genom att befordra en ögonblicksbild till basblobens position kan du återställa en tidigare version av en blob.
Du kan kopiera en ögonblicksbild till en målblob som har ett annat namn. Den resulterande målbloben är en skrivbar blob och inte en ögonblicksbild.
När du kopierar från en sidblob skapar Blob Storage en målsideblob med källblobens längd. Till en början innehåller sidbloben alla nollor. Sedan räknas källsidans intervall upp och icke-tomma intervall kopieras.
För en blockblob eller en tilläggsblob skapar Blob Storage en checkad blob med noll längd innan den returneras från den här åtgärden.
När du kopierar från en blockblob kopieras alla bekräftade block och deras block-ID:n. Ej tillåtna block kopieras inte. I slutet av kopieringsåtgärden har målbloben samma antal bekräftade block som källan.
När du kopierar från en tilläggsblob kopieras alla bekräftade block. I slutet av kopieringsåtgärden har målbloben färre än eller samma antal bekräftade block som källbloben.
För alla blobtyper kan du anropa Get Blob eller Get Blob Properties på målbloben för att kontrollera status för kopieringsåtgärden. Den sista bloben checkas in när kopieringsåtgärden är klar.
När källan för en kopieringsåtgärd innehåller ETag värden kommer eventuella ändringar av källan medan kopieringsåtgärden pågår att göra att åtgärden misslyckas. Ett försök att ändra målbloben medan en kopia pågår misslyckas med statuskoden 409 (konflikt). Om målbloben har ett oändligt lån måste låne-ID:t skickas till Copy Blob. Lån med begränsad varaktighet tillåts inte.
Värdet ETag för en blockblob ändras när åtgärden Copy Blob startas och när åtgärden är klar. Värdet ETag för en sidblob ändras när åtgärden Copy Blob startar och den fortsätter att ändras ofta under kopieringsåtgärden. Innehållet i en blockblob visas endast via ett Get kommando när den fullständiga kopieringsåtgärden har slutförts.
Kopiera blobegenskaper, taggar och metadata
När en blob kopieras kopieras följande systemegenskaper till målbloben som har samma värden:
Content-TypeContent-EncodingContent-LanguageContent-LengthCache-ControlContent-MD5Content-Dispositionx-ms-blob-sequence-number(endast för sidblobar)x-ms-committed-block-count(endast för tilläggsblobar och endast för version 2015-02-21)
Källblobens bekräftade blocklista kopieras också till målbloben, om bloben är en blockblob. Alla icke-utelämnade block kopieras inte.
Målbloben har alltid samma storlek som källbloben. Värdet för Content-Length huvudet för målbloben matchar värdet för det huvudet för källbloben.
När källbloben och målbloben är desamma tar Copy Blob bort alla icke-utelämnade block. Om metadata anges i det här fallet skrivs befintliga metadata över med de nya metadata.
x-ms-tags Om huvudet innehåller taggar för målbloben måste de vara frågesträngskodade. Taggnycklar och värden måste överensstämma med namngivnings- och längdkraven, enligt vad som anges i Ange blobtaggar.
Rubriken x-ms-tags kan innehålla upp till 2 kilobitar taggar. Om du behöver fler taggar använder du åtgärden Set Blob Tags .
x-ms-tags Om rubriken inte innehåller taggar kopieras inte taggar från källbloben.
Kopiera en hyrd blob
Åtgärden Copy Blob läser bara från källbloben, så lånetillståndet för källbloben spelar ingen roll. Åtgärden sparar dock Copy Blob värdet för ETag källbloben när kopieringsåtgärden startar. Om värdet ETag ändras innan kopieringsåtgärden är klar misslyckas åtgärden. Du kan förhindra ändringar i källbloben genom att leasa den under kopieringsåtgärden.
Om målbloben har ett aktivt oändligt lån måste du ange dess låne-ID i anropet Copy Blob till åtgärden. Om lånet som du anger är ett aktivt lån med begränsad varaktighet misslyckas det här anropet med statuskoden 412 (villkoret misslyckades). Medan kopieringsåtgärden väntar misslyckas alla låneåtgärder på målbloben med statuskoden 409 (konflikt). Ett oändligt lån på målbloben är låst på det här sättet under kopieringsåtgärden oavsett om du kopierar till en målblob som har ett annat namn än källan, kopierar till en målblob som har samma namn som källan eller befordrar en ögonblicksbild över basbloben.
Om klienten anger ett låne-ID på en blob som ännu inte finns returnerar Blob Storage statuskod 412 (villkorsfel) för begäranden som görs mot version 2013-08-15 och senare. För tidigare versioner returnerar Blob Storage statuskoden 201 (skapad).
Kopiera blobögonblicksbilder
När en källblob kopieras kopieras inga ögonblicksbilder eller versioner av källbloben till målet. När en målblob skrivs över med en kopia förblir alla ögonblicksbilder eller versioner som är associerade med målbloben intakta under dess namn.
Du kan utföra en kopieringsåtgärd för att höja upp en ögonblicksbild över dess basblob, så länge den är på en onlinenivå (frekvent eller lågfrekvent). På så sätt kan du återställa en tidigare version av en blob. Ögonblicksbilden finns kvar, men målet skrivs över med en kopia som kan både läsas och skrivas.
Kopiera blobversioner
Du kan utföra en kopieringsåtgärd för att höja upp en version över dess basblob, så länge den är på en onlinenivå (frekvent eller lågfrekvent). På så sätt kan du återställa en tidigare version av en blob. Versionen finns kvar, men målet skrivs över med en kopia som kan både läsas och skrivas.
Kopiera en arkiverad blob
Från och med version 2018-11-09 kan du kopiera en arkiverad blob till en ny blob i samma lagringskonto. Källbloben finns kvar på arkivnivån. När källbloben är en arkiverad blob måste begäran innehålla x-ms-access-tier huvudet, vilket anger målblobens nivå. Målbloben måste finnas på en onlinenivå. Du kan inte kopiera till en blob på arkivnivån.
Från och med version 2021-02-12 kan du kopiera en arkiverad blob till en onlinenivå i ett annat lagringskonto, så länge målkontot finns i samma region som källkontot.
Begäran kan misslyckas om källbloben extraheras.
Detaljerad information om nivåindelning på blockblobnivå finns i Lagringsnivåer för frekvent, lågfrekvent lagring och arkivlagring.
Arbeta med en väntande kopieringsåtgärd (version 2012-02-12 och senare)
Om åtgärden Copy Blob slutförs asynkront använder du följande tabell för att fastställa nästa steg baserat på den returnerade statuskoden:
| Statuskod | Innebörd |
|---|---|
| 202 (accepterad), x-ms-copy-status: lyckades | Kopieringsåtgärden har slutförts. |
| 202 (accepterad), x-ms-copy-status: väntar | Kopieringsåtgärden har inte slutförts. Avsök målbloben med hjälp Get Blob Properties av för att undersöka x-ms-copy-status huvudet tills åtgärden har slutförts eller misslyckas. |
| 4xx, 500 eller 503 | Kopieringsåtgärden misslyckades. |
Under och efter en Copy Blob åtgärd innehåller egenskaperna för målbloben kopierings-ID Copy Blob för åtgärden och URL:en för källbloben. När åtgärden är klar skriver Blob Storage tids- och utfallsvärdet (success, failedeller aborted) till målblobens egenskaper. Om åtgärden har ett failed resultat x-ms-copy-status-description innehåller rubriken en felinformationssträng.
En väntande Copy Blob åtgärd har en tidsgräns på två veckor. Ett kopieringsförsök som inte har slutförts efter två veckors tidsgräns och lämnar en tom blob med x-ms-copy-status fältet inställt på failed och x-ms-copy-status-description inställt på 500 (OperationCancelled). Tillfälliga, icke-allvarliga fel som kan inträffa under en kopieringsåtgärd kan hindra åtgärdens förlopp men inte orsaka att den misslyckas. I dessa fall x-ms-copy-status-description beskriver de tillfälliga felen.
Alla försök att ändra eller ögonblicksbilda målbloben under kopieringsåtgärden misslyckas med statuskoden 409 (konflikt), "Kopieringsblob pågår".
Om du anropar åtgärden Abort Copy Blob visas ett x-ms-copy-status:aborted huvud. Målbloben har intakta metadata och en bloblängd på 0 byte. Du kan upprepa det ursprungliga anropet till för att Copy Blob försöka utföra kopieringsåtgärden igen.
Om åtgärden Copy Blob slutförs synkront använder du följande tabell för att fastställa status för kopieringsåtgärden:
| Statuskod | Innebörd |
|---|---|
| 202 (accepterad), x-ms-copy-status: lyckades | Kopieringsåtgärden har slutförts. |
| 4xx, 500 eller 503 | Kopieringsåtgärden misslyckades. |
Nivån ärvs för premiumlagringsnivåer. Om du skriver över målbloben för blockblobar ärver den frekventa eller lågfrekventa nivån från målet om x-ms-access-tier den inte anges. Det går inte att skriva över en arkiverad blob. Detaljerad information om nivåindelning på blockblobnivå finns i Lagringsnivåer för frekvent, lågfrekvent lagring och arkivlagring.
Fakturering
Prisbegäranden kan komma från klienter som använder Blob Storage-API:er, antingen direkt via REST-API:et för Blob Storage eller från ett Azure Storage-klientbibliotek. Dessa begäranden ackumulerar avgifter per transaktion. Typen av transaktion påverkar hur kontot debiteras. Lästransaktioner till exempel tillfaller en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Copy Blob begäranden baserat på lagringskontotypen:
| Åtgärd | Typ av lagringskonto | Faktureringskategori |
|---|---|---|
| Kopiera blob (målkonto1) | Premium-blockblob Standard generell användning v2 Standard generell användning v1 |
Skrivåtgärder |
| Kopiera blob (källkonto2) | Premium-blockblob Standard generell användning v2 Standard generell användning v1 |
Läsåtgärder |
1Målkontot debiteras för en transaktion för att initiera skrivning.
2När källobjektet finns i ett annat konto ådrar sig källkontot en transaktion för varje läsbegäran till källobjektet.
Mer information om priser för de angivna faktureringskategorierna finns i Azure Blob Storage Prissättning.
Målkontot medför också transaktionskostnader för varje begäran om att avbryta kopieringsåtgärden (se Avbryt kopieringsblob) eller för att kontrollera status för kopieringsåtgärden (se Hämta blob ellerHämta blobegenskaper).
Om käll- och målkontona finns i olika regioner (till exempel USA, norra och USA, södra) debiteras dessutom bandbredden som du använder för att överföra begäran till källlagringskontot som utgående. Utgående mellan konton i samma region är kostnadsfri.
När du kopierar en källblob till en målblob som har ett annat namn inom samma konto använder du ytterligare lagringsresurser för den nya bloben. Kopieringsåtgärden resulterar sedan i en avgift mot lagringskontots kapacitetsanvändning för dessa ytterligare resurser. Men om namnen på käll- och målblobbarna är desamma inom samma konto (till exempel när du höjer upp en ögonblicksbild till dess basblob) tillkommer ingen extra kostnad, förutom de extra kopieringsmetadata som lagras i version 2012-02-12 och senare.
När du höjer upp en ögonblicksbild för att ersätta dess basblob blir ögonblicksbilden och basbloben identiska. De delar block eller sidor, så kopieringsåtgärden resulterar inte i en extra avgift mot lagringskontots kapacitetsanvändning. Men om du kopierar en ögonblicksbild till en målblob som har ett annat namn medför åtgärden en extra kostnad för de lagringsresurser som den resulterande nya bloben använder. Två blobar som har olika namn kan inte dela block eller sidor, även om de är identiska. Mer information om scenarier för ögonblicksbilder finns i Förstå hur ögonblicksbilder påförs avgifter.
Se även
Auktorisera begäranden till Azure Storage
Status- och felkoder
Felkoder för Blob Storage
Förstå hur ögonblicksbilder ackumuleras avgifter
Avbryt kopieringsblob