Kopiowanie obiektu blob

Operacja Copy Blob kopiuje obiekt blob do miejsca docelowego na koncie magazynu.

W wersji 2012-02-12 lub nowszej źródło Copy Blob operacji może być zatwierdzonym obiektem blob na dowolnym koncie usługi Azure Storage.

Począwszy od wersji 2015-02-21, źródłem Copy Blob operacji może być plik platformy Azure na dowolnym koncie usługi Azure Storage.

Uwaga

Tylko konta magazynu utworzone w dniu 7 czerwca 2012 r. zezwalają na Copy Blob kopiowanie operacji z innego konta magazynu.

Żądanie

Żądanie można skonstruować Copy Blob w następujący sposób. Zalecamy użycie protokołu HTTPS. Zastąp ciąg myaccount nazwą konta magazynu, ciągiem mycontainer nazwą kontenera, a obiekt myblob nazwą docelowego obiektu blob.

Począwszy od wersji 2013-08-15, możesz określić sygnaturę dostępu współdzielonego dla docelowego obiektu blob, jeśli znajduje się na tym samym koncie co źródłowy obiekt blob. Począwszy od wersji 2015-04-05, możesz również określić sygnaturę dostępu współdzielonego dla docelowego obiektu blob, jeśli znajduje się na innym koncie magazynu.

IDENTYFIKATOR URI żądania PUT Wersja PROTOKOŁU HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob HTTP/1.1

Identyfikator URI emulowanej usługi magazynu

Podczas wysyłania żądania względem emulowanej usługi magazynu określ nazwę hosta emulatora i Azure Blob Storage port jako 127.0.0.1:10000, a następnie nazwę emulowanego konta magazynu:

IDENTYFIKATOR URI żądania PUT Wersja PROTOKOŁU HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob HTTP/1.1

Aby uzyskać więcej informacji, zobacz Use the Azurite emulator for local Azure Storage development (Używanie emulatora Azurite do lokalnego programowania w usłudze Azure Storage).

Parametry identyfikatora URI

W identyfikatorze URI żądania można określić następujące dodatkowe parametry:

Parametr Opis
timeout Opcjonalny. Parametr jest wyrażony timeout w sekundach. Aby uzyskać więcej informacji, zobacz Ustawianie limitów czasu dla operacji usługi Blob Storage.

Nagłówki żądań

W poniższej tabeli opisano wymagane i opcjonalne nagłówki żądań:

Nagłówek żądania Opis
Authorization Wymagane. Określa schemat autoryzacji, nazwę konta i podpis. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
Date lub x-ms-date Wymagane. Określa dla żądania godzinę w formacie uniwersalnego czasu koordynowanego (UTC). Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
x-ms-version Wymagane dla wszystkich autoryzowanych żądań. Aby uzyskać więcej informacji, zobacz Przechowywanie wersji usług Azure Storage.
x-ms-meta-name:value Opcjonalny. Określa parę nazw/wartości zdefiniowanych przez użytkownika skojarzonych z obiektem blob. Jeśli nie określono par nazw/wartości, operacja kopiuje metadane ze źródłowego obiektu blob lub pliku do docelowego obiektu blob. Jeśli określono co najmniej jedną parę nazw/wartości, docelowy obiekt blob jest tworzony przy użyciu określonych metadanych, a metadane nie są kopiowane ze źródłowego obiektu blob lub pliku.

