Tutoriel : Restaurer un jeu de données sismique à un moment antérieur

Utilisez l’opération de restauration Seismic DDMS dans Azure Data Manager for Energy pour restaurer un ensemble de données sismique à un moment antérieur. L’opération restaure à la fois les métadonnées du jeu de données et les données blobs associées à l’état existant à l’horodatage que vous spécifiez. Cette opération peut aider à récupérer un jeu de données après une mise à jour ou suppression involontaire, à condition qu’une version restaurable soit toujours disponible dans la période fixe de rétention de 30 jours.

Dans ce tutoriel, vous allez apprendre à :

Prerequisites

Avant de commencer, veillez à respecter les conditions préalables suivantes :

• Une ressource SKU Azure Data Manager for Energy Standard avec la prévisualisation de restauration Seismic DDMS activée.
• tenant Inscrit et subproject dans le service DDMS sismique.
• Rôle subproject.admin attribué à votre compte d’utilisateur.
• Jeton d'accès pour l’authentification de l’API. Découvrez comment générer un jeton d’authentification.
• Le sdPath jeu de données sismique que vous souhaitez restaurer.
• Un point de restauration dans la période fixe de rétention de 30 jours. La période de rétention n’est pas configurable.

Restauration des opérations API

Le flux de restauration utilise deux opérations API :

Choisissez un point de restauration

La restorePointInTime valeur identifie l’état à restaurer. Spécifiez la valeur comme un horodatage ISO 8601 UTC, par exemple, 2026-07-10T08:30:00.000Z.

Le point de restauration doit répondre à toutes les exigences suivantes :

• C’est du passé.
• C’est dans la période fixe de 30 jours de rétention de restauration.
• C’est plus tard que le moment de création du jeu de données.

Choisissez un horodatage juste avant la mise à jour ou la suppression involontaire. L’état restauré n’inclut aucun changement de jeu de données effectué après l’horodatage sélectionné.

Lancer une opération de restauration

Avant de soumettre la demande, arrêtez les opérations d’écriture et de suppression sur le jeu de données. L’opération de restauration verrouille le jeu de données pendant qu’elle restaure les métadonnées et les données de blob.

1. Soumettez une requête POST au point de terminaison de restauration. Il sdPath doit identifier un seul ensemble de données, et non un répertoire :

   POST <instance>.energy.azure.com/seistore-svc/api/v3/operation/restore
   Authorization: Bearer <access_token>
   data-partition-id: <data_partition_id>
   Content-Type: application/json
   
   {
     "sdPath": "sd://<tenant>/<subproject>/<path>/<dataset_name>",
     "restorePointInTime": "2026-07-10T08:30:00.000Z"
   }
   

2. Épargnez le operation_id ou statusUrl de la 202 Accepted réponse. Vous avez besoin de l’une de ces valeurs pour surveiller le fonctionnement :

   {
     "operation_id": "c3d282e6-e7d1-40d8-8ac2-edc15b6d174c",
     "statusUrl": "/seistore-svc/api/v3/operation/restore/c3d282e6-e7d1-40d8-8ac2-edc15b6d174c"
   }
   

Surveillez l’opération de restauration

Interrogez le point de terminaison d’état pour suivre la restauration asynchrone.

1. Envoyez une demande GET avec le operation_id:

   GET <instance>.energy.azure.com/seistore-svc/api/v3/operation/restore/<operation_id>
   Authorization: Bearer <access_token>
   data-partition-id: <data_partition_id>
   

2. Vérifiez le status champ dans la réponse. L’opération peut se déplacer à travers Enqueued et InProgress avant d’atteindre un état terminal.

   {
     "operationId": "c3d282e6-e7d1-40d8-8ac2-edc15b6d174c",
     "status": "InProgress",
     "sdPath": "sd://opendes/test-subproject/surveys/dataset1",
     "restorePointInTime": "2026-07-10T08:30:00.000Z",
     "tenant": "opendes",
     "subproject": "test-subproject",
     "createdBy": "00000000-0000-0000-0000-000000000000",
     "startedAt": "2026-07-15T10:00:00.000Z",
     "lastUpdatedAt": "2026-07-15T10:00:05.000Z"
   }
   

3. Arrêtez la sondation lorsque status est l’une des valeurs terminales suivantes :

   État	Description
   Succeeded	Les métadonnées du jeu de données et les données blobs ont été restaurées au moment sélectionné.
   Failed	La restauration a commencé mais n’a pas pu être terminée. Critique errorDetails la cause.
   Rejected	Le service n’a pas pu lancer la restauration, par exemple parce que le jeu de données était verrouillé ou qu’aucun état restaurable n’était disponible. Critique errorDetails la cause.

   L’exemple suivant montre une restauration rejetée :

   {
     "operationId": "c3d282e6-e7d1-40d8-8ac2-edc15b6d174c",
     "status": "Rejected",
     "sdPath": "sd://opendes/test-subproject/surveys/dataset1",
     "restorePointInTime": "2026-07-10T08:30:00.000Z",
     "createdBy": "00000000-0000-0000-0000-000000000000",
     "errorDetails": "Restore rejected: the dataset is currently locked by another in-progress write operation. Wait for that operation to finish and release the lock, then retry this restore.",
     "lastUpdatedAt": "2026-07-15T10:00:07.000Z",
     "completedAt": "2026-07-15T10:00:07.000Z"
   }
   

Après le succès de l’opération, récupérez ou téléchargez le jeu de données et confirmez que ses métadonnées et son contenu correspondent à l’état attendu.

Limitations et considérations

Prenez en compte les limitations suivantes avant de commencer une restauration :

• Un seul jeu de données — Chaque requête restaure un ensemble de données. Vous ne pouvez pas spécifier un répertoire, restaurer chaque jeu de données sous un chemin, ou soumettre plusieurs ensembles de données dans une seule requête.
• Une fenêtre de conservation fixe s’applique — Vous ne pouvez pas restaurer à un horodatage en dehors de la période de rétention de 30 jours. La période de rétention n’est pas configurable et ne peut pas être annulée dans la requête.
• Une restauration par partition de données — Une seule opération de restauration peut s’exécuter dans une partition de données à la fois, même si une autre requête cible un autre jeu de données. Une requête concurrente renvoie 409 Conflict.
• La restauration est asynchrone — une 202 Accepted réponse n’est pas une confirmation du succès. Vous devez interroger le point de terminaison d’état.
• Les écritures doivent être mises en pause — Un verrouillage d’écriture actif peut entraîner le rejet de l’opération. Ne mettez pas à jour ni ne supprimez le jeu de données tant que la restauration n’a pas atteint un état terminal.
• L’état actuel est remplacé — Une restauration réussie fait de la version historique sélectionnée l’état actuel du jeu de données. Les mises à jour effectuées après le point de restauration ne sont pas présentes dans la version restaurée.
• La disponibilité des fonctionnalités est limitée — L’opération de restauration est une fonctionnalité d’aperçu qui doit être activée pour une instance SKU standard. Si ce n’est pas activé, le service renvoie 403 Forbidden.

Nettoyer les ressources

Ce tutoriel ne crée aucune ressource Azure facturable. Si vous avez effectué une restauration pour les tests, vérifiez l’état du jeu de données avant de reprendre les opérations d’écriture.

Contenu connexe

• Tutoriel : Utiliser des données sismiques à l’aide des API DDMS sismiques
• Modifier le niveau de stockage des ensembles de données sismiques
• Comment générer un jeton d’authentification
• Informations de référence sur l’API DDMS sismique