Partager via

Restaurer un conteneur

  • Article

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 :

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.

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.