Począwszy od wersji 2009-09-19, nazwy metadanych muszą być zgodne z regułami nazewnictwa identyfikatorów języka C#. Aby uzyskać więcej informacji, zobacz Nazewnictwo i odwoływanie się do kontenerów, obiektów blob i metadanych.
x-ms-tags Opcjonalny. Ustawia podane tagi zakodowane w ciągu zapytania w obiekcie blob. Tagi nie są kopiowane ze źródła kopiowania. Aby uzyskać więcej informacji, zobacz Uwagi. Obsługiwane w wersji 2019-12-12 lub nowszej.
x-ms-source-if-modified-since Opcjonalny. Wartość DateTime . Określ ten nagłówek warunkowy, aby skopiować obiekt blob tylko wtedy, gdy źródłowy obiekt blob został zmodyfikowany od określonej daty/godziny. Jeśli źródłowy obiekt blob nie został zmodyfikowany, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiodło się). Nie można określić tego nagłówka, jeśli źródłem jest plik platformy Azure.
x-ms-source-if-unmodified-since Opcjonalny. Wartość DateTime . Określ ten nagłówek warunkowy, aby skopiować obiekt blob tylko wtedy, gdy źródłowy obiekt blob nie został zmodyfikowany od określonej daty/godziny. Jeśli źródłowy obiekt blob został zmodyfikowany, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiodło się). Nie można określić tego nagłówka, jeśli źródłem jest plik platformy Azure.
x-ms-source-if-match Opcjonalny. Wartość ETag . Określ ten nagłówek warunkowy, aby skopiować źródłowy obiekt blob tylko wtedy, gdy jego ETag wartość jest zgodna z określoną wartością. Jeśli wartości nie są zgodne, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiodło się). Nie można określić tego nagłówka, jeśli źródłem jest plik platformy Azure.
x-ms-source-if-none-match Opcjonalny. Wartość ETag . Określ ten nagłówek warunkowy, aby skopiować obiekt blob tylko wtedy, gdy jego ETag wartość nie jest zgodna z określoną wartością. Jeśli wartości są identyczne, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiodło się). Nie można określić tego nagłówka, jeśli źródłem jest plik platformy Azure.
If-Modified-Since Opcjonalny. Wartość DateTime . Określ ten nagłówek warunkowy, aby skopiować obiekt blob tylko wtedy, gdy docelowy obiekt blob został zmodyfikowany od określonej daty/godziny. Jeśli docelowy obiekt blob nie został zmodyfikowany, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiodło się).
If-Unmodified-Since Opcjonalny. Wartość DateTime . Określ ten nagłówek warunkowy, aby skopiować obiekt blob tylko wtedy, gdy docelowy obiekt blob nie został zmodyfikowany od określonej daty/godziny. Jeśli docelowy obiekt blob został zmodyfikowany, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiodło się).
If-Match Opcjonalny. Wartość ETag . ETag Określ wartość dla tego nagłówka warunkowego, aby skopiować obiekt blob tylko wtedy, gdy określona ETag wartość jest zgodna z ETag wartością istniejącego docelowego obiektu blob. Jeśli wartości nie są zgodne, usługa Blob Storage zwraca kod stanu 412 (Warunek wstępny nie powiodło się).
If-None-Match Opcjonalny. Wartość ETag lub symbol wieloznaczny (*).

ETag Określ wartość tego nagłówka warunkowego, aby skopiować obiekt blob tylko wtedy, gdy określona ETag wartość nie jest zgodna z ETag wartością docelowego obiektu blob.

Określ symbol wieloznaczny (*) do wykonania operacji tylko wtedy, gdy docelowy obiekt blob nie istnieje.

Jeśli określony warunek nie zostanie spełniony, usługa Blob Storage zwróci kod stanu 412 (Warunek wstępny nie powiodło się).
x-ms-copy-source:name Wymagane. Określa nazwę źródłowego obiektu blob lub pliku.

Począwszy od wersji 2012-02-12, ta wartość może być adresem URL do 2 kibibajtów (KiB) o długości, która określa obiekt blob. Wartość powinna być zakodowana jako adres URL w identyfikatorze URI żądania.

Operację odczytu źródłowego obiektu blob na tym samym koncie magazynu można autoryzować za pośrednictwem klucza współdzielonego. Począwszy od wersji 2017-11-09, możesz również użyć usługi Azure Active Directory (Azure AD), aby autoryzować operację odczytu w źródłowym obiekcie blob. Jeśli jednak źródło jest obiektem blob na innym koncie magazynu, źródłowy obiekt blob musi być publiczny lub dostęp do niego musi być autoryzowany za pośrednictwem sygnatury dostępu współdzielonego. Jeśli źródłowy obiekt blob jest publiczny, do wykonania operacji kopiowania nie jest wymagana autoryzacja.

Począwszy od wersji 2015-02-21, obiekt źródłowy może być plikiem w Azure Files. Jeśli obiekt źródłowy jest plikiem, który zostanie skopiowany do obiektu blob, plik źródłowy musi być autoryzowany za pośrednictwem sygnatury dostępu współdzielonego, niezależnie od tego, czy znajduje się on na tym samym koncie, czy na innym koncie.

Tylko konta magazynu utworzone w dniu 7 czerwca 2012 r. zezwalają na Copy Blob kopiowanie operacji z innego konta magazynu.

Oto kilka przykładów adresów URL obiektów źródłowych:

- 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>

Gdy obiekt źródłowy jest plikiem w Azure Files, źródłowy adres URL używa następującego formatu. Należy pamiętać, że adres URL musi zawierać prawidłowy token sygnatury dostępu współdzielonego dla pliku.

- https://myaccount.file.core.windows.net/myshare/mydirectorypath/myfile?sastoken

W wersjach wcześniejszych niż 2012-02-12 obiekty blob można kopiować tylko na tym samym koncie, a nazwa źródłowa może używać następujących formatów:

