# Red indices when restoring from snapshot which contains indices in cold phase **URL:** \ **Category:** Elasticsearch\ **Created:** [July 22, 2021, 3:52am UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329 "2021-07-22T03:52:26Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![dimitris\_sb](https://avatars.discourse-cdn.com/v4/letter/d/eada6e/32.png) [@dimitris\_sb](https://discuss.elastic.co/u/dimitris_sb)\ **Post date:** [July 22, 2021, 3:52am UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329/1 "2021-07-22T03:52:26Z")
Hi All, I got a snapshot in s3 from cluster A (7.11.x) and tried to restore it in cluster B (7.13.x) and noticed that indices in cold nodes e.g. index-data-2021.03 were restored as e.g. restored-shrink-index-data-2021.03 which was red (0 documents, 0 bytes). What is the problem here and how can I overcome it to restore the index? Their ILM policy is missing in the new server (I would assign a new one). Thank you in advance for you answers ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [July 22, 2021, 5:17am UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329/2 "2021-07-22T05:17:29Z")
The [cluster allocation explain API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-allocation-explain.html) answers questions like this. What does it say? ---
**Author:** ![dimitris\_sb](https://avatars.discourse-cdn.com/v4/letter/d/eada6e/32.png) [@dimitris\_sb](https://discuss.elastic.co/u/dimitris_sb)\ **Post date:** [July 26, 2021, 7:47am UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329/3 "2021-07-26T07:47:57Z")
Most of the instances report that they cannot host this index as it is meant for cold tier. The cold tier instance report that a related to the ILM policy, SLM policy snapshot repository is missing. I understand that I have to register the same repo with the same name. ```auto "deciders" : [ { "decider" : "restore_in_progress", "decision" : "NO", "explanation" : "shard has failed to be restored from the snapshot [migration_data:migration_index_data_06-2021.07.20-q2cdf65kr4-7dlltfhorab/NNgW2TOXQCuOgbF9NnPCSw] because of [failed shard on node [NMax3YN1RV2w-ooGQOexVQ]: failed to create shard, failure RepositoryMissingException[[index-data_slm_backups_repo] missing]] - manually close or delete the index [restored-index-data-2021.05] in order to retry to restore the snapshot again or use the reroute API to force the allocation of an empty primary shard" } ] ``` ---
**Author:** ![dimitris\_sb](https://avatars.discourse-cdn.com/v4/letter/d/eada6e/32.png) [@dimitris\_sb](https://discuss.elastic.co/u/dimitris_sb)\ **Post date:** [July 27, 2021, 4:58pm UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329/4 "2021-07-27T16:58:54Z")
I created the same repo with the same name and managed to "restore" these indices but I get ILM error "illegal\_argument\_exception: index [restored-shrink-index-data-2021.23] in snapshot [found-snapshots/tZZAEJD8SHa\_fAc4mew9-w:2021.07.27-restored-shrink-index-data-2021.23-ilm\_policy\_index\_data\_existing-x7cpnk7nrwypb8vgohwfw] is a snapshot of a searchable snapshot index backed by index [shrink-index-data-2021.23] in snapshot [index-data\_slm\_backups\_repo/:2021.06.24-shrink-index-data-2021.23-ilm\_no\_delete\_existing-w3sddtalqpoayxifxpcbzq] and cannot be mounted; did you mean to restore it instead?" Yeah, I would like to restore it and apply new ILM policies ... Should I use some other options in the restore request? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [July 27, 2021, 5:59pm UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329/5 "2021-07-27T17:59:22Z")
> [@dimitris\_sb](#): > > cannot be mounted; did you mean to restore it instead Looks like you tried to [mount](https://www.elastic.co/guide/en/elasticsearch/reference/current/searchable-snapshots-api-mount-snapshot.html) these indices rather than [restoring](https://www.elastic.co/guide/en/elasticsearch/reference/current/restore-snapshot-api.html) them? ---
**Author:** ![dimitris\_sb](https://avatars.discourse-cdn.com/v4/letter/d/eada6e/32.png) [@dimitris\_sb](https://discuss.elastic.co/u/dimitris_sb)\ **Post date:** [July 27, 2021, 6:02pm UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329/6 "2021-07-27T18:02:43Z")
I used ```auto POST /_snapshot/migration_data/migration_index_data_02-2021.07.16-hdydzipwqjk2gp3gvkvghq/_restore { "indices": "restored-shrink-index-data-2021.23", "ignore_unavailable": true, "include_global_state": false } ``` Should I use "include\_global\_state": true ? `include_global_state` (Optional, Boolean) If `false` , the global state is not restored. Defaults to `false` . If `true` , the current global state is included in the restore operation. The global state includes: - Persistent cluster settings - Index templates - Legacy index templates - Ingest pipelines - ILM lifecycle policies - For snapshots taken after 7.12.0, data stored in system indices, such as Watches and task records, replacing any existing configuration (configurable via `feature_states` ) ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [July 27, 2021, 8:24pm UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329/7 "2021-07-27T20:24:50Z")
I don't think it's possible to get a message containing the string `cannot be mounted; did you mean to restore it instead` from the API call you quoted. ---
**Author:** ![dimitris\_sb](https://avatars.discourse-cdn.com/v4/letter/d/eada6e/32.png) [@dimitris\_sb](https://discuss.elastic.co/u/dimitris_sb)\ **Post date:** [July 27, 2021, 8:36pm UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329/8 "2021-07-27T20:36:10Z")
Yes, it is strange as my intention was to restore. Is it possible that applying another ILM policy, a mount call is made by ILM? ---
**Author:** ![dimitris\_sb](https://avatars.discourse-cdn.com/v4/letter/d/eada6e/32.png) [@dimitris\_sb](https://discuss.elastic.co/u/dimitris_sb)\ **Post date:** [August 2, 2021, 6:37am UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329/9 "2021-08-02T06:37:47Z")
I think that the problem is that as it has a searchable snapshot (Frozen tier) and I want to copy it to another cluster where the specific ILM policy is missing/replaced with another when I use the restore functionality from the UI or the API, the newly restored indices display this error. Should I change the ILM policy not to contain searchable snapshots in the existing cluster? How could I copy them without such behavior? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [August 30, 2021, 6:38am UTC](https://discuss.elastic.co/t/red-indices-when-restoring-from-snapshot-which-contains-indices-in-cold-phase/279329/10 "2021-08-30T06:38:33Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.