Tutorial: Stellen Sie einen seismischen Datensatz an einen früheren Zeitpunkt wieder her

Verwenden Sie die Operation Seismic DDMS Restore in Azure Data Manager for Energy, um einen seismischen Datensatz an einen früheren Zeitpunkt zurückzusetzen. Die Operation stellt sowohl die Metadaten des Datensatzes als auch die zugehörigen Blob-Daten in den Zustand zurück, der zum von Ihnen angegebenen Zeitstempel existierte. Diese Operation kann helfen, einen Datensatz nach einer unbeabsichtigten Aktualisierung oder Löschung wiederherzustellen, vorausgesetzt, eine wiederherstellbare Version ist innerhalb der festen 30-tägigen Speicherfrist weiterhin verfügbar.

In diesem Tutorial erfahren Sie, wie:

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllen:

• Eine Azure Data Manager for Energy Standard SKU-Ressource mit aktivierter Seismic DDMS-Wiederherstellungsvorschau.
• Ein registrierter tenant und subproject im Seismic DDMS-Dienst.
• Die subproject.admin Rolle, die Ihrem Benutzerkonto zugewiesen ist.
• Ein Bearertoken für die API-Authentifizierung. Informationen zum Generieren eines Authentifizierungstokens.
• Der sdPath seismische Datensatz, den du wiederherstellen möchtest.
• Ein Wiederherstellungspunkt innerhalb der festen 30-tägigen Aufbewahrungsfrist. Die Aufbewahrungszeit ist nicht konfigurierbar.

API-Operationen wiederherstellen

Der Wiederherstellungsworkflow verwendet zwei API-Operationen:

Wählen Sie einen Wiederherstellungspunkt

Der Wert restorePointInTime identifiziert den zu wiederherstellenden Zustand. Geben Sie den Wert beispielsweise als ISO 8601 UTC-Zeitstempel an. 2026-07-10T08:30:00.000Z

Der Wiederherstellungspunkt muss alle folgenden Anforderungen erfüllen:

• Das ist Vergangenheit.
• Es liegt innerhalb der festen 30-tägigen Wiederherstellungsfrist.
• Es ist später als die Erstellungszeit des Datensatzes.

Wählen Sie einen Zeitstempel unmittelbar vor der unbeabsichtigten Aktualisierung oder Löschung. Der wiederhergestellte Zustand enthält keine Datensatzänderungen, die nach dem gewählten Zeitstempel vorgenommen wurden.

Starte eine Wiederherstellungsoperation

Bevor Sie die Anfrage einreichen, stoppen Sie die Schreib- und Löschoperationen im Datensatz. Die Wiederherstellungsoperation sperrt den Datensatz, während sie die Metadaten und Blob-Daten wiederherstellt.

1. Reichen Sie eine POST-Anfrage an den Wiederherstellungspunkt ein. Sie sdPath müssen einen Datensatz identifizieren, nicht ein Verzeichnis:

   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. Speichere das operation_id oder statusUrl aus der Antwort 202 Accepted . Sie benötigen einen dieser Werte, um die Operation zu überwachen:

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

Überwachen Sie den Wiederherstellungsvorgang

Abfrage des Status-Endpunkts, um die asynchrone Wiederherstellung zu verfolgen.

1. Senden Sie eine GET-Anfrage mit dem 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. Überprüfen Sie das status Feld in der Antwort. Die Operation kann durch Enqueued und InProgress bevor sie einen terminalen Zustand erreicht.

   {
     "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. Abfragen stoppen, wenn status einer der folgenden Terminalwerte ist:

   Status	Beschreibung
   Succeeded	Die Metadaten des Datensatzes und die Blob-Daten wurden auf den ausgewählten Zeitpunkt zurückgesetzt.
   Failed	Die Wiederherstellung begann, konnte aber nicht abgeschlossen werden. Überprüfen errorDetails Sie die Ursache.
   Rejected	Der Dienst konnte die Wiederherstellung nicht starten, zum Beispiel, weil der Datensatz gesperrt war oder kein wiederherstellbarer Zustand verfügbar war. Überprüfen errorDetails Sie die Ursache.

   Das folgende Beispiel zeigt eine abgelehnte Wiederherstellung:

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

Nachdem die Operation erfolgreich ist, rufen Sie den Datensatz ab oder laden Sie ihn herunter und bestätigen, dass seine Metadaten und Inhalte mit dem erwarteten Zustand übereinstimmen.

Einschränkungen und Überlegungen

Beachten Sie die folgenden Einschränkungen, bevor Sie eine Wiederherstellung starten:

• Nur ein einzelner Datensatz – Jede Anfrage stellt einen Datensatz wieder her. Man kann kein Verzeichnis angeben, nicht jeden Datensatz unter einem Pfad wiederherstellen oder mehrere Datensätze in einer Anfrage einreichen.
• Es gilt ein festes Aufbewahrungsfenster – Sie können nicht auf einen Zeitstempel außerhalb der 30-tägigen Aufbewahrungsfrist zurücksetzen. Die Aufbewahrungsfrist ist nicht konfigurierbar und kann in der Anfrage nicht überschrieben werden.
• Eine Wiederherstellung pro Datenpartition – Es kann jeweils nur eine Wiederherstellungsoperation in einer Datenpartition ausgeführt werden, selbst wenn eine andere Anfrage einen anderen Datensatz anspricht. Eine gleichzeitige Anfrage ergibt .409 Conflict
• Wiederherstellen ist asynchron – Eine 202 Accepted Antwort ist keine Bestätigung des Erfolgs. Du musst den Status-Endpunkt abfragen.
• Schreibvorgänge müssen pausiert werden – Eine aktive Schreibsperre kann dazu führen, dass die Operation abgelehnt wird. Aktualisieren oder löschen Sie den Datensatz nicht, bis die Wiederherstellung einen Terminalzustand erreicht hat.
• Der aktuelle Zustand wird ersetzt – Eine erfolgreiche Wiederherstellung macht die ausgewählte historische Version zum aktuellen Datensatzzustand. Updates, die nach dem Wiederherstellungspunkt vorgenommen wurden, sind in der wiederhergestellten Version nicht vorhanden.
• Die Funktionsverfügbarkeit ist begrenzt – Die Wiederherstellungsoperation ist eine Vorschaufunktion, die für eine Standard-SKU-Instanz aktiviert werden muss. Wenn es nicht aktiviert ist, gibt der Dienst die Sendung zurück.403 Forbidden

Bereinigen von Ressourcen

Dieses Tutorial erstellt keine abrechenbaren Azure-Ressourcen. Wenn Sie eine Wiederherstellung zum Testen durchgeführt haben, überprüfen Sie den Datensatzstatus, bevor Sie die Schreibvorgänge fortsetzen.

Verwandte Inhalte

• Lernprogramm: Arbeiten mit seismischen Daten mithilfe von seismischen DDMS-APIs
• Änderung der Speicherschicht seismischer Datensätze
• Wie man Authentifizierungstoken generiert
• Seismische DDMS-API-Referenz