- Obiekt blob w nazwanym kontenerze: /accountName/containerName/blobName
- Migawka w nazwanym kontenerze: /accountName/containerName/blobName?snapshot=<DateTime>
— Obiekt blob w kontenerze głównym: /accountName/blobName
— Migawka w kontenerze głównym: /accountName/blobName?snapshot=<DateTime>
x-ms-lease-id:<ID> Wymagane, jeśli docelowy obiekt blob ma aktywną dzierżawę. Identyfikator dzierżawy określony dla tego nagłówka musi być zgodny z identyfikatorem dzierżawy docelowego obiektu blob. Jeśli żądanie nie zawiera identyfikatora dzierżawy lub identyfikator jest nieprawidłowy, operacja kończy się niepowodzeniem z kodem stanu 412 (Warunek wstępny nie powiodło się).

Jeśli ten nagłówek jest określony, a docelowy obiekt blob nie ma obecnie aktywnej dzierżawy, operacja kończy się niepowodzeniem z kodem stanu 412 (Warunek wstępny nie powiodło się).

W wersji 2012-02-12 lub nowszej ta wartość musi określać aktywną nieskończoną dzierżawę dla dzierżawionego obiektu blob. Identyfikator dzierżawy o skończonym czasie trwania kończy się niepowodzeniem z kodem stanu 412 (Niepowodzenie warunku wstępnego).
x-ms-source-lease-id: <ID> Opcjonalne wersje przed 2012-02-12 (nieobsługiwane w latach 2012-02-12 i nowszych). Określ ten nagłówek, aby wykonać operację Copy Blob tylko wtedy, gdy podany identyfikator dzierżawy jest zgodny z aktywnym identyfikatorem dzierżawy źródłowego obiektu blob.

Jeśli ten nagłówek jest określony, a źródłowy obiekt blob nie ma obecnie aktywnej dzierżawy, operacja kończy się niepowodzeniem z kodem stanu 412 (Warunek wstępny nie powiodło się).
x-ms-client-request-id Opcjonalny. Udostępnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-KiB rejestrowanym w dziennikach usługi Azure Monitor podczas konfigurowania rejestrowania. Zdecydowanie zalecamy używanie tego nagłówka do korelowania działań po stronie klienta z żądaniami odbieranymi przez serwer. Aby uzyskać więcej informacji, zobacz Rejestrowanie platformy Azure: używanie dzienników do śledzenia żądań magazynu.
x-ms-access-tier Opcjonalny. Określa warstwę, która ma zostać ustawiona na docelowym obiekcie blob. Ten nagłówek dotyczy stronicowych obiektów blob na koncie premium tylko w wersji 2017-04-17 lub nowszej. Aby uzyskać pełną listę obsługiwanych warstw, zobacz Magazyn w warstwie Premium o wysokiej wydajności i dyski zarządzane dla maszyn wirtualnych. Ten nagłówek jest obsługiwany w wersji 2018-11-09 i nowszej dla blokowych obiektów blob. Obsługa warstw blokowych obiektów blob jest obsługiwana na kontach usługi Blob Storage lub Ogólnego przeznaczenia v2. Prawidłowe wartości to Hot, Cooli Archive. Aby uzyskać szczegółowe informacje na temat warstw blokowych obiektów blob, zobacz Warstwy magazynowania Gorąca, Chłodna i Archiwum.
x-ms-rehydrate-priority Opcjonalny. Wskazuje priorytet, za pomocą którego należy ponownie uzupełnić zarchiwizowany obiekt blob. Ten nagłówek jest obsługiwany w wersji 2019-02-02 i nowszej dla blokowych obiektów blob. Prawidłowe wartości to High i Standard. Priorytet obiektu blob można ustawić tylko raz. Ten nagłówek zostanie zignorowany w kolejnych żądaniach do tego samego obiektu blob. Domyślny priorytet bez tego nagłówka to Standard.
x-ms-seal-blob Opcjonalny. Obsługiwane w wersji 2019-12-12 lub nowszej. Ten nagłówek jest prawidłowy tylko dla uzupełnialnych obiektów blob. Zamyka docelowy obiekt blob po zakończeniu operacji kopiowania.
x-ms-immutability-policy-until-date Wersja 2020-06-12 lub nowsza. Określa okres przechowywania do daty ustawienia obiektu blob. Jest to data, do której obiekt blob może być chroniony przed modyfikacją lub usunięciem. Jest zgodny z formatem RFC1123.
x-ms-immutability-policy-mode Wersja 2020-06-12 lub nowsza. Określa tryb zasad niezmienności, który ma być ustawiony na obiekcie blob. Prawidłowe wartości to unlocked i locked. Wartość unlocked wskazuje, że użytkownik może zmienić zasady, zwiększając lub zmniejszając okres przechowywania do daty. Wartość locked wskazuje, że te działania są zabronione.
x-ms-legal-hold Wersja 2020-06-12 lub nowsza. Określa blokadę prawną, która ma zostać ustawiona na obiekcie blob. Prawidłowe wartości to true i false.

