Przywracanie kontenera

Artykuł
05/15/2024

Operacja Restore Container przywraca zawartość i właściwości kontenera usuniętego nietrwale do określonego kontenera. Operacja Restore Container jest dostępna w wersji i nowszych 2019-12-12 wersjach.

Żądanie

Żądanie można utworzyć Restore Container przy użyciu prawidłowego żądania, autoryzowanego przy użyciu klucza wspólnego, autoryzacji sygnatury dostępu współdzielonego konta lub kontroli dostępu opartej na rolach.

Metoda	Identyfikator URI żądania	Wersja PROTOKOŁU HTTP
`PUT`	`https://myaccount.blob.core.windows.net/destinationcontainer?restype=container&comp=undelete`	HTTP/1.1
`PUT`	`https://myaccount.blob.core.windows.net/destinationcontainer?restype=container&comp=undelete&sv=validsastoken`	HTTP/1.1

Parametry identyfikatora URI

Dla identyfikatora URI żądania można określić następujące dodatkowe parametry.

Parametr	Opis
`restype`	Wymagane. Wartość parametru `restype` musi mieć wartość `container`.
`comp`	Wymagane. Wartość parametru `comp` musi mieć wartość `undelete`.
`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 or 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ń. Określa wersję operacji do użycia dla tego żądania. W przypadku tej operacji wersja musi być `2018-03-28` lub nowsza. Aby uzyskać więcej informacji, zobacz Przechowywanie wersji dla usług Azure Storage.
`x-ms-client-request-id`	Opcjonalny. Zapewnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-kibibyte (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. Aby uzyskać więcej informacji, zobacz Monitorowanie Azure Blob Storage.
`x-ms-deleted-container-name`	Wymagane. Ten nagłówek służy do unikatowego identyfikowania kontenera usuniętego nietrwale, który należy przywrócić.
`x-ms-deleted-container-version`	Wymagane. Ten nagłówek służy do unikatowego identyfikowania kontenera usuniętego nietrwale, który należy przywrócić. Tę wartość można uzyskać, określając `deleted` wartość w parametrze `includeList Containers` zapytania operacji. Aby uzyskać więcej informacji, zobacz List Containers (Wyświetlanie listy kontenerów).

Treść żądania

Brak.

Reakcja

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

Kod stanu

Pomyślna operacja 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
`x-ms-request-id`	Unikatowo identyfikuje żądanie, które zostało wykonane i może 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`	Wersja 2009-09-19 lub nowsza. Wskazuje wersję Azure Blob Storage używaną do uruchamiania żądania.
`Date`	Wartość daty/godziny UTC wskazująca godzinę, o której zainicjowano odpowiedź. Usługa generuje tę wartość.
`Content-Length`	Długość treści żądania. W przypadku tej operacji długość zawartości jest zawsze równa zero.

Treść odpowiedzi

Brak.

Przykładowa odpowiedź

Response Status:  
HTTP/1.1 201 OK  
  
Response Headers:  
Date: Mon, 15 Jun 2020 12:43:08 GMT  
x-ms-version: 2019-12-12  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
Content-Length: 0

Autoryzacja

Autoryzacja jest wymagana w przypadku wywoływania dowolnej operacji dostępu do danych w usłudze Azure Storage. Operację Restore Container można autoryzować zgodnie z opisem w poniższych sekcjach.

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ólnego.

Usługa Azure Storage obsługuje autoryzację żądań do danych obiektów blob przy użyciu Tożsamość Microsoft Entra. Dzięki Tożsamość Microsoft Entra możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby udzielić uprawnień podmiotowi zabezpieczeń. Podmiotem zabezpieczeń może być użytkownik, grupa, jednostka usługi aplikacji lub tożsamość zarządzana 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 Storage.

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

Następujące akcje kontroli dostępu opartej na rolach są niezbędne dla użytkownika Microsoft Entra, grupy, tożsamości zarządzanej lub jednostki usługi w celu wywołania Restore Container operacji oraz najmniej uprzywilejowanej wbudowanej roli RBAC platformy Azure, która obejmuje tę akcję:

Akcja RBAC platformy Azure: Microsoft.Storage/storageAccounts/blobServices/containers/write
Najmniej uprzywilejowana wbudowana rola: Współautor danych obiektu blob usługi Storage

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.

Sygnatura dostępu współdzielonego (SAS) zapewnia bezpieczny delegowany dostęp do zasobów na koncie magazynu. Dzięki sygnaturze dostępu współdzielonego masz szczegółową kontrolę nad sposobem uzyskiwania dostępu do danych przez klienta. Możesz określić zasób, do którego może uzyskiwać dostęp klient, jakie uprawnienia mają do tych zasobów i jak długo sygnatura dostępu współdzielonego jest prawidłowa.

Operacja Restore Container obsługuje autoryzację przy użyciu sygnatury dostępu współdzielonego konta.

Jeśli dostęp do klucza współużytkowanego jest niedozwolony dla konta magazynu, token SAS konta nie będzie dozwolony na żądanie do usługi Blob Storage. Aby dowiedzieć się więcej, zobacz Understand how dis disallowing Shared Key affects SAS tokens (Informacje o tym, jak uniemożliwić korzystanie z klucza współużytkowanego wpływa na tokeny SAS).

Sygnatura dostępu współdzielonego konta

Sygnatura dostępu współdzielonego konta jest zabezpieczona za pomocą klucza konta magazynu. Sygnatura dostępu współdzielonego konta deleguje dostęp do zasobu w co najmniej jednej usłudze magazynu. Wszystkie operacje dostępne za pośrednictwem sygnatury dostępu współdzielonego delegowania usługi lub użytkownika są również dostępne za pośrednictwem sygnatury dostępu współdzielonego konta.

W poniższej tabeli przedstawiono typ podpisanego zasobu i podpisane uprawnienia do określania, kiedy delegujesz dostęp:

Operacja	Podpisana usługa	Typ zasobu podpisanego	Podpisane uprawnienie
Przywracanie kontenera	Obiekt blob (b)	Kontener (c)	Zapis (w)

Aby dowiedzieć się więcej na temat sygnatury dostępu współdzielonego konta, zobacz Twórca sygnaturę dostępu współdzielonego konta.

Uwagi

Zasady przechowywania usuwania kontenera można ustawić na koncie przy użyciu dostawcy zasobów magazynu.
Określony kontener nie może istnieć w czasie Restore Container wykonywania operacji.
Jeśli określony kontener istnieje, Restore Container operacja zakończy się niepowodzeniem z błędem 409 (Konflikt).
Jeśli kontener usunięty nietrwale nie istnieje, został już użyty jako źródło Restore Container operacji lub przekroczył jego dni przechowywania, operacja zakończy się niepowodzeniem z 409 (konflikt).

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 Restore Container żądań na podstawie typu konta magazynu:

Operacja	Typ konta magazynu	Kategoria rozliczeń
Przywracanie kontenera	Blokowy obiekt blob w warstwie Premium Standardowa ogólnego przeznaczenia, wersja 2 Standardowa ogólnego przeznaczenia, wersja 1	Wyświetlanie listy i Twórca operacji kontenera

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

Udostępnij za pośrednictwem