Restore searchable snapshot data to a regular index

A searchable snapshot index is a read-only index whose data is stored in a snapshot repository.

Use this procedure for fully mounted and partially mounted searchable snapshots when you need to:

Modify documents that are stored in a read-only searchable snapshot.
Move the data to another snapshot repository by restoring it before creating a new snapshot.
Remove a data tier, such as the frozen tier, while keeping its data available as regular indices on another tier.
Return the data to regular index storage and recovery behavior instead of keeping it backed by a mounted snapshot.

This procedure restores the data from the source snapshot as a new regular index. It does not modify the mounted index in place.

The result is sometimes described as converting a searchable snapshot back to a regular index or rehydrating it.

The procedure covers searchable snapshots mounted manually or managed by the index lifecycle management (ILM) searchable_snapshot action. It also covers data stream backing indices managed by ILM or by data stream lifecycle (DLM) with frozen_after.

Note

If you want to restore searchable snapshot indices and keep them as searchable snapshots, follow Back up and restore searchable snapshots. This guide covers a different goal: bringing the data back as a regular index instead of recreating it as a searchable snapshot index.

Before you begin

Before restoring searchable snapshot data to a regular index:

Confirm that the source repository used by the mounted index is registered and that the source snapshot is available.
Ensure that the destination data nodes or tier have enough local storage for the complete regular index and its replicas. During the restore, the mounted and regular indices exist at the same time.
If the cluster uses data tiers, select a destination tier other than the frozen tier, which is reserved for partially mounted searchable snapshots.
Ensure that you have the permissions required to restore a snapshot and manage the affected indices, aliases, lifecycle policies, and data streams.

Warning

The source snapshot is the sole complete copy of the searchable snapshot data. Do not delete it until the regular index is fully restored and verified and the mounted index has been deleted.

Restore the data as a regular index

Follow these steps to restore the data from a mounted searchable snapshot as a regular index. To restore multiple indices, complete the procedure separately for each index.

Gather details and prepare the restore

Get the mounted index settings.

Use the mounted index settings to gather the information required for the restore and any later lifecycle decisions:
```
				GET /<searchable-snapshot-index-name>/_settings?filter_path=**.index.store.snapshot.index_name,**.index.store.snapshot.snapshot_name,**.index.store.snapshot.repository_name,**.index.lifecycle.name,**.index.lifecycle.rollover_alias&expand_wildcards=all
		
```
For example, the following response shows the relevant settings for the mounted index partial-.ds-logs-app-2026.09.01-000123:
```
{
  "partial-.ds-logs-app-2026.09.01-000123": {
    "settings": {
      "index": {
        "store": {
          "snapshot": {
            "repository_name": "my_repository",
            "snapshot_name": "my_snapshot",
            "index_name": "fm-clone-a1b2c3-.ds-logs-app-2026.09.01-000123"
          }
        },
        "lifecycle": {
          "name": "logs-app-policy"
        }
      }
    }
  }
}
		
```
Record the source details.

From the response, record the following details:
- index.store.snapshot.repository_name and index.store.snapshot.snapshot_name: The repository and snapshot to use in the restore API path. In this example, use my_repository and my_snapshot.
- index.store.snapshot.index_name: The name of the index stored in the source snapshot. It usually matches the regular index name before it was mounted, but it can identify an intermediate index such as fm-clone-* or dlm-clone-*. Use the exact returned value in the indices field of the restore request. In this example, use fm-clone-a1b2c3-.ds-logs-app-2026.09.01-000123.
- ILM settings: If present, record index.lifecycle.name and index.lifecycle.rollover_alias in case you want to reuse the previous policy after the restore.
Define the restore values.

Define the following values to use in the restore request:
- Restored index name: Select a name that does not conflict with an existing index, data stream, or alias. For an ILM-created data stream backing index, this is typically the mounted index name without the restored- or partial- prefix. For a DLM-created backing index, remove the dlm-frozen- prefix. For manually mounted snapshots, select any available index name. In this example, use .ds-logs-app-2026.09.01-000123.
- Allocation: If the cluster uses data tiers, select the destination and fallback tiers for the regular index. If the cluster uses nodes with the generic data role instead, plan to clear the inherited tier preference. The example in this guide uses the cold tier, with the warm and hot tiers as fallbacks.
- Number of replicas: Select the number of replicas required for the regular index. The example uses one replica.
Record how the mounted index is accessed

