Tutorial: Restaurar um conjunto de dados sísmico para um ponto anterior no tempo

Use a operação de restauração do DDMS Sísmico no Azure Data Manager for Energy para restaurar um conjunto de dados sísmico a um ponto anterior no tempo. A operação restaura tanto os metadados do conjunto de dados quanto seus dados de blob associados ao estado que existiam no carimbo de tempo que você especifica. Essa operação pode ajudar a recuperar um conjunto de dados após uma atualização ou exclusão não intencional, desde que uma versão restaurável ainda esteja disponível dentro do período fixo de retenção de 30 dias.

Neste tutorial, você aprenderá como:

Pré-requisitos

Antes de iniciar, verifique se você cumpre os seguintes pré-requisitos:

• Um recurso do Azure Data Manager para o padrão de energia SKU com a prévia de restauração do DDMS Sísmico ativada.
• Um tenant e subproject registrado no serviço DDMS Sísmico.
• A função subproject.admin atribuída à sua conta de usuário.
• Um token de portador para autenticação de API. Veja como gerar o token de autenticação.
• O sdPath conjunto de dados sísmico que você deseja restaurar.
• Um ponto de restauração dentro do período fixo de retenção de 30 dias. O período de retenção não é configurável.

Restaurar operações da API

O fluxo de restauração utiliza duas operações de API:

Escolha um ponto de restauração

O restorePointInTime valor identifica o estado a ser restaurado. Especifique o valor como um carimbo de data ISO 8601 UTC, por exemplo, 2026-07-10T08:30:00.000Z.

O ponto de restauração deve atender a todos os seguintes requisitos:

• Isso já passou.
• Está dentro do período fixo de retenção de restauração de 30 dias.
• É mais tarde do que o tempo de criação do conjunto de dados.

Escolha um carimbo de data imediatamente antes da atualização ou exclusão não intencional. O estado restaurado não inclui nenhuma alteração no conjunto de dados feita após o carimbo de tempo selecionado.

Iniciar uma operação de restauração

Antes de enviar a solicitação, pare as operações de gravação e exclusão no conjunto de dados. A operação de restauração bloqueia o conjunto de dados enquanto restaura os metadados e os dados do blob.

1. Envie uma solicitação POST para o endpoint de restauração. O sdPath objetivo deve identificar um conjunto de dados, não um diretório:

   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. Salve o operation_id ou statusUrl da 202 Accepted resposta. Você precisa de um desses valores para monitorar a operação:

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

Monitore a operação de restauração

Consulte o endpoint de status para acompanhar a restauração assíncrona.

1. Envie um pedido GET com o 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. Verifique o status campo na resposta. A operação pode avançar antes EnqueuedInProgress de atingir o 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. Pare de sondar quando status for um dos seguintes valores terminais:

   Status	Descrição
   Succeeded	Os metadados do conjunto de dados e os dados de blobs foram restaurados no momento selecionado.
   Failed	A restauração começou, mas não conseguiu ser concluída. Reveja errorDetails a causa.
   Rejected	O serviço não conseguiu iniciar a restauração, por exemplo, porque o conjunto de dados estava bloqueado ou nenhum estado restaurável estava disponível. Reveja errorDetails a causa.

   O exemplo a seguir mostra uma restauração rejeitada:

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

Após o sucesso da operação, recupere ou baixe o conjunto de dados e confirme se seus metadados e conteúdos correspondem ao estado esperado.

Limitações e considerações

Considere as seguintes limitações antes de iniciar uma restauração:

• Apenas um único conjunto de dados — Cada requisição restaura um conjunto de conjuntos. Você não pode especificar um diretório, restaurar todos os conjuntos de dados em um caminho ou enviar vários conjuntos de dados em uma única solicitação.
• A janela de retenção fixa se aplica — Você não pode restaurar para um carimbo de tempo fora do período de retenção de 30 dias. O período de retenção não é configurável e não pode ser anulado no pedido.
• Uma restauração por partição de dados — Apenas uma operação de restauração pode ser executada em uma partição de dados por vez, mesmo que outra requisição tenha como alvo um conjunto de dados diferente. Uma solicitação simultânea retorna 409 Conflict.
• A restauração é assíncrona — Uma 202 Accepted resposta não é confirmação de sucesso. Você deve consultar o endpoint de status.
• As gravações devem ser pausadas — Um bloqueio ativo de escrita pode fazer com que a operação seja rejeitada. Não atualize nem exclua o conjunto de dados até que a restauração atinja um estado terminal.
• O estado atual é substituído — Uma restauração bem-sucedida transforma a versão histórica selecionada no estado atual do conjunto de dados. As atualizações feitas após o ponto de restauração não estão presentes na versão restaurada.
• A disponibilidade de recursos é limitada — A operação de restauração é uma prévia que deve ser ativada para uma instância de SKU Padrão. Se não estiver ativado, o serviço retorna 403 Forbidden.

Limpar os recursos

Este tutorial não cria recursos faturáveis no Azure. Se você realizou uma restauração para testes, verifique o estado do conjunto de dados antes de retomar as operações de escrita.

Conteúdo relacionado

• Tutorial: Trabalhar com dados sísmicos usando APIs do DDMS sísmico
• Altere o nível de armazenamento dos conjuntos de dados sísmicos
• Como gerar token de autenticação
• Referência da API do Seismic DDMS