Restore OpenSearch Indices

Use this page when you need to restore older log indices from Sauron OpenSearch backups in OCI Object Storage. Small restores can usually be done from OpenSearch Dashboards Dev Tools. Large or many-index restores require Sauron-team help because they can affect capacity, performance, and backups.

Which restore path should I use?

Task Recommended path
Restore a few older indices Use the self-service Dev Tools flow below.
Restore many or very large indices Request Sauron-team help in #sauron-support.
Export OpenSearch data to local files Use Download OpenSearch Data.

Before you restore

Ask your Sauron owner to confirm restore permission, capacity, and the snapshot repository name. The example uses object-store-repo; replace it if yours differs.

Before restoring indices:

  1. Open OpenSearch Dashboards and go to Dev Tools.
  2. Check cluster health and available disk space. If health is red, or capacity is uncertain, ask the Sauron team before restoring.
  3. Identify the exact source index names.
  4. Choose a snapshot that contains the indices you need.
  5. Restore into renamed indices so the restored logs are not treated like the original old indices.
  6. Keep the source index names, snapshot ID, restore request, and restored index names for validation.

For request fields, see the OpenSearch snapshot restore API reference.

Restore a few indices

1) Check the status of your OpenSearch cluster

GET _cat/indices?v&s=index:asc

Check GET _cluster/health and available disk space as well. A yellow cluster can have unassigned replica shards; a red cluster has unavailable primary shards. Ask #sauron-support before restoring if health is red, there are persistent unassigned shards, or capacity is uncertain.

2) List snapshots visible in this repository

GET _cat/snapshots/object-store-repo?h=id&s=id:desc

This lists snapshots visible in this repository to your account. It does not prove every backup or retention period for the instance. Check Console Recovery or ask the Sauron team if an expected snapshot is missing.

3) Select a snapshot and verify it has the logs you're interested in

From the list returned in Step 2, determine which snapshot to use. Suppose you want to restore example_index_2026.10_01 and example_index_2026.10_02. Choose a completed snapshot that contains the required indices and covers the log times you need. A later date alone does not prove coverage. The example below uses 20261004-192148.

Replace the sample ID with a real snapshot ID from your list, then confirm it contains those indices:

GET _snapshot/object-store-repo/20261004-192148?pretty

Check through the list to make sure the logs you're interested in appear.

4) Restore the indices

Restore the indices with new names. If you do not rename them, they can be subject to the instance's index retention rules, and an existing open index with the same name will block restore. This example removes the date separators and adds a -restore suffix. Check the rename and retention policy with the Sauron team if the data must remain available.

POST _snapshot/object-store-repo/20261004-192148/_restore
{
  "indices": "example_index_2026.10_01",
  "include_global_state": false,
  "include_aliases": false,
  "rename_pattern": "^example_index_2026\\.10_01$",
  "rename_replacement": "example_index_20261001-restore"
}

POST _snapshot/object-store-repo/20261004-192148/_restore
{
  "indices": "example_index_2026.10_02",
  "include_global_state": false,
  "include_aliases": false,
  "rename_pattern": "^example_index_2026\\.10_02$",
  "rename_replacement": "example_index_20261002-restore"
}

These requests start recovery into renamed indices without restoring cluster-wide settings or source aliases. They keep the snapshot's replica settings; ask your OpenSearch owner whether the destination needs an approved override. A successful response does not mean recovery has finished.

5) Verify the indices have been restored

Restore time depends on index size and cluster capacity. Check the state of the indices:

GET _cat/indices?v&s=index:asc

You should see example_index_20261001-restore and example_index_20261002-restore. Check recovery progress with GET _cat/recovery?v&active_only=true. Wait for recovery to finish and confirm the expected shard allocation with your OpenSearch owner; yellow health can mean only replicas are unassigned.

6) Prove the restored data is usable

Before treating the restore as complete:

  1. Confirm the restored index names are present.
  2. Confirm recovery has finished and the expected shards are available.
  3. Search the restored index names in OpenSearch Dashboards.
  4. Confirm the restored records include the log time range you expected.

7) Clean up restored indices when finished

When you are finished with the restored data, delete only the restored indices. Before deleting, confirm the index names have the -restore suffix and are not the original source indices.

DELETE example_index_20261001-restore
DELETE example_index_20261002-restore

Large restore requests

An example of a large restore request is: "I want to restore all daily indices from Oct 1-14, 2026." In this case, contact #sauron-support for assistance. Restoring large numbers of indices to your current Sauron can cause a number of problems:

  • Capacity: Your environment must be able to hold your current data plus all restored data.
  • Performance: When a lot of data is being restored, it may degrade performance of your OpenSearch cluster.
  • Backups: Extra restored data can increase backup size and duration. Confirm the instance's backup schedule and retention with the Sauron owner.

The Sauron team will choose an approved recovery destination and cleanup plan with you; a separate temporary instance may be appropriate.

Tips and checks

  • Tips: Confirm the snapshot contains the required indices. Restore under a new name first to avoid replacing existing data. OpenSearch restore guidance.
  • Check: Follow recovery progress and check shard allocation, then search for expected records. If recovery fails, read the Dev Tools error and check index names, snapshot contents, and available capacity. An accepted request does not prove completion.