Udostępnij za pośrednictwem

Kopiowanie obiektu blob

  • Artykuł

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

W wersji 2012-02-12 lub nowszej źródło operacji może być zatwierdzonym obiektem Copy Blob 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 7 czerwca 2012 r. lub później umożliwiają 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 mycontainer nazwą kontenera, a ciąg myblob nazwą docelowego obiektu blob.

Począwszy od wersji 2013-08-15, można 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żna 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

Gdy wysyłasz żądanie 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

Dla identyfikatora 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 dla usług Azure Storage.
x-ms-meta-name:value Opcjonalny. Określa parę nazwa/wartość zdefiniowana przez użytkownika skojarzona z obiektem blob. Jeśli nie określono żadnych par nazwa/wartość, operacja kopiuje metadane ze źródłowego obiektu blob lub pliku do docelowego obiektu blob. Jeśli określono co najmniej jedną parę nazwa/wartość, docelowy obiekt blob jest tworzony z określonymi metadanymi, 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. DateTime Wartość. 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 (Niepowodzenie warunku wstępnego). Nie można określić tego nagłówka, jeśli źródłem jest plik platformy Azure.
x-ms-source-if-unmodified-since Opcjonalny. DateTime Wartość. 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 (Niepowodzenie warunku wstępnego). 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 (Niepowodzenie warunku wstępnego). 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 (Niepowodzenie warunku wstępnego). Nie można określić tego nagłówka, jeśli źródłem jest plik platformy Azure.
If-Modified-Since Opcjonalny. DateTime Wartość. 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 (Niepowodzenie warunku wstępnego).
If-Unmodified-Since Opcjonalny. DateTime Wartość. 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 (Niepowodzenie warunku wstępnego).
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 (Niepowodzenie warunku wstępnego).
If-None-Match Opcjonalny. ETag Wartość lub symbol wieloznaczny (*).

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

Określ symbol wieloznaczny (*), aby wykonać operację 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 (Niepowodzenie warunku wstępnego).
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 określającej obiekt blob. Wartość powinna być zakodowana w adresie URL, tak jak byłaby wyświetlana w identyfikatorze URI żądania.

Operacja odczytu źródłowego obiektu blob na tym samym koncie magazynu może być autoryzowana za pośrednictwem klucza współużytkowanego. Począwszy od wersji 2017-11-09, można również użyć Tożsamość Microsoft Entra do autoryzowania operacji 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 żadna 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ę na tym samym koncie, czy na innym koncie.

Tylko konta magazynu utworzone 7 czerwca 2012 r. lub później umożliwiają Copy Blob kopiowanie operacji z innego konta magazynu.

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