Ta operacja obsługuje x-ms-if-tags nagłówki warunkowe i x-ms-source-if-tags , aby zakończyły się powodzeniem tylko wtedy, gdy określony warunek zostanie spełniony. Aby uzyskać więcej informacji, zobacz Określanie nagłówków warunkowych dla operacji usługi Blob Storage.

Treść żądania

Brak.

Reakcja

Odpowiedź zawiera kod stanu HTTP i zestaw nagłówków odpowiedzi.

Kod stanu

W wersji 2012-02-12 i nowszej operacja zakończona powodzeniem zwraca kod stanu 202 (Zaakceptowano).

W wersjach wcześniejszych niż 2012-02-12 operacja powiodła się zwraca kod stanu 201 (Utworzono).

Aby uzyskać informacje o kodach stanu, zobacz Stan i kody błędów.

Nagłówki odpowiedzi

Odpowiedź na tę operację zawiera następujące nagłówki. Odpowiedź może również zawierać dodatkowe standardowe nagłówki HTTP. Wszystkie nagłówki standardowe są zgodne ze specyfikacją protokołu HTTP/1.1.

Nagłówek odpowiedzi Opis
ETag W wersji 2012-02-12 lub nowszej, jeśli kopia zostanie ukończona, ten nagłówek zawiera ETag wartość docelowego obiektu blob. Jeśli kopia nie zostanie ukończona, nagłówek zawiera ETag wartość pustego obiektu blob utworzonego na początku operacji kopiowania.

W wersjach wcześniejszych niż 2012-02-12 ten nagłówek zwraca ETag wartość docelowego obiektu blob.

W wersji 2011-08-18 i nowszej ETag wartość jest w cudzysłowie.
Last-Modified Zwraca datę/godzinę zakończenia operacji kopiowania do docelowego obiektu blob.
x-ms-request-id Jednoznacznie identyfikuje wykonane żądanie. Ten nagłówek służy do rozwiązywania problemów z żądaniem. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z operacjami interfejsu API.
x-ms-version Wskazuje wersję usługi Blob Storage, która jest używana do wykonania żądania. Ten nagłówek jest zwracany dla żądań wysyłanych w wersji 2009-09-19 lub nowszej.
Date Wartość daty/godziny UTC wskazująca godzinę, w której usługa wysłała odpowiedź.
x-ms-copy-id: <id> Wersja 2012-02-12 lub nowsza. Zawiera identyfikator ciągu dla tej operacji kopiowania. Użyj polecenia Get Blob lub Get Blob Properties , aby sprawdzić stan tej operacji kopiowania lub przekazać polecenie , aby Abort Copy Blob anulować oczekującą operację kopiowania.
x-ms-copy-status: <success &#124; pending> Wersja 2012-02-12 lub nowsza. Wskazuje stan operacji kopiowania z następującymi wartościami:

- success: operacja zakończyła się pomyślnie.
- pending: Operacja jest w toku.
x-ms-version-id: <DateTime> Wersja 2019-12-12 lub nowsza. Jednoznacznie identyfikuje obiekt blob według jego wersji. Tę nieprzezroczystą wartość można użyć w kolejnych żądaniach, aby uzyskać dostęp do tej wersji obiektu blob.
x-ms-client-request-id Może służyć do rozwiązywania problemów z żądaniami i odpowiadającymi im odpowiedziami. Wartość tego nagłówka jest równa wartości x-ms-client-request-id nagłówka, jeśli znajduje się w żądaniu, a wartość wynosi co najwyżej 1024 widoczne znaki ASCII. x-ms-client-request-id Jeśli nagłówek nie znajduje się w żądaniu, ten nagłówek nie będzie obecny w odpowiedzi.

Treść odpowiedzi

Brak.

Przykładowa odpowiedź

Poniższy kod to przykładowa odpowiedź żądania kopiowania obiektu 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>  
  

Autoryzacja

Właściciel konta może wywołać tę operację. W przypadku żądań wysyłanych w wersji 2013-08-15 lub nowszej sygnatura dostępu współdzielonego z uprawnieniami do zapisu w docelowym obiekcie blob lub jego kontenerze jest obsługiwana w przypadku operacji kopiowania w ramach tego samego konta. Należy pamiętać, że sygnatura dostępu współdzielonego określona w żądaniu ma zastosowanie tylko do docelowego obiektu blob.

