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 |  |
| NFS |  |
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.