Annuler la suppression d’un objet blob

L’opération Undelete Blob restaure le contenu et les métadonnées d’un objet blob supprimé de manière réversible, ainsi que tous les instantanés supprimés de manière réversible associés.

Undelete Blob est pris en charge uniquement sur la version 2017-07-29 ou ultérieure.

Requête

Vous pouvez construire la Undelete Blob requête comme suit. HTTPS est recommandé. Remplacez myaccount par le nom de votre compte de stockage.

URI de demande de méthode PUT	Version HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=undelete	HTTP/1.1

URI de service de stockage émulé

Lorsque vous effectuez une demande auprès du service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et Stockage Blob Azure port comme 127.0.0.1:10000, suivi du nom du compte de stockage émulé.

URI de demande de méthode PUT	Version HTTP
http://127.0.0.1:10000/ devstoreaccount1/mycontainer/myblob?comp=undelete	HTTP/1.1

Pour plus d’informations, consultez Utiliser l’émulateur Azurite pour le développement local de Stockage Azure.

Paramètres URI

Vous pouvez spécifier le paramètre supplémentaire suivant sur l’URI de demande.

Paramètre	Description
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 (tous les types d’objets blob)

Le tableau suivant décrit les en-têtes de requête obligatoires et facultatifs pour tous les types d’objets blob.

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 ou 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 plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
x-ms-undelete-source	facultatif. Version 2020-08-04 et ultérieures. Uniquement pour les comptes activés avec un espace de noms hiérarchique. Chemin d’accès de l’objet blob supprimé de manière réversible à annuler la suppression. Le format est blobPath?deletionid=<id>. Le compte et le nom du conteneur ne sont pas inclus dans le chemin d’accès. DeletionId est l’identificateur unique de l’objet blob supprimé de manière réversible. Vous pouvez le récupérer en listant les objets blob supprimés de manière réversible avec l’API REST pour les List Blobs comptes activés avec un espace de noms hiérarchique. Le chemin d’accès doit être encodé en pourcentage.
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.

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 envoie le code d'état 200 (OK). 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.

Syntaxe	Description
x-ms-request-id	Cet en-tête identifie de manière unique la demande qui a été effectuée et peut être utilisé 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	Indique la version du stockage Blob 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.
x-ms-client-request-id	Vous pouvez utiliser cet en-tête pour résoudre les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id , s’il est présent dans la demande. La valeur est au maximum de 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la requête, cet en-tête ne sera pas présent dans la réponse.

Response body

Aucun.

Autorisation

Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans Stockage Azure. Vous pouvez autoriser l’opération Undelete Blob comme décrit ci-dessous.

Microsoft Entra ID

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 auprès du service 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

Vous trouverez ci-dessous l’action RBAC nécessaire pour qu’un utilisateur, un groupe ou un principal de service Microsoft Entra appelle l’opérationUndelete Blob, ainsi que 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 l’accès aux données d’objets blob.

Signatures d’accès partagé (SAP)

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 Undelete Blob prend en charge trois types de signatures d’accès partagé : sas de délégation d’utilisateur, SAP de service et SAP de compte.

Comme meilleure pratique de sécurité, nous vous recommandons d’utiliser Microsoft Entra informations d’identification plutôt que la clé de compte de stockage, qui peut être plus facilement compromise. Si la conception de votre application nécessite des signatures d’accès partagé, utilisez Microsoft Entra informations d’identification pour créer une sap de délégation d’utilisateur, si possible.

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

SAP de délégation d’utilisateur

Une sap de délégation d’utilisateur est sécurisée avec des informations d’identification Microsoft Entra, ainsi que par les autorisations spécifiées pour la signature d’accès partagé.

L’appel de l’opération à l’aide Undelete Blob d’un jeton SAP délégué à une ressource de conteneur nécessite l’autorisation Write (w) dans le cadre du jeton SAP de délégation d’utilisateur.

Pour en savoir plus sur la SAP de délégation d’utilisateur, consultez Créer une SAP de délégation d’utilisateur.

SAP de service

Une SAP de service est sécurisée à l’aide de la clé de compte de stockage. Une SAP de service délègue l’accès à une ressource dans un seul service de stockage Azure, tel que le stockage d’objets blob.

L’appel de l’opération à l’aide Undelete Blob d’un jeton SAP délégué à une ressource de conteneur nécessite l’autorisation Write (w) dans le cadre du jeton SAP de service.

Pour en savoir plus sur la SAP de service, consultez Créer une SAP de service.

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 lors de la délégation de l’accès :

Opération	Service signé	Type de ressource signé	Autorisation signée
Annuler la suppression d’un objet blob	Blob (b)	Conteneur (c)	Écriture (w)

Pour en savoir plus sur la SAP de compte, consultez Créer une SAP de compte.

Clé partagée

L’opération Undelete Blob prend en charge l’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée pour la plupart des scénarios, car elle est moins sécurisée.

Microsoft recommande 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

Lorsque vous annulez la suppression d’un objet blob supprimé de manière réversible, l’objet blob et tous les instantanés associés sont disponibles pour les opérations à l’aide d’autres API. Lorsque vous annulez la suppression d’un objet blob qui n’est pas supprimé de manière réversible ou qui n’a pas d’instantanés supprimés de manière réversible, l’opération réussit sans aucune modification.

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 Undelete Blob les demandes en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Annuler la suppression d’un objet blob	Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard	Opérations d’écriture

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

Voir aussi

Autoriser les demandes dans le Stockage Azure
Codes d’état et d’erreurSupprimer l’objet blob