Dostęp do źródłowego obiektu blob lub pliku jest autoryzowany oddzielnie, zgodnie z opisem w szczegółach nagłówka x-ms-copy-sourceżądania .

W poniższej tabeli opisano, jak można autoryzować obiekty docelowe i źródłowe dla Copy Blob operacji:

Obiekt blob Autoryzacja przy użyciu klucza wspólnego lub klucza wspólnego Lite Autoryzacja z sygnaturą dostępu współdzielonego Obiekt publiczny nie wymaga autoryzacji
Docelowy obiekt blob Tak Tak Nie
Źródłowy obiekt blob na tym samym koncie Tak Tak Tak
Źródłowy obiekt blob na innym koncie Nie Tak Tak
Plik źródłowy na tym samym koncie lub innym koncie Nie Tak Nie dotyczy

Jeśli żądanie określa tagi w nagłówku x-ms-tags żądania, obiekt wywołujący musi spełniać wymagania autoryzacji operacji Ustawianie tagów obiektów blob .

Uwagi

W wersji 2012-02-12 lub nowszej Copy Blob operacja może zakończyć się asynchronicznie. Ta operacja zwraca identyfikator kopiowania, którego można użyć do sprawdzenia lub anulowania operacji kopiowania. Usługa Blob Storage kopiuje obiekty blob w oparciu o najlepsze wysiłki.

Źródłowy obiekt blob operacji kopiowania może być blokowym obiektem blob, uzupełnianym obiektem blob, stronicowym obiektem blob lub migawką. Jeśli docelowy obiekt blob już istnieje, musi mieć ten sam typ obiektu blob co źródłowy obiekt blob. Każdy istniejący docelowy obiekt blob zostanie zastąpiony. Nie można zmodyfikować docelowego obiektu blob, gdy trwa operacja kopiowania.

W wersji 2015-02-21 lub nowszej źródło operacji kopiowania może być również plikiem w Azure Files. Jeśli źródło jest plikiem, miejsce docelowe musi być blokowym obiektem blob.

Wiele oczekujących Copy Blob operacji na koncie może być przetwarzanych sekwencyjnie. Docelowy obiekt blob może mieć tylko jedną oczekującą Copy Blob operację. Innymi słowy obiekt blob nie może być miejscem docelowym dla wielu oczekujących Copy Blob operacji. Próba skopiowania obiektu blob do docelowego obiektu blob, który ma już oczekującą operację kopiowania, kończy się niepowodzeniem z kodem stanu 409 (Konflikt).

Tylko konta magazynu utworzone 7 czerwca 2012 r. lub później umożliwiają Copy Blob kopiowanie operacji z innego konta magazynu. Próba skopiowania z innego konta magazynu do konta utworzonego przed 7 czerwca 2012 r. kończy się niepowodzeniem z kodem stanu 400 (nieprawidłowe żądanie).

Operacja Copy Blob zawsze kopiuje cały źródłowy obiekt blob lub plik. Kopiowanie zakresu bajtów lub zestawu bloków nie jest obsługiwane.

Operacja Copy Blob może przyjmować dowolną z następujących form:

  • Źródłowy obiekt blob można skopiować do docelowego obiektu blob o innej nazwie. Docelowy obiekt blob może być istniejącym obiektem blob tego samego typu obiektu blob (blokowym, dołączanym lub stronicowym) lub może być nowym obiektem blob tworzonym przez operację kopiowania.

  • Źródłowy obiekt blob można skopiować do docelowego obiektu blob, który ma taką samą nazwę, skutecznie zastępując docelowy obiekt blob. Taka operacja kopiowania usuwa wszystkie niezatwierdzone bloki i zastępuje metadane obiektu blob.

  • Plik źródłowy można skopiować w Azure Files do docelowego obiektu blob. Docelowy obiekt blob może być istniejącym blokowym obiektem blob lub może być nowym blokowym obiektem blob tworzonym przez operację kopiowania. Kopiowanie z plików do stronicowych obiektów blob lub uzupełnialnych obiektów blob nie jest obsługiwane.

  • Migawkę można skopiować na podstawowy obiekt blob. Promując migawkę do pozycji podstawowego obiektu blob, można przywrócić wcześniejszą wersję obiektu blob.

  • Migawkę można skopiować do docelowego obiektu blob o innej nazwie. Wynikowy docelowy obiekt blob jest zapisywalnym obiektem blob, a nie migawką.

