Container herstellen

De Restore Container bewerking herstelt de inhoud en eigenschappen van een voorlopig verwijderde container naar een opgegeven container. De Restore Container bewerking is beschikbaar op versie 2019-12-12 en hoger.

Aanvraag

U kunt de Restore Container aanvraag samenstellen met behulp van een geldige aanvraag, geautoriseerd met behulp van een gedeelde sleutel, autorisatie van gedeelde toegangshandtekening voor accounts of op rollen gebaseerd toegangsbeheer.

Methode	Aanvraag-URI	HTTP-versie
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-parameters

U kunt de volgende aanvullende parameters opgeven voor de aanvraag-URI.

Parameter	Beschrijving
restype	Vereist. De restype parameterwaarde moet zijn container.
comp	Vereist. De comp parameterwaarde moet zijn undelete.
timeout	Optioneel. De timeout parameter wordt uitgedrukt in seconden. Zie Time-outs instellen voor Blob Storage-bewerkingen voor meer informatie.

Aanvraagheaders

In de volgende tabel worden vereiste en optionele aanvraagheaders beschreven.

Aanvraagheader	Beschrijving
Authorization	Vereist. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening. Zie Aanvragen voor Azure Storage autoriseren voor meer informatie.
Date or x-ms-date	Vereist. Geef de Coordinated Universal Time (UTC) op voor de aanvraag. Zie Aanvragen voor Azure Storage autoriseren voor meer informatie.
x-ms-version	Vereist voor alle geautoriseerde aanvragen. Hiermee geeft u de versie van de bewerking te gebruiken voor deze aanvraag. Voor deze bewerking moet de versie of hoger zijn 2018-03-28 . Zie Versiebeheer voor de Azure Storage-services voor meer informatie.
x-ms-client-request-id	Optioneel. Biedt een door de client gegenereerde, ondoorzichtige waarde met een limiet van 1 kibibyte (KiB) die wordt vastgelegd in de logboeken wanneer logboekregistratie is geconfigureerd. We raden u ten zeerste aan deze header te gebruiken om activiteiten aan de clientzijde te correleren met aanvragen die de server ontvangt. Zie Azure Blob Storage bewaken voor meer informatie.
x-ms-deleted-container-name	Vereist. U gebruikt deze header om de voorlopig verwijderde container te identificeren die moet worden hersteld.
x-ms-deleted-container-version	Vereist. U gebruikt deze header om de voorlopig verwijderde container te identificeren die moet worden hersteld. U kunt deze waarde verkrijgen door de deleted waarde op te geven in de include queryparameter van de List Containers bewerking. Zie Containers weergeven voor meer informatie.

Aanvraagbody

Geen.

Antwoord

Het antwoord bevat een HTTP-statuscode en een set antwoordheaders.

Statuscode

Een geslaagde bewerking retourneert statuscode 201 (gemaakt). Zie Status- en foutcodes voor meer informatie over statuscodes.

Antwoordheaders

Het antwoord voor deze bewerking bevat de volgende headers. Het antwoord kan ook extra, standaard HTTP-headers bevatten. Alle standaardheaders voldoen aan de HTTP/1.1-protocolspecificatie.

Antwoordheader	Description
x-ms-request-id	Uniek identificeert de aanvraag die is gedaan en kan worden gebruikt voor het oplossen van problemen met de aanvraag. Zie Problemen met API-bewerkingen oplossen voor meer informatie.
x-ms-version	Versie 2009-09-19 en hoger. Geeft de versie van Azure Blob Storage gebruikt om de aanvraag uit te voeren.
Date	Een UTC-datum/tijd-waarde die de tijd aangeeft waarop het antwoord is gestart. De service genereert deze waarde.
Content-Length	De lengte van de aanvraagtekst. Voor deze bewerking is de lengte van de inhoud altijd nul.

Hoofdtekst van de reactie

Geen.

Voorbeeldantwoord

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  

Autorisatie

Autorisatie is vereist wanneer u een bewerking voor gegevenstoegang in Azure Storage aanroept. U kunt de Restore Container bewerking autoriseren zoals beschreven in de volgende secties.

Belangrijk

Microsoft raadt aan Microsoft Entra ID met beheerde identiteiten te gebruiken om aanvragen voor Azure Storage te autoriseren. Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak in vergelijking met autorisatie van gedeelde sleutels.