Use the get index API to identify any aliases and determine whether the mounted index belongs to a data stream:
```
				GET /<searchable-snapshot-index-name>?filter_path=*.aliases,*.data_stream
		
```
For example, the mounted index used throughout this guide is a backing index of the logs-app data stream and has no aliases:
```
{
  "partial-.ds-logs-app-2026.09.01-000123": {
    "aliases": {},
    "data_stream": "logs-app"
  }
}
		
```
- If aliases contains any entries, record their names and complete configuration so that you can transfer them to the regular index.
- If data_stream is present, the index is a backing index. Record the data stream name. If the field is absent, the index does not belong to a data stream.
Check for name conflicts.

Use the resolve index API to confirm that the selected restored index name does not match an existing index, data stream, or alias:
```
				GET /_resolve/index/<restored-index-name>
		
```
An empty indices, aliases, and data_streams response confirms that the name is available.

For an ILM-managed index that is not a data stream backing index, the searchable_snapshot action creates an alias with the original index name and points it to the mounted index. Because indices and aliases share the same namespace, you cannot restore the regular index with its original name while that alias exists.
- To preserve access through the existing alias, restore the regular index with a different name and then transfer the alias to it. This is the recommended approach.
- If the regular index itself must use the original name, use the update aliases API to remove or rename the conflicting alias before the restore. After you remove the alias, requests that use the original name will fail until the restore completes.
Restore the data from the source snapshot

Use the restore API to create a regular index from the source snapshot:
```
				POST /_snapshot/<snapshot_repository_name>/<searchable_snapshot_name>/_restore
					{
  "indices": "<snapshot_index_name>",
  "rename_pattern": "(.+)",
  "rename_replacement": "<restored_index_name>",
  "include_aliases": false,
  "index_settings": {
    "index.routing.allocation.include._tier_preference": "<data_tiers>",
    "index.number_of_replicas": 1,
    "index.lifecycle.name": null,
    "index.lifecycle.rollover_alias": null
  }
}
		
```
1. Use the repository and snapshot name recorded in the first step.
2. Use the index.store.snapshot.index_name value. This selects the actual index stored in the source snapshot.
3. Use the selected regular index name. The rename prevents an internal source name such as fm-clone-* or dlm-clone-* from becoming the regular index name. You can omit rename_pattern and rename_replacement if the source name already matches the desired name.
4. Do not restore aliases from the snapshot. Snapshot aliases might be absent or might not reflect the aliases on the mounted index. You transfer the current aliases after verifying the restore.
5. If the cluster uses data tiers, specify an ordered list of destination and fallback tiers. Do not include data_frozen because the restored index is a regular index. If the cluster does not use data tiers, set index.routing.allocation.include._tier_preference to null so that an inherited tier preference does not restrict allocation to nodes with the generic data role.
6. Set the number of replicas required for the regular index.
Snapshot restore does not apply current index templates. It restores the index metadata from the snapshot and then applies the overrides in the request. If the source index has custom require, include, or exclude allocation filters, add the appropriate null overrides to index_settings so that they do not prevent allocation on the destination tier. If the restored index has unassigned shards, troubleshoot conflicting allocation settings to identify any remaining filters that prevent allocation.

Example: Using the values gathered for partial-.ds-logs-app-2026.09.01-000123 in the previous steps, restore the data with the following request:
```
				POST /_snapshot/my_repository/my_snapshot/_restore
					{
  "indices": "fm-clone-a1b2c3-.ds-logs-app-2026.09.01-000123",
  "rename_pattern": "(.+)",
  "rename_replacement": ".ds-logs-app-2026.09.01-000123",
  "include_aliases": false,
  "index_settings": {
    "index.routing.allocation.include._tier_preference": "data_cold,data_warm,data_hot",
    "index.number_of_replicas": 1,
    "index.lifecycle.name": null,
    "index.lifecycle.rollover_alias": null
  }
}
		
```
Verify the restored index

