Tutorial: Restaurar un conjunto de datos sísmico a un momento anterior

Utiliza la operación de restauración de DDMS sísmico en Azure Data Manager for Energy para restaurar un conjunto sísmico a un momento anterior. La operación restaura tanto los metadatos del conjunto de datos como los datos de blob asociados al estado que existían en la marca temporal que especifiques. Esta operación puede ayudar a recuperar un conjunto de datos tras una actualización o eliminación no intencionada, siempre que una versión restaurable siga disponible dentro del periodo fijo de retención de 30 días.

En este tutorial, obtendrá información sobre cómo:

Prerequisites

Antes de comenzar, asegúrese de cumplir los siguientes requisitos previos:

• Un recurso SKU de Azure Data Manager para el estándar energético con la vista previa de restauración de DDMS Seismic activada.
• Un tenant registrado y subproject en el servicio Seismic DDMS.
• El rol subproject.admin asignado a tu cuenta de usuario.
• Token de portador para la autenticación de API. Consulte Cómo generar el token de autenticación.
• El sdPath conjunto de datos sísmico que quieres restaurar.
• Un punto de restauración dentro del periodo fijo de retención de 30 días. El periodo de retención no es configurable.

Restaurar operaciones de API

El flujo de trabajo de restauración utiliza dos operaciones de API:

Elige un punto de restauración

El restorePointInTime valor identifica el estado a restaurar. Especifica el valor como una marca de tiempo ISO 8601 UTC, por ejemplo, 2026-07-10T08:30:00.000Z.

El punto de restauración debe cumplir todos los siguientes requisitos:

• Eso es cosa del pasado.
• Está dentro del periodo fijo de retención de restauración de 30 días.
• Es más tarde que el momento de creación del conjunto de datos.

Elige una marca de tiempo justo antes de la actualización o eliminación no deseada. El estado restaurado no incluye ningún cambio en el conjunto de datos realizado después de la marca temporal seleccionada.

Iniciar una operación de restauración

Antes de enviar la solicitud, detiene las operaciones de escritura y eliminación del conjunto de datos. La operación de restauración bloquea el conjunto de datos mientras restaura los metadatos y los datos del blob.

1. Envía una solicitud POST al endpoint de restauración. Deben sdPath identificar un conjunto de datos, no un directorio:

   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. Guarda el operation_id or statusUrl de la 202 Accepted respuesta. Necesitas uno de estos valores para monitorizar la operación:

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

Supervisa la operación de restauración

Consulta el endpoint de estado para rastrear la restauración asincrónica.

1. Envía una solicitud GET con la 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. Compruebe el status campo en la respuesta. La operación puede avanzar antes EnqueuedInProgress de alcanzar un estado 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. Detener la sondeación cuando status es uno de los siguientes valores terminales:

   Situación	Descripción
   Succeeded	Los metadatos del conjunto de datos y los datos de blobs se restauraron en el momento seleccionado.
   Failed	La restauración empezó pero no pudo completarse. Revisión errorDetails de la causa.
   Rejected	El servicio no pudo iniciar la restauración, por ejemplo, porque el conjunto de datos estaba bloqueado o no había estado restaurable disponible. Revisión errorDetails de la causa.

   El siguiente ejemplo muestra una restauración rechazada:

   {
     "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"
   }
   

Tras el éxito de la operación, recupera o descarga el conjunto de datos y confirma que sus metadatos y contenido coinciden con el estado esperado.

Limitaciones y consideraciones

Ten en cuenta las siguientes limitaciones antes de iniciar una restauración:

• Solo un solo conjunto de datos—Cada solicitud restaura un conjunto de datos. No puedes especificar un directorio, restaurar todos los conjuntos de datos bajo una ruta o enviar varios conjuntos de datos en una sola solicitud.
• Se aplica una ventana de retención fija—No puedes restaurar con una marca de tiempo fuera del periodo de retención de 30 días. El periodo de retención no es configurable y no puede ser anulado en la solicitud.
• Una restauración por partición de datos: Solo puede ejecutarse una operación de restauración en una partición de datos a la vez, incluso si otra solicitud apunta a un conjunto de datos diferente. Una solicitud concurrente devuelve 409 Conflict.
• La restauración es asincrónica—Una 202 Accepted respuesta no es confirmación de éxito. Debes consultar el endpoint de estado.
• Las escrituras deben pausarse: un bloqueo activo de escritura puede hacer que la operación sea rechazada. No actualices ni borres el conjunto de datos hasta que la restauración alcance un estado terminal.
• El estado actual se reemplaza: una restauración exitosa convierte la versión histórica seleccionada en el estado actual del conjunto de datos. Las actualizaciones hechas después del punto de restauración no están presentes en la versión restaurada.
• La disponibilidad de funciones es limitada: la operación de restauración es una función de vista previa que debe activarse para una instancia de SKU Estándar. Si no está habilitado, el servicio devuelve 403 Forbidden.

Limpieza de recursos

Este tutorial no crea recursos facturables de Azure. Si realizaste una restauración para pruebas, verifica el estado del conjunto de datos antes de reanudar las operaciones de escritura.

Contenido relacionado

• Tutorial: Trabajar con datos sísmicos mediante las API de DDMS de Seismic
• Cambiar el nivel de almacenamiento de conjuntos de datos sísmicos
• Cómo generar token de autenticación
• Referencia de la API de DDMS de Seismic