Microsoft Entra ID (aanbevolen)

Azure Storage ondersteunt het gebruik van Microsoft Entra ID om aanvragen voor blobgegevens te autoriseren. Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipal. De beveiligingsprincipal kan een gebruiker, groep, toepassingsservice-principal of door Azure beheerde identiteit zijn. De beveiligingsprincipal wordt geverifieerd door Microsoft Entra ID om een OAuth 2.0-token te retourneren. Het token kan vervolgens worden gebruikt om een aanvraag voor Blob Storage te autoriseren.

Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra ID voor meer informatie over autorisatie met behulp van Microsoft Entra ID.

Machtigingen

De volgende RBAC-acties zijn nodig voor een Microsoft Entra gebruiker, groep, beheerde identiteit of service-principal om de Restore Container bewerking aan te roepen, en de ingebouwde Azure RBAC-rol met de minste bevoegdheden die deze actie omvat:

• Azure RBAC-actie: Microsoft.Storage/storageAccounts/blobServices/containers/write
• Ingebouwde rol met minimale bevoegdheden: Inzender voor opslagblobgegevens

Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.

Handtekeningen voor gedeelde toegang

Een Shared Access Signature (SAS) biedt beveiligde gedelegeerde toegang tot resources in een opslagaccount. Met een SAS hebt u gedetailleerde controle over hoe een client toegang heeft tot gegevens. U kunt opgeven tot welke resource de client toegang heeft, welke machtigingen ze hebben voor deze resources en hoe lang de SAS geldig is.

De Restore Container bewerking ondersteunt autorisatie met behulp van een account-SAS.

Wanneer gedeelde sleuteltoegang niet is toegestaan voor het opslagaccount, wordt een SAS-accounttoken niet toegestaan voor een aanvraag voor Blob Storage. Zie Begrijpen hoe het niet toewijzen van gedeelde sleutel van invloed is op SAS-tokens voor meer informatie.

Account-SAS

Een account-SAS wordt beveiligd met de sleutel van het opslagaccount. Een account-SAS delegeert toegang tot resources in een of meer van de opslagservices. Alle bewerkingen die beschikbaar zijn via een service- of gebruikersdelegatie-SAS zijn ook beschikbaar via een account-SAS.

In de volgende tabel ziet u het ondertekende resourcetype en de ondertekende machtigingen die moeten worden opgegeven wanneer u toegang delegeert:

Bewerking	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Container herstellen	Blob (b)	Container (c)	Schrijven (w)

Zie een account-SAS Creatie voor meer informatie over de account-SAS.

Gedeelde sleutel

De Restore Container bewerking ondersteunt autorisatie van gedeelde sleutels. Het is niet raadzaam om voor de meeste scenario's te autoriseren met accountsleutels, omdat dit minder veilig is.

U wordt aangeraden waar mogelijk de autorisatie van een gedeelde sleutel voor het opslagaccount ongedaan te maken. Zie Autorisatie met gedeelde sleutel voorkomen voor meer informatie.

Opmerkingen

• U kunt het bewaarbeleid voor het verwijderen van containers voor het account instellen met behulp van de opslagresourceprovider.
• De opgegeven container mag niet bestaan op het moment dat de Restore Container bewerking wordt uitgevoerd.
• Als de opgegeven container bestaat, mislukt de Restore Container bewerking met een 409 (conflict).
• Als de voorlopig verwijderde container niet bestaat, al is gebruikt als de bron van een Restore Container bewerking of de retentiedagen heeft overschreden, mislukt de bewerking met een 409 (conflict).

Billing

Prijsaanvragen kunnen afkomstig zijn van clients die gebruikmaken van Blob Storage-API's, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Met deze aanvragen worden kosten per transactie in rekening gebracht. Het type transactie is van invloed op de manier waarop de rekening in rekening wordt gebracht. Leestransacties worden bijvoorbeeld toegevoegd aan een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Restore Container aanvragen op basis van het type opslagaccount:

Bewerking	Type opslagaccount	Factureringscategorie
Container herstellen	Premium-blok-blob Standard v2 voor algemeen gebruik Standard v1 voor algemeen gebruik	Containerbewerkingen weergeven en Creatie

Zie prijzen voor Azure Blob Storage voor meer informatie over prijzen voor de opgegeven factureringscategorie.