Wait for the restore to finish and verify the regular index:
```
				GET /<restored-index-name>/_recovery?active_only=true
				GET /_cat/indices/<restored-index-name>?v=true
				GET /<restored-index-name>/_settings?filter_path=**.index.store.snapshot
		
```
Confirm that:
- The recovery response shows no active recoveries.
- The index health is green.
- docs.count and store.size have the expected values.
- The settings response contains no index.store.snapshot settings. Their absence confirms that the restored index is a regular index rather than a mounted searchable snapshot.
Clear restored ILM metadata

If ILM managed the index before it became a searchable snapshot, remove the restored lifecycle execution state:
```
				POST /<restored-index-name>/_ilm/remove
		
```
The restore request sets index.lifecycle.name and index.lifecycle.rollover_alias to null so that the restored index does not automatically resume its previous policy. The remove policy API then clears inherited lifecycle execution metadata, including the cached phase definition and any previous error state. Together, these actions provide a predictable starting point before you deliberately apply a policy to the regular index.

For more information about controlling lifecycle execution when restoring managed indices, refer to Restore managed indices and manage ILM actions.

For the restored index in this guide, use:
```
				POST /.ds-logs-app-2026.09.01-000123/_ilm/remove
		
```
Modify the restored data (optional)

If your reason for restoring the data is to update or delete documents, make and verify those changes now. The restored index is already verified as a regular index, but aliases, the data stream, or clients still use the mounted searchable snapshot index.

Skip this step if you do not need to modify the restored data.
Update aliases and data stream membership

Use the access details recorded earlier to make aliases and the data stream use the restored regular index. Complete each action that applies before deleting the mounted searchable snapshot index.

Transfer aliases

If the mounted searchable snapshot index uses aliases, transfer them to the regular index in one request:
```
				POST /_aliases
					{
  "actions": [
    {
      "remove": {
        "index": "<searchable-snapshot-index-name>",
        "alias": "<alias-name>"
      }
    },
    {
      "add": {
        "index": "<restored-index-name>",
        "alias": "<alias-name>"
      }
    }
  ]
}
		
```
1. Add one remove and add action pair for each alias. Include any filter, routing, or other alias configuration recorded earlier. The request applies all actions atomically.
Replace a data stream backing index

If the mounted searchable snapshot index is a data stream backing index, replace it with the regular index.
Warning
If DLM manages the data stream, review its lifecycle settings before adding the regular index:
- If frozen_after is configured, the restored backing index might become eligible for conversion back to a searchable snapshot based on its age. Depending on the intended behavior, remove the setting to stop future frozen conversions for the data stream, or increase its value to delay when the restored index becomes eligible.
- Any configured data_retention also applies after you add the regular index. Confirm that the retention period will not delete it earlier than intended.
Refer to Update the lifecycle of a data stream and Searchable snapshots for data streams.
Use the modify data stream API to replace the backing index atomically:
```
				POST /_data_stream/_modify
					{
  "actions": [
    {
      "remove_backing_index": {
        "data_stream": "<data-stream-name>",
        "index": "<searchable-snapshot-index-name>"
      }
    },
    {
      "add_backing_index": {
        "data_stream": "<data-stream-name>",
        "index": "<restored-index-name>"
      }
    }
  ]
}
		
```
Refer to Modify a data stream.

For the logs-app data stream example, use:
```
				POST /_data_stream/_modify
					{
  "actions": [
    {
      "remove_backing_index": {
        "data_stream": "logs-app",
        "index": "partial-.ds-logs-app-2026.09.01-000123"
      }
    },
    {
      "add_backing_index": {
        "data_stream": "logs-app",
        "index": ".ds-logs-app-2026.09.01-000123"
      }
    }
  ]
}
		
```
Verify that the data stream contains the regular backing index:
```
				GET /_data_stream/<data-stream-name>
		
```
Delete the mounted index

After confirming that aliases, the data stream, or clients use the regular index, delete the mounted searchable snapshot index:
```
				DELETE /<searchable-snapshot-index-name>
		
```
Deleting the mounted index does not delete its source snapshot or the data stored in the snapshot repository.
Delete the source snapshot (optional)

