Restaurer un conteneur

Article
05/15/2024

L’opération Restore Container restaure le contenu et les propriétés d’un conteneur supprimé de manière réversible dans un conteneur spécifié. L’opération Restore Container est disponible sur version 2019-12-12 et versions ultérieures.

Requête

Vous pouvez construire la demande à l’aide Restore Container d’une requête valide, autorisée à l’aide d’une clé partagée, d’une autorisation de signature d’accès partagé de compte ou d’un contrôle d’accès en fonction du rôle.

Méthode	URI de demande	Version 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

Paramètres URI

Vous pouvez spécifier les paramètres supplémentaires suivants sur l’URI de requête.

Paramètre	Description
`restype`	Obligatoire. La valeur du `restype` paramètre doit être `container`.
`comp`	Obligatoire. La valeur du `comp` paramètre doit être `undelete`.
`timeout`	facultatif. Le paramètre `timeout` est exprimé en secondes. Pour plus d’informations, consultez Définition de délais d’expiration pour les opérations de stockage Blob.

En-têtes de requête

Le tableau suivant décrit les en-têtes de demande obligatoires ou facultatifs.

En-tête de requête	Description
`Authorization`	Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
`Date or x-ms-date`	Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
`x-ms-version`	Obligatoire pour toutes les demandes autorisées. Spécifie la version de l'opération à utiliser pour cette demande. Pour cette opération, la version doit être `2018-03-28` ou ultérieure. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
`x-ms-client-request-id`	facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (Kio) enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes reçues par le serveur. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.
`x-ms-deleted-container-name`	Obligatoire. Vous utilisez cet en-tête pour identifier de manière unique le conteneur supprimé de manière réversible qui doit être restauré.
`x-ms-deleted-container-version`	Obligatoire. Vous utilisez cet en-tête pour identifier de manière unique le conteneur supprimé de manière réversible qui doit être restauré. Vous pouvez obtenir cette valeur en spécifiant la `deleted` valeur dans le `include` paramètre de requête de l’opération `List Containers` . Pour plus d’informations, consultez Répertorier les conteneurs.

Corps de la demande

Aucun.

response

La réponse inclut un code d'état HTTP et un ensemble d'en-têtes de réponse.

Code d’état

Une opération réussie renvoie le code d'état 201 (Créé). Pour plus d’informations sur les codes status, consultez État et codes d’erreur.

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

En-tête de réponse	Description
`x-ms-request-id`	Identifie de manière unique la demande qui a été effectuée et peut être utilisée pour la résolution des problèmes de la demande. Pour plus d’informations, consultez Résolution des problèmes liés aux opérations d’API.
`x-ms-version`	Version 2009-09-19 et ultérieures. Indique la version de Stockage Blob Azure utilisée pour exécuter la demande.
`Date`	Valeur de date/heure UTC qui indique l’heure à laquelle la réponse a été lancée. Le service génère cette valeur.
`Content-Length`	Longueur du corps de la demande. Pour cette opération, la longueur du contenu est toujours égale à zéro.

Response body

Aucun.

Exemple de réponse

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

Autorisation

L’autorisation est requise lorsque vous appelez une opération d’accès aux données dans Stockage Azure. Vous pouvez autoriser l’opération Restore Container comme décrit dans les sections suivantes.

Important

Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour autoriser les demandes à Stockage Azure. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée.

Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les demandes de données blob. Avec Microsoft Entra ID, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête sur stockage Blob.

Pour en savoir plus sur l’autorisation à l’aide de Microsoft Entra ID, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.

Autorisations

Les actions RBAC suivantes sont nécessaires pour qu’un utilisateur, un groupe, une identité managée ou un principal de service Microsoft Entra appelle l’opérationRestore Container, et le rôle RBAC azure intégré le moins privilégié qui inclut cette action :

Action RBAC Azure : Microsoft.Storage/storageAccounts/blobServices/containers/write
Rôle intégré le moins privilégié : Contributeur aux données blob de stockage

Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour accéder aux données d’objets blob.

Une signature d’accès partagé (SAP) fournit un accès délégué sécurisé aux ressources d’un compte de stockage. Avec une SAP, vous disposez d’un contrôle granulaire sur la façon dont un client peut accéder aux données. Vous pouvez spécifier la ressource à laquelle le client peut accéder, les autorisations dont il dispose sur ces ressources et la durée de validité de la SAP.

L’opération Restore Container prend en charge l’autorisation à l’aide d’une sape de compte.

Lorsque l’accès à la clé partagée est interdit pour le compte de stockage, un jeton SAP de compte n’est pas autorisé lors d’une demande adressée au stockage Blob. Pour plus d’informations, consultez Comprendre comment l’interdiction de la clé partagée affecte les jetons SAP.

SAP de compte

Une SAP de compte est sécurisée à l’aide de la clé de compte de stockage. Une SAP de compte délègue l’accès aux ressources d’un ou plusieurs des services de stockage. Toutes les opérations disponibles via une SAP de service ou de délégation d’utilisateur sont également disponibles via une SAP de compte.

Le tableau suivant indique le type de ressource signé et les autorisations signées à spécifier lorsque vous déléguez l’accès :

Opération	Service signé	Type de ressource signé	Autorisation signée
Restaurer un conteneur	Blob (b)	Conteneur (c)	Écriture (w)

Pour en savoir plus sur la SAP de compte, consultez Create une SAP de compte.

L’opération Restore Container prend en charge l’autorisation de clé partagée. Nous vous déconseillons d’autoriser avec des clés de compte dans la plupart des scénarios, car elle est moins sécurisée.

Nous vous recommandons d’interdire l’autorisation de clé partagée pour le compte de stockage lorsque cela est possible. Pour plus d’informations, consultez Empêcher l’autorisation avec une clé partagée.

Remarques

Vous pouvez définir la stratégie de rétention de suppression de conteneur sur le compte à l’aide du fournisseur de ressources de stockage.
Le conteneur spécifié ne doit pas exister au moment où l’opération Restore Container est effectuée.
Si le conteneur spécifié existe, l’opération Restore Container échoue avec un 409 (Conflit).
Si le conteneur supprimé de manière réversible n’existe pas, a déjà été utilisé comme source d’une Restore Container opération ou a dépassé ses jours de rétention, l’opération échoue avec un 409 (Conflit).

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent les API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à partir d’une bibliothèque cliente stockage Azure. Ces demandes accumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture s’accumulent dans une catégorie de facturation différente de celle des transactions d’écriture. Le tableau suivant montre la catégorie de facturation pour Restore Container les demandes en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Restaurer un conteneur	Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard	Répertorier et Create opérations de conteneur

Pour en savoir plus sur la tarification de la catégorie de facturation spécifiée, consultez tarification Stockage Blob Azure.

Partager via