Przywracanie kontenera
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 skonstruować Restore Container
przy użyciu prawidłowego żądania autoryzowanego przy użyciu klucza współdzielonego, 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
W identyfikatorze 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 usług Azure Storage. |
x-ms-client-request-id |
Opcjonalny. Udostępnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-kibibyte (KiB), który jest rejestrowany 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 ma zostać przywrócony. |
x-ms-deleted-container-version |
Wymagane. Ten nagłówek służy do unikatowego identyfikowania kontenera usuniętego nietrwale, który ma zostać przywrócony. Tę wartość można uzyskać od określenia deleted wartości w parametrze include List Containers zapytania operacji. Aby uzyskać więcej informacji, zobacz Wyświetlanie listy kontenerów. |
Treść żądania
Brak.
Reakcja
Odpowiedź zawiera kod stanu HTTP i zestaw nagłówków odpowiedzi.
Kod stanu
Operacja zakończona powodzeniem 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 |
---|---|
x-ms-request-id |
Jednoznacznie identyfikuje żądanie, które zostało wykonane i może być używane 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żytą do uruchomienia żądania. |
Date |
Wartość daty/godziny UTC wskazująca godzinę, w 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 podczas 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.
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żna następnie 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 RBAC są niezbędne do Microsoft Entra użytkownika, grupy 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
- Rola wbudowana z najmniejszymi uprawnieniami: 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.
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 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 cenowe 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 do 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 tworzenie operacji kontenera |
Aby dowiedzieć się więcej o cenach dla określonej kategorii rozliczeń, zobacz Azure Blob Storage Cennik.