Podczas kopiowania ze stronicowego obiektu blob usługa Blob Storage tworzy docelowy stronicowy obiekt blob o długości źródłowego obiektu blob. Początkowo stronicowy obiekt blob zawiera wszystkie zera. Następnie zakresy stron źródłowych są wyliczane, a zakresy niepuste są kopiowane.

W przypadku blokowego obiektu blob lub uzupełnialnych obiektów blob usługa Blob Storage tworzy zatwierdzony obiekt blob o zerowej długości przed powrotem z tej operacji.

Podczas kopiowania z blokowego obiektu blob wszystkie zatwierdzone bloki i ich identyfikatory bloków są kopiowane. Niezatwierdzone bloki nie są kopiowane. Na końcu operacji kopiowania docelowy obiekt blob ma taką samą liczbę zatwierdzonych bloków co źródło.

Podczas kopiowania z uzupełnialnych obiektów blob wszystkie zatwierdzone bloki są kopiowane. Na końcu operacji kopiowania docelowy obiekt blob będzie miał mniej niż lub taką samą liczbę zatwierdzonych bloków co źródłowy obiekt blob.

W przypadku wszystkich typów obiektów blob można wywołać Get Blob obiekt blob lub Get Blob Properties w docelowym obiekcie blob, aby sprawdzić stan operacji kopiowania. Końcowy obiekt blob zostanie zatwierdzony po zakończeniu operacji kopiowania.

Gdy źródło operacji kopiowania zawiera ETag wartości, wszelkie zmiany w źródle podczas wykonywania operacji kopiowania spowodują niepowodzenie tej operacji. Próba zmiany docelowego obiektu blob, gdy kopia jest w toku, zakończy się niepowodzeniem z kodem stanu 409 (konflikt). Jeśli docelowy obiekt blob ma nieskończoną dzierżawę, identyfikator dzierżawy musi zostać przekazany do .Copy Blob Dzierżawy ograniczonego czasu trwania są niedozwolone.

Wartość ETag blokowego obiektu blob zmienia się po uruchomieniu Copy Blob operacji i zakończeniu operacji. Wartość ETag stronicowego obiektu blob zmienia się podczas Copy Blob uruchamiania operacji i nadal zmienia się często podczas operacji kopiowania. Zawartość blokowego obiektu blob jest widoczna za pomocą Get polecenia dopiero po zakończeniu pełnej operacji kopiowania.

Kopiowanie właściwości obiektu blob, tagów i metadanych

Po skopiowaniu obiektu blob następujące właściwości systemowe są kopiowane do docelowego obiektu blob, który ma te same wartości:

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

  • x-ms-blob-sequence-number (tylko dla stronicowych obiektów blob)

  • x-ms-committed-block-count (tylko dla uzupełnialnych obiektów blob i tylko w wersji 2015-02-21)

Zatwierdzona lista bloków obiektu blob źródłowego jest również kopiowana do docelowego obiektu blob, jeśli obiekt blob jest blokowym obiektem blob. Żadne niezatwierdzone bloki nie są kopiowane.

Docelowy obiekt blob jest zawsze taki sam jak źródłowy obiekt blob. Wartość nagłówka Content-Length docelowego obiektu blob odpowiada wartości tego nagłówka źródłowego obiektu blob.

Gdy źródłowy obiekt blob i docelowy obiekt blob są takie same, Copy Blob usuwa wszystkie niezatwierdzone bloki. Jeśli w tym przypadku określono metadane, istniejące metadane zostaną zastąpione nowymi metadanymi.

x-ms-tags Jeśli nagłówek zawiera tagi dla docelowego obiektu blob, muszą być zakodowane w ciągu zapytania. Klucze i wartości tagów muszą być zgodne z wymaganiami dotyczącymi nazewnictwa i długości, jak określono w temacie Ustawianie tagów obiektów blob.

Nagłówek x-ms-tags może zawierać maksymalnie 2 kilobity tagów. Jeśli potrzebujesz więcej tagów, użyj Set Blob Tags operacji .

x-ms-tags Jeśli nagłówek nie udostępnia tagów, tagi nie są kopiowane ze źródłowego obiektu blob.

Kopiowanie dzierżawionego obiektu blob

Operacja Copy Blob jest odczytywana tylko ze źródłowego obiektu blob, więc stan dzierżawy źródłowego obiektu blob nie ma znaczenia. Copy Blob Jednak operacja zapisuje ETag wartość źródłowego obiektu blob po rozpoczęciu operacji kopiowania. ETag Jeśli wartość zmieni się przed zakończeniem operacji kopiowania, operacja zakończy się niepowodzeniem. Możesz zapobiec zmianom źródłowego obiektu blob, dzierżawiając go podczas operacji kopiowania.