Delete the source snapshot if you no longer need it:
Warning
Delete the source snapshot only after verifying the restored regular index and deleting the mounted searchable snapshot index.

Before deleting the snapshot:
- Confirm that no other mounted index in this or another cluster depends on it.
- Confirm that it contains no other data you need. Manually created snapshots can contain multiple indices. A snapshot created by the ILM searchable_snapshot action contains only the managed index.
- Retain the source snapshot if a backup snapshot that contains the mounted index must remain restorable. A snapshot of a searchable snapshot index contains only metadata that references the source snapshot, not the original index data.
- If the restored data requires snapshot-based protection, retain the source snapshot until a new snapshot containing the regular index is available.
```
				DELETE /_snapshot/<snapshot_repository_name>/<searchable_snapshot_name>
		
```

Manage the regular index lifecycle

The restore performed in the previous section removes the previous ILM policy assignment and lifecycle execution state so the restored regular index does not resume its original policy unexpectedly. Choose how to manage it based on why you restored the data and how you want to retain it:

Leave the index unmanaged.
Apply an ILM policy designed for an existing index.
Return the index to an existing rollover-based lifecycle.
Let DLM manage the index automatically if it belongs to a DLM-managed data stream.

If you might reuse the previous policy, retrieve its definition:

				GET /_ilm/policy/<policy-name>

Before applying an ILM policy, review its phases, actions, and min_age values. If ILM uses an earlier origination date, the restored index might become eligible for multiple phases or deletion immediately.

Apply an ILM policy without rollover

When possible, create a dedicated policy for restored historical indices. Because these indices are generally not active write indices, they typically do not need rollover or the same phases and actions as indices managed from creation. Include only the actions you need, such as moving data between available tiers, converting the index to a new searchable snapshot, or deleting it according to your retention requirements.

If the policy includes resource-intensive actions such as force merge, apply it to restored indices gradually and monitor the cluster to avoid running too many actions concurrently.

If the index name contains its original creation date in the supported format, set index.lifecycle.parse_origination_date to true so that ILM calculates its age from that date:

						PUT /.ds-logs-app-2026.09.01-000123/_settings
					{
  "index.lifecycle.name": "restored-index-policy",
  "index.lifecycle.parse_origination_date": true
}
		
	

Refer to Apply an ILM policy to an existing index and Manage existing indices.

Reuse an ILM policy with rollover

You can reuse a policy with rollover when its rollover mechanism is already active and the restored index is not the write index. Set index.lifecycle.indexing_complete to true when you reapply the policy so that ILM does not attempt to roll over the historical index.

If the reused policy contains a searchable_snapshot action, ILM can convert the regular index to a new searchable snapshot after it completes any preceding actions.

The following examples assume that the index name contains its original creation date in the supported format. Otherwise, omit index.lifecycle.parse_origination_date or set index.lifecycle.origination_date explicitly. Refer to Index lifecycle management settings for details about these settings.

Backing index of an ILM-managed data stream

After adding the restored backing index to the data stream, reapply the policy and mark indexing as complete:

						PUT /.ds-logs-app-2026.09.01-000123/_settings
					{
  "index.lifecycle.name": "logs-app-policy",
  "index.lifecycle.indexing_complete": true,
  "index.lifecycle.parse_origination_date": true
}
		
	

Index that uses a rollover alias

For an alias-based rollover lifecycle, also set the index.lifecycle.rollover_alias setting. Confirm that the alias has another write index and that the restored index is not its write index:

						PUT /logs-app-2026.09.01-000123/_settings
					{
  "index.lifecycle.name": "logs-app-policy",
  "index.lifecycle.rollover_alias": "logs-app-write",
  "index.lifecycle.indexing_complete": true,
  "index.lifecycle.parse_origination_date": true
}
		
	

Refer to Skip rollover manually for the requirements and behavior of index.lifecycle.indexing_complete.

Use DLM

After you add the regular index to a DLM-managed data stream, the data stream lifecycle applies automatically. The index.lifecycle.indexing_complete setting is specific to ILM and is not required for DLM. No additional lifecycle assignment is required.