How to managed restored indices with ISM

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
v 1.3.2

Describe the issue:
When I restore an index from a snapshot, I have noticed that the creation_date of that index is from the snapshot, not from the day it was restored, which is causing me issues within ISM.

Is there a way to change the creation_date ( i know a reindex with do this, but I don’t really want to do a restore and reindex). If the creation date was from the time the index was restored this would not be a problem

It seems that we cannot change the creation date when restoring index, but you can try to clone the index after it has been restored, clone operation will not take too much time to execute in most cases.

Unfortunately, it is not possible to change the creation_date of an index after it has been restored from a snapshot. The creation_date is set when the index is created, and it is not possible to modify it directly.

One possible workaround is to clone the restored index to a new index with the desired creation_date. The clone operation will create a new index with the same data as the restored index, but with a new creation_date. This can be done using the clone API, which is a relatively quick operation that does not require reindexing the data.

Here’s an example of how to clone an index:

POST /_clone/my-restored-index
{
  "settings": {
    "index": {
      "creation_date": "2023-03-28T00:00:00Z"
    }
  }
}

In this example, we’re cloning the “my-restored-index” index and setting the creation_date to “2023-03-28T00:00:00Z”. You can replace this date with any value that you want.

Note that cloning an index will create a new index with a new name. You will need to update your ISM policies or other configurations to use the cloned index instead of the original restored index.

Thanks for your suggestions.

The way I resolved this particular issue was to restore the index and append _restored to the index name. I then created a new ISM rule which then removes indices with _restored at the end.

Regards,
Adrian