Jeśli docelowy obiekt blob ma aktywną nieskończoną dzierżawę, należy określić jego identyfikator dzierżawy w wywołaniu Copy Blob operacji. Jeśli określona dzierżawa jest aktywną dzierżawą skończoną, to wywołanie zakończy się niepowodzeniem z kodem stanu 412 (Warunek wstępny nie powiodło się). Podczas gdy operacja kopiowania jest oczekująca, każda operacja dzierżawy w docelowym obiekcie blob kończy się niepowodzeniem z kodem stanu 409 (Konflikt). Nieskończona dzierżawa docelowego obiektu blob jest zablokowana w ten sposób podczas operacji kopiowania niezależnie od tego, czy kopiujesz do docelowego obiektu blob, który ma inną nazwę od źródła, kopiując do docelowego obiektu blob o tej samej nazwie co źródło, czy promując migawkę nad podstawowym obiektem blob.

Jeśli klient określa identyfikator dzierżawy obiektu blob, który jeszcze nie istnieje, usługa Blob Storage zwraca kod stanu 412 (Niepowodzenie warunku wstępnego) dla żądań wysyłanych w wersji 2013-08-15 lub nowszej. W przypadku wcześniejszych wersji usługa Blob Storage zwraca kod stanu 201 (Utworzono).

Kopiowanie migawek obiektów blob

Po skopiowaniu źródłowego obiektu blob wszystkie migawki lub wersje źródłowego obiektu blob nie są kopiowane do miejsca docelowego. Gdy docelowy obiekt blob zostanie zastąpiony kopią, wszystkie migawki lub wersje skojarzone z docelowym obiektem blob pozostaną nienaruszone pod jego nazwą.

Możesz wykonać operację kopiowania, aby podwyższyć poziom migawki względem podstawowego obiektu blob, o ile znajduje się on w warstwie online (gorąca lub chłodna). W ten sposób można przywrócić wcześniejszą wersję obiektu blob. Migawka pozostaje, ale jej miejsce docelowe jest zastępowane kopią, która może być odczytywana i zapisywana.

Kopiowanie wersji obiektów blob

Możesz wykonać operację kopiowania, aby podwyższyć poziom wersji względem podstawowego obiektu blob, o ile znajduje się w warstwie online (gorąca lub chłodna). W ten sposób można przywrócić wcześniejszą wersję obiektu blob. Wersja pozostaje, ale jej miejsce docelowe jest zastępowane kopią, która może być odczytywana i zapisywana.

Kopiowanie zarchiwizowanego obiektu blob

Począwszy od wersji 2018-11-09, można skopiować zarchiwizowany obiekt blob do nowego obiektu blob w ramach tego samego konta magazynu. Źródłowy obiekt blob pozostaje w warstwie archiwum. Gdy źródłowy obiekt blob jest zarchiwizowanym obiektem blob, żądanie musi zawierać nagłówek, który wskazuje warstwę x-ms-access-tier docelowego obiektu blob. Docelowy obiekt blob musi znajdować się w warstwie online. Nie można skopiować do obiektu blob w warstwie archiwum.

Począwszy od wersji 2021-02-12, można skopiować zarchiwizowany obiekt blob do warstwy online na innym koncie magazynu, o ile konto docelowe znajduje się w tym samym regionie co konto źródłowe.

Żądanie może zakończyć się niepowodzeniem, jeśli źródłowy obiekt blob jest ponownie wypełniania.

Aby uzyskać szczegółowe informacje na temat obsługi warstw na poziomie blokowych obiektów blob, zobacz Warstwy magazynowania Gorąca, Chłodna i Archiwum.

Praca z oczekującą operacją kopiowania (wersja 2012-02-12 lub nowsza)

Copy Blob Jeśli operacja zakończy się asynchronicznie, użyj poniższej tabeli, aby określić następny krok na podstawie zwróconego kodu stanu:

Kod stanu Znaczenie
202 (Zaakceptowano), x-ms-copy-status: powodzenie Operacja kopiowania zakończyła się pomyślnie.
202 (Zaakceptowano), x-ms-copy-status: oczekiwanie Operacja kopiowania nie została zakończona. Sonduj docelowy obiekt blob przy użyciu polecenia , Get Blob Properties aby zbadać x-ms-copy-status nagłówek do momentu zakończenia lub niepowodzenia operacji.
4xx, 500 lub 503 Operacja kopiowania nie powiodła się.

Podczas operacji i po Copy Blob operacji właściwości docelowego obiektu blob zawierają identyfikator Copy Blob kopii operacji i adresu URL źródłowego obiektu blob. Po zakończeniu operacji usługa Blob Storage zapisuje wartość czasu i wyniku (success, failedlub aborted) we właściwościach docelowego obiektu blob. Jeśli operacja ma failed wynik, x-ms-copy-status-description nagłówek zawiera ciąg szczegółów błędu.