- 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 SAS 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 (Niepowodzenie warunku wstępnego).

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 (Niepowodzenie warunku wstępnego).

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 dla wersji starszych niż 2012-02-12 (nieobsługiwane w wersji 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 (Niepowodzenie warunku wstępnego).
x-ms-client-request-id Opcjonalny. Zapewnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-KiB rejestrowanym w dziennikach podczas konfigurowania rejestrowania. Zdecydowanie zalecamy używanie tego nagłówka do korelowania działań po stronie klienta z żądaniami odbieranymi przez serwer.
x-ms-access-tier Opcjonalny. Określa warstwę, która ma zostać ustawiona w 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 lub 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, CoolCold i Archive. Uwaga:Cold warstwa jest obsługiwana w wersji 2021-12-02 lub nowszej. 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 ma być przywracany zarchiwizowany obiekt blob. Ten nagłówek jest obsługiwany w wersji 2019-02-02 lub 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, który ma zostać ustawiony w obiekcie 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 w obiekcie blob. Prawidłowe wartości to unlocked i locked. Wartość unlocked wskazuje, że użytkownik może zmienić zasady przez zwiększenie lub zmniejszenie okresu przechowywania do daty. Wartość locked wskazuje, że te działania są zabronione.
x-ms-legal-hold Wersja 2020-06-12 lub nowsza. Określa archiwizację prawną, która ma zostać ustawiona w obiekcie blob. Prawidłowe wartości to true i false.

Ta operacja obsługuje x-ms-if-tags nagłówki i x-ms-source-if-tags warunkowe, aby zakończyć 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 lub nowszej operacja powiodła się zwraca kod stanu 202 (Zaakceptowano).

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

Aby uzyskać informacje o kodach stanu, zobacz Kody stanu i 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 standardowe nagłówki są zgodne ze specyfikacją protokołu HTTP/1.1.

Nagłówek odpowiedzi Opis
ETag W wersji 2012-02-12 lub nowszej, jeśli kopia została 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 starszych niż 2012-02-12 ten nagłówek zwraca ETag wartość docelowego obiektu blob.

W wersji 2011-08-18 lub nowszej ETag wartość jest w cudzysłowie.
Last-Modified Zwraca datę/godzinę zakończenia operacji kopiowania do docelowego obiektu blob.
x-ms-request-id Unikatowo identyfikuje żądanie, które zostało wykonane. 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 w przypadku żądań wysyłanych w wersji 2009-09-19 lub nowszej.
Date Wartość daty/godziny UTC wskazująca godzinę, o 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 lub Get BlobGet Blob Properties , aby sprawdzić stan tej operacji kopiowania, lub przekaż polecenie , aby Abort Copy Blob anulować oczekującą operację kopiowania.
x-ms-copy-status: <success ¦ 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. Unikatowo identyfikuje obiekt blob według jego wersji. Tej nieprzezroczystej wartości można użyć w kolejnych żądaniach dostępu 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 odpowiedziami. Wartość tego nagłówka jest równa wartości nagłówka x-ms-client-request-id , jeśli jest obecna w żądaniu, a wartość wynosi najwyżej 1024 widoczne znaki ASCII. x-ms-client-request-id Jeśli nagłówek nie istnieje w żądaniu, ten nagłówek nie będzie obecny w odpowiedzi.

Treść odpowiedzi

Brak.

Przykładowa odpowiedź

Poniższy kod to przykładowa odpowiedź na żądanie 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

Autoryzacja jest wymagana podczas wywoływania dowolnej operacji dostępu do danych w usłudze Azure Storage. W poniższej tabeli opisano sposób autoryzacji obiektów docelowych i źródłowych dla Copy Blob operacji:

Typ obiektu autoryzacja Tożsamość Microsoft Entra Autoryzacja sygnatury dostępu współdzielonego (SAS) Autoryzacja klucza współdzielonego (lub klucz udostępniony Lite)
Docelowy obiekt blob Tak Tak Tak
Źródłowy obiekt blob na tym samym koncie magazynu Tak Tak Tak
Źródłowy obiekt blob na innym koncie magazynu Nie Tak Nie

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 .

Możesz autoryzować operację zgodnie z Copy Blob poniższym opisem. Należy pamiętać, że źródłowy obiekt blob na innym koncie magazynu musi być autoryzowany oddzielnie za pośrednictwem tokenu SAS z uprawnieniem Odczyt (r). Aby uzyskać więcej informacji na temat autoryzacji źródłowego obiektu blob, zobacz szczegóły nagłówka x-ms-copy-sourceżądania .

Ważne

Firma Microsoft zaleca używanie Tożsamość Microsoft Entra z tożsamościami zarządzanymi w celu autoryzowania żądań do usługi Azure Storage. Tożsamość Microsoft Entra zapewnia doskonałe zabezpieczenia i łatwość użycia w porównaniu z autoryzacją klucza współdzielonego.

Usługa Azure Storage obsługuje używanie Tożsamość Microsoft Entra do autoryzacji żądań do danych obiektów blob. Za pomocą Tożsamość Microsoft Entra możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby udzielić uprawnień podmiotowi zabezpieczeń. Podmiot zabezpieczeń może być użytkownikiem, grupą, jednostką usługi aplikacji lub tożsamością zarządzaną platformy Azure. Podmiot zabezpieczeń jest uwierzytelniany przez Tożsamość Microsoft Entra w celu zwrócenia tokenu OAuth 2.0. Token może następnie służyć do autoryzowania żądania względem usługi Blob Service.

Aby dowiedzieć się więcej na temat autoryzacji przy użyciu Tożsamość Microsoft Entra, zobacz Autoryzowanie dostępu do obiektów blob przy użyciu Tożsamość Microsoft Entra.

Uprawnienia

Poniżej przedstawiono akcję RBAC niezbędną do Microsoft Entra użytkownika, grupy, tożsamości zarządzanej lub jednostki usługi w celu wywołania Copy Blob operacji oraz najmniej uprzywilejowanej wbudowanej roli RBAC platformy Azure, która obejmuje tę akcję:

Docelowy obiekt blob

Źródłowy obiekt blob na tym samym koncie magazynu

Aby dowiedzieć się więcej na temat przypisywania ról przy użyciu kontroli dostępu opartej na rolach platformy Azure, zobacz Przypisywanie roli platformy Azure w celu uzyskania dostępu do danych 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. Ze względu na asynchroniczną naturę operacji kopiowania usługa Blob Storage kopiuje obiekty blob na zasadzie najlepszego nakładu pracy. Usługa Blob Service kopiuje obiekty blob, gdy zasoby serwera nie są używane przez inne zadania, więc nie ma gwarancji, że kopia zostanie uruchomiona natychmiast lub ukończona w określonym przedziale czasu.

Ź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 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 obiektów 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 tagów i wartości 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

Podczas kopiowania ź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 w celu podwyższenia poziomu migawki do 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órą można odczytywać i zapisywać.

Kopiowanie wersji obiektów blob

Możesz wykonać operację kopiowania, aby podwyższyć poziom wersji do bazowego 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. Wersja pozostaje, ale jej miejsce docelowe jest zastępowane kopią, którą można odczytywać i zapisywać.

Kopiowanie zarchiwizowanego obiektu blob

Począwszy od wersji 2018-11-09, można skopiować zarchiwizowany obiekt blob do nowego obiektu blob na tym samym koncie magazynu. Źródłowy obiekt blob pozostaje w warstwie Archiwum. Gdy źródłowy obiekt blob jest zarchiwizowanym obiektem blob, żądanie musi zawierać x-ms-access-tier nagłówek, który wskazuje warstwę 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 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 i nowsze)

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 kopii Copy Blob operacji i adres 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 powodują 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 ponowić próbę wykonania operacji 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 magazynu w warstwie 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 warstw na poziomie blokowych obiektów blob, zobacz Warstwy magazynowania Gorąca, Chłodna i Archiwum.

