Partager via


Restaurer le partage

L’opération Restore Share restaure (ou annule la suppression) d’un partage précédemment supprimé de manière réversible. Cette API est entièrement prise en charge, mais il s’agit d’une API de gestion héritée. Utilisez plutôt Partages de fichiers - Restauration, fournis par le fournisseur de ressources de stockage (Microsoft.Storage). Pour en savoir plus sur l’interaction programmatique avec FileShare les ressources à l’aide du fournisseur de ressources de stockage, consultez Operations on FileShares.

Le partage est restauré avec toutes ses données, métadonnées et instantanés. La ressource de partage inclut des métadonnées et des propriétés pour le partage.

Disponibilité du protocole

Protocole de partage de fichiers activé Disponible
SMB Oui
NFS Non

Requête

Vous pouvez construire la Restore Share requête comme suit. HTTPS est recommandé.

Méthode URI de demande Version HTTP
PUT https://myaccount.file.core.windows.net/restoredShareName?restype=share&comp=undelete HTTP/1.1

Remplacez les composants du chemin indiqués dans l'URI de la demande par les vôtres, comme suit :

Composant Chemin d’accès Description
myaccount nom de votre compte de stockage.
restoredShareName Nom à utiliser pour le partage restauré. Si un partage existe déjà avec ce nom, l’opération échoue.

Pour plus d’informations sur les restrictions de nommage de chemin d’accès, consultez Nommer et référencer des partages, des répertoires, des fichiers et des métadonnées.

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 Azure Files.

En-têtes de requête

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

En-tête de requête Description
Authorization Obligatoire. Spécifie le schéma d'authentification, le nom du compte et la signature. Pour plus d’informations, consultez Authentification pour les services stockage Azure.
x-ms-date Obligatoire. Spécifie l'heure UTC (temps universel coordonné) pour la demande. Pour plus d’informations, consultez Authentification pour les services stockage Azure.
x-ms-version Obligatoire pour toutes les demandes authentifié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-deleted-share-name Obligatoire. Identifie le partage de fichiers supprimé de manière réversible à restaurer. Cette valeur doit correspondre à la valeur de restoredShareName.
x-ms-deleted-share-version Obligatoire. Identifie de manière unique le partage de fichiers supprimé de manière réversible par sa version.
x-ms-client-request-id Optionnel. 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.

Exemple de requête

PUT https://myaccount.file.core.windows.net/myshare?restype=share&comp=undelete HTTP/1.1   

Request Headers:  
x-ms-version: 2019-12-12   
x-ms-deleted-share-name: myshare 
x-ms-deleted-share-version: 01D2AC0C18EDFE36   
Authorization: SharedKey myaccount:Z5043vY9MesKNh0PNtksNc9nbXSSqGHueE00JdjidOQ= 

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éé). Si le nom du partage de fichiers de destination est utilisé par un partage de fichiers non supprimé valide, la demande échoue avec un 409 (Conflit). Si le partage de fichiers source n’est pas supprimé de manière réversible, s’il a déjà été restauré ou si le partage de fichiers source a passé sa période de rétention et a expiré, la demande échoue avec une valeur 404 (introuvable).

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
ETag Contient une valeur qui représente la version du partage, entre guillemets.
Last-Modified Renvoie la date et l'heure de la dernière modification du partage. Pour plus d’informations, consultez Représentation des valeurs de date-heure dans les en-têtes.

Toute opération qui modifie le partage, ses propriétés ou métadonnées, met à jour l’heure de la dernière modification. Les opérations sur les fichiers n’affectent pas l’heure de dernière modification du partage.
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 Indique la version de Azure Files 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 Peut être utilisé pour résoudre les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de x-ms-client-request-id header, s’il est présent dans la demande. La valeur est au maximum de 1 024 caractères ASCII visibles. Si le x-ms-client-request-id header n’est pas présent dans la demande, il ne sera pas présent dans la réponse.

Response body

Aucun.

Exemple de réponse

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
x-ms-request-id: 78c46801-f01a-0089-31fb-486017000000 
x-ms-version: 2019-12-12   
Content-Length: 0 
Date: <date>   
ETag: "0x8CB14C3E29B7E82"   
Last-Modified: <date>   
Server: Windows-Azure-File/1.0 Microsoft-HTTPAPI/2.0 

Autorisation

Le propriétaire du compte de stockage peut appeler cette opération. En outre, les utilisateurs disposant de jetons de signature d’accès partagé de compte valides peuvent appeler cette opération. Le jeton doit inclure des autorisations d’écriture pour la ressource conteneur pour autoriser cette opération.

Notes

Vous ne pouvez pas restaurer un partage sous un autre nom. Lorsque vous restaurez un partage, s’il existe un autre partage portant le même nom, l’opération échoue avec status code 409 (Conflit). Le partage portant le même nom doit d’abord être supprimé avant que le partage supprimé de manière réversible ne puisse être supprimé.

Lorsqu’un partage est supprimé, un partage portant le même nom ne peut pas être restauré pendant au moins 30 secondes. Pendant la suppression du partage, les tentatives de restauration d’un partage du même nom échouent avec status code 409 (Conflit). Le service retourne des informations d’erreur supplémentaires, indiquant que le partage est en cours de suppression.

Voir aussi

Opérations sur les partages (Azure Files)