Oczekująca Copy Blob operacja ma limit czasu dwutygodniowego. Próba kopiowania, która nie została zakończona po dwóch tygodniach, i pozostawia pusty obiekt blob z x-ms-copy-status polem ustawionym na failed i x-ms-copy-status-description ustawionym na 500 (OperationCancelled). Sporadyczne błędy niekrytyczne, które mogą wystąpić podczas operacji kopiowania, mogą utrudniać postęp operacji, ale nie powodować niepowodzenia. W takich przypadkach x-ms-copy-status-description opisano sporadyczne błędy.

Każda próba zmodyfikowania lub migawki docelowego obiektu blob podczas operacji kopiowania zakończy się niepowodzeniem z kodem stanu 409 (konflikt), "Kopiuj obiekt blob w toku".

Jeśli wywołasz operację Abort Copy Blobx-ms-copy-status:aborted , zobaczysz nagłówek. Docelowy obiekt blob będzie miał nienaruszone metadane i długość obiektu blob o długości 0 bajtów. Możesz powtórzyć oryginalne wywołanie, aby Copy Blob spróbować ponownie wykonać operację kopiowania.

Copy Blob Jeśli operacja zakończy się synchronicznie, użyj poniższej tabeli, aby określić stan operacji kopiowania:

Kod stanu Znaczenie
202 (Zaakceptowano), x-ms-copy-status: powodzenie Operacja kopiowania zakończyła się pomyślnie.
4xx, 500 lub 503 Operacja kopiowania nie powiodła się.

Warstwa jest dziedziczona dla warstw magazynowania w warstwach Premium. W przypadku blokowych obiektów blob zastąpienie docelowego obiektu blob będzie dziedziczyć warstwę Gorąca lub Chłodna z miejsca docelowego, jeśli x-ms-access-tier nie zostanie podana. Zastąpienie zarchiwizowanego obiektu blob zakończy się niepowodzeniem. Aby uzyskać szczegółowe informacje na temat obsługi warstw na poziomie blokowych obiektów blob, zobacz Warstwy magazynowania Gorąca, Chłodna i Archiwum.

Rozliczenia

Konto docelowe Copy Blob operacji jest naliczane za jedną transakcję w celu uruchomienia kopii. Konto docelowe powoduje również jedną transakcję dla każdego żądania anulowania lub żądania stanu operacji kopiowania.

Gdy źródłowy obiekt blob znajduje się na innym koncie, konto źródłowe ponosi koszty transakcji. Ponadto jeśli konta źródłowe i docelowe znajdują się w różnych regionach (na przykład Północno-wschodnie stany USA i Południowe stany USA), przepustowość używana do przeniesienia żądania jest naliczana na źródłowym koncie magazynu jako ruch wychodzący. Ruch wychodzący między kontami w tym samym regionie jest bezpłatny.

Podczas kopiowania źródłowego obiektu blob do docelowego obiektu blob o innej nazwie na tym samym koncie należy użyć dodatkowych zasobów magazynu dla nowego obiektu blob. Operacja kopiowania powoduje naliczanie opłat za użycie pojemności konta magazynu dla tych dodatkowych zasobów. Jeśli jednak nazwy źródłowych i docelowych obiektów blob są takie same na tym samym koncie (na przykład w przypadku podwyższania poziomu migawki do podstawowego obiektu blob), nie są naliczane dodatkowe opłaty, inne niż dodatkowe metadane kopii przechowywane w wersji 2012-02-12 lub nowszej.

Gdy podwyższasz poziom migawki, aby zastąpić podstawowy obiekt blob, migawka i podstawowy obiekt blob stają się identyczne. Współużytkują bloki lub strony, więc operacja kopiowania nie powoduje naliczania dodatkowych opłat za użycie pojemności konta magazynu. Jeśli jednak skopiujesz migawkę do docelowego obiektu blob o innej nazwie, ta operacja spowoduje naliczanie dodatkowej opłaty za zasoby magazynu używane przez wynikowy nowy obiekt blob. Dwa obiekty blob, które mają różne nazwy, nie mogą współużytkować bloków ani stron, nawet jeśli są identyczne. Aby uzyskać więcej informacji na temat scenariuszy kosztów migawek, zobacz Opis sposobu naliczania opłat za migawki.

Zobacz też

Autoryzowanie żądań do usługi Azure Storage
Kody stanu i błędów
Kody błędów usługi Blob Storage
Opis sposobu naliczania opłat za migawki
Przerwanie kopiowania obiektu blob