Rozliczenia

Żądania cen mogą pochodzić od klientów korzystających z interfejsów API usługi Blob Storage bezpośrednio za pośrednictwem interfejsu API REST usługi Blob Storage lub biblioteki klienta usługi Azure Storage. Te żądania naliczają opłaty za transakcję. Typ transakcji wpływa na sposób naliczania opłat za konto. Na przykład transakcje odczytu są naliczane w innej kategorii rozliczeniowej niż transakcje zapisu. W poniższej tabeli przedstawiono kategorię rozliczeń dla Copy Blob żądań na podstawie typu konta magazynu:

Operacja Typ konta magazynu Kategoria rozliczeń
Kopiowanie obiektu blob (konto docelowe1) Blokowy obiekt blob w warstwie Premium
Standardowa ogólnego przeznaczenia, wersja 2
Standardowa ogólnego przeznaczenia, wersja 1		 Operacje zapisu
Kopiowanie obiektu blob (konto źródłowe2) Blokowy obiekt blob w warstwie Premium
Standardowa ogólnego przeznaczenia, wersja 2
Standardowa ogólnego przeznaczenia, wersja 1		 Operacje odczytu

1Konto docelowe jest obciążane opłatą za jedną transakcję w celu zainicjowania zapisu.
2Gdy obiekt źródłowy znajduje się na innym koncie, konto źródłowe powoduje naliczenie jednej transakcji dla każdego żądania odczytu do obiektu źródłowego.

Aby dowiedzieć się więcej o cenach dla określonych kategorii rozliczeń, zobacz Azure Blob Storage Cennik.

Konto docelowe wiąże się również z kosztami transakcji dla każdego żądania anulowania operacji kopiowania (zobacz Abort Copy Blob) lub sprawdzania stanu operacji kopiowania (zobacz Pobieranie obiektu blob lub Uzyskiwanie właściwości obiektu blob).

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ższenia poziomu migawki do podstawowego obiektu blob), nie są naliczane żadne dodatkowe opłaty, inne niż dodatkowe metadane kopiowania przechowywane w wersji 2012-02-12 lub nowszej.

Gdy podwyższasz poziom migawki w celu zastąpienia jej podstawowego obiektu 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, operacja ta spowoduje naliczenie dodatkowej opłaty za zasoby magazynu używane przez wynikowy nowy obiekt blob. Dwa obiekty blob o różnych nazwach 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