Återställa container

Operationen Restore Container återställer innehållet och egenskaperna hos en mjukt raderad container till en specificerad container. Funktionen Restore Container finns tillgänglig i version 2019-12-12 och senare.

Request

Du kan konstruera förfrågan Restore Container genom att använda en giltig förfrågan, auktoriserad genom delad nyckel, kontodelad åtkomstsignaturauktorisation eller rollbaserad åtkomstkontroll.

Method	Begäran om URI	HTTP-version
`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

URI parametrar

Du kan ange följande ytterligare parametrar på begärande-URI:n.

Parameter	Description
`restype`	Required. Parametervärdet `restype` måste vara `container`.
`comp`	Required. Parametervärdet `comp` måste vara `undelete`.
`timeout`	Optional. Parametern `timeout` uttrycks i sekunder. Mer information finns i Ange tidsgränser för Blob Storage-åtgärder.

Förfrågningsrubriker

I följande tabell beskrivs obligatoriska och valfria begärandehuvuden.

Förfrågningshuvudrad	Description
`Authorization`	Required. Anger auktoriseringsschema, kontonamn och signatur. Mer information finns i Auktorisera begäranden till Azure Storage.
`Date or x-ms-date`	Required. Anger UTC (Coordinated Universal Time) 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. Anger vilken version av åtgärden som ska användas för den här begäran. För denna operation måste versionen vara `2018-03-28` eller senare. Mer information finns i Versionshantering för Azure Storage-tjänsterna.
`x-ms-client-request-id`	Optional. Tillhandahåller ett klientgenererat, täckande värde med en kibibytesteckengräns (KiB) som registreras i loggarna när loggningen konfigureras. 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. Mer information finns i Övervaka Azure Blob Storage-.
`x-ms-deleted-container-name`	Required. Du använder denna header för att unikt identifiera den mjukt raderade behållaren som ska återställas.
`x-ms-deleted-container-version`	Required. Du använder denna header för att unikt identifiera den mjukt raderade behållaren som ska återställas. Du kan få detta värde genom att specificera `deleted` värdet i frågeparametern `include` för operationen `List Containers` . För mer information, se List Containers.

Begär brödtext

None.

Response

Svaret innehåller en HTTP-statuskod och en uppsättning svarshuvuden.

Statuskod

En lyckad åtgärd returnerar statuskoden 201 (skapad). Information om statuskoder finns i Status och felkoder.

Svarsrubriker

Svaret för den här åtgärden innehåller följande rubriker. Svaret kan också innehålla ytterligare standard-HTTP-huvuden. Alla standardhuvuden överensstämmer med HTTP/1.1-protokollspecifikationen.

Svarsrubrik	Description
`x-ms-request-id`	Identifierar unikt den begäran som gjordes och kan användas för felsökning. Mer information finns i Felsökning av API-åtgärder.
`x-ms-version`	Version 2009-09-19 och senare. Anger vilken version av Azure Blob Storage som används för att köra förfrågan.
`Date`	Ett UTC-datum/tid-värde som anger den tid då svaret initierades. Tjänsten genererar det här värdet.
`Content-Length`	Längden på begärandetexten. För denna operation är innehållets längd alltid noll.

Svarsdel

None.

Exempelsvar

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

Authorization

Auktorisation krävs när du anropar någon dataåtkomstoperation i Azure Storage. Du kan godkänna operationen Restore Container enligt beskrivningen i följande avsnitt.

Important

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 av 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äkerhetsprincipen kan vara en användar-, grupp-, applikationstjänsteprincipal eller Azure-hanterad identitet. Säkerhetsprincipen 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 Storage.

För att lära dig mer om auktorisation genom att använda Microsoft Entra ID, se Auktorisera åtkomst till blobs med Microsoft Entra ID.

Behörigheter

Följande RBAC-åtgärder är nödvändiga för att en Microsoft Entra-användare, grupp, hanterad identitet eller tjänstehuvudperson ska kunna anropa operationenRestore Container, samt den minst privilegierade inbyggda Azure RBAC-rollen som inkluderar denna åtgärd:

Azure RBAC-åtgärd: Microsoft. Lagring/lagringKonton/blobTjänster/behållare/skriv
Minst privilegierad inbyggd roll: Storage Blob Data Contributor

För att lära dig mer om hur man tilldelar roller med Azure RBAC, se Tilldela en Azure-roll för åtkomst till blobdata.

En signatur för delad åtkomst (SAS) ger säker delegerad åtkomst till resurser i ett lagringskonto. Med en SAS har du detaljerad kontroll över hur en klient kan komma åt data. Du kan specificera vilken resurs klienten kan komma åt, vilka behörigheter de har för dessa resurser och hur länge SAS:en är gyldig.

Operationen Restore Container stödjer auktorisering endast med ett konto som SAS. Service SAS och användardelegerings-SAS stöds inte för denna operation.

När åtkomst till delad nyckel inte tillåts för lagringskontot tillåts inte en SAS-token för kontot på en begäran till Blob Storage. Mer information finns i Förstå hur nekande av delad nyckel påverkar SAS-token.

Konto SAS

Ett SAS-konto skyddas med lagringskontonyckeln. Ett SAS-konto delegerar åtkomst till resurser i en eller flera av lagringstjänsterna. Alla operationer som är tillgängliga via ett tjänst-SAS eller ett SAS för användardelegering är också tillgängliga via ett konto-SAS.

Följande tabell visar den signerade resurstypen och signerade behörigheter för att ange när du delegerar åtkomst:

Operation	Signerad tjänst	Signerad resurstyp	Signerad behörighet
Återställa container	Blobben (b)	Behållare (c)	Skriv (w)

Mer information om sas-kontot finns i Skapa ett KONTO SAS-.

Remarks

Du kan ställa in container-borttagningspolicyn på kontot genom att använda Storage Resource Provider.
Den angivna behållaren får inte existera vid tidpunkten för Restore Container operationen.
Om den angivna behållaren finns, kommer operationen Restore Container att misslyckas med en 409 (Konflikt).
Om den mjukt raderade containern inte existerar, redan har använts som källa för en Restore Container operation, eller har överskridit sina lagringsdagar, kommer operationen att misslyckas med en 409 (Konflikt).

Billing

Prisbegäranden kan komma från klienter som använder Blob Storage-API:er, antingen direkt via BLOB Storage REST API eller från ett Azure Storage-klientbibliotek. Dessa begäranden ackumulerar avgifter per transaktion. Typen av transaktion påverkar hur kontot debiteras. Lästransaktioner ackumuleras till exempel till en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Restore Container begäranden baserat på lagringskontotypen:

Operation	Typ av lagringskonto	Faktureringskategori
Återställa container	Premiumblockblob Standard för allmän användning v2 Standard allmän användning v1	Lista och skapa containeråtgärder

Mer information om priser för den angivna faktureringskategorin finns i Prissättning för Azure Blob Storage.

Uppdaterades senast 2026-11-05