# Snapshot restore Failed recovery of index, getting FileAlreadyExistsException

**URL:** <https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300>\
**Category:** Elasticsearch\
**Created:** [September 13, 2017, 7:33am UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300 "2017-09-13T07:33:16Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![rinu](https://avatars.discourse-cdn.com/v4/letter/r/85e7bf/32.png) [@rinu](https://discuss.elastic.co/u/rinu)\
**Post date:** [September 13, 2017, 7:33am UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/1 "2017-09-13T07:33:16Z")

</div>

When trying to restore a 2.2 snapshot on 5.1.1 cluster the below exception returned. out of 10 shards, 2 shards failed recovery. Able to restore the same snapshot in 2.2 and 5.5 cluster.  
Any idea why? there is no memory problem or permission issues. Similar Snapshot restored fine on 5.1.1 cluster some days back.

IndexShardRestoreFailedException[Failed to recover index]; nested: FileAlreadyExistsException[C:\elasticsearch\elasticsearch-5.1.1\data\nodes\0\indices\Zttv7nGBRn-KHM0uakuQ3A\2\index\_km\_Lucene50\_0.doc];

Appreciate your help

---

<div class="post-metadata">

**Author:** ![ywelsch](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ywelsch/32/7751_2.png) [@ywelsch](https://discuss.elastic.co/u/ywelsch)\
**Post date:** [September 13, 2017, 9:14am UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/2 "2017-09-13T09:14:52Z")

</div>

How did you run the restore? Did you close the index to be restored and ran the restore again? Is it possible that there are still remnants from the earlier restore on your disk?

---

<div class="post-metadata">

**Author:** ![rinu](https://avatars.discourse-cdn.com/v4/letter/r/85e7bf/32.png) [@rinu](https://discuss.elastic.co/u/rinu)\
**Post date:** [September 13, 2017, 9:39am UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/3 "2017-09-13T09:39:39Z")

</div>

yes, we used to close the existing index to be restored to update mapping and delta.

---

<div class="post-metadata">

**Author:** ![ywelsch](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ywelsch/32/7751_2.png) [@ywelsch](https://discuss.elastic.co/u/ywelsch)\
**Post date:** [September 13, 2017, 10:02am UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/4 "2017-09-13T10:02:44Z")

</div>

It looks like you're encountering a bug then (could be related to [https://github.com/elastic/elasticsearch/pull/20220](https://github.com/elastic/elasticsearch/pull/20220))

Are you seeing the same issue if you repeatedly restore the same index in the 5.5 cluster (and close it in-between restores)?

I will see if I can reproduce this.

---

<div class="post-metadata">

**Author:** ![rinu](https://avatars.discourse-cdn.com/v4/letter/r/85e7bf/32.png) [@rinu](https://discuss.elastic.co/u/rinu)\
**Post date:** [September 13, 2017, 2:04pm UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/5 "2017-09-13T14:04:36Z")

</div>

> [@ywelsch](#):
>
> there are still remnants from the earlier restore on your disk

I tried in 5.5 cluster closing and restoring again and again, this issue is not happening on it. This happens only on 5.1.1 cluster.

---

<div class="post-metadata">

**Author:** ![rinu](https://avatars.discourse-cdn.com/v4/letter/r/85e7bf/32.png) [@rinu](https://discuss.elastic.co/u/rinu)\
**Post date:** [September 13, 2017, 2:07pm UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/6 "2017-09-13T14:07:41Z")

</div>

Tried to restore on local machine (5.1.1) as new indices and got 5 unassigned primary shards out of 10. What may be the reason?

For unassigned shards seeing the same exception  
failed recovery, failure RecoveryFailedException[[index][0]: Recovery failed on {o79mICl}{o79mIClXR9iufzWCvjwfaw}{32ae7kuXRYuJSqA-qfM\_lA}{localhost}{127.0.0.1:9600}]; nested: IndexShardRecoveryException[failed recovery]; nested: IndexShardRestoreFailedException[restore failed]; nested: IndexShardRestoreFailedException[failed to restore snapshot [prod\_snapshot/prod\_snapshot]]; nested: IndexShardRestoreFailedException[Failed to recover index]; nested: FileAlreadyExistsException[C:\elasticsearch\elasticsearch-5.1.1\data\nodes\0\indices\isKmuLWLQrWdZvyrVg-rVA\0\index\_25m.cfs];

but there is no such file.

---

<div class="post-metadata">

**Author:** ![ywelsch](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ywelsch/32/7751_2.png) [@ywelsch](https://discuss.elastic.co/u/ywelsch)\
**Post date:** [September 13, 2017, 3:35pm UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/7 "2017-09-13T15:35:02Z")

</div>

that's truly weird. Is it possible to share the repository contents with us?

@Igor_Motov are you aware of such a bug in 5.1.1 that has been fixed in subsequent versions?

---

<div class="post-metadata">

**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\
**Post date:** [September 14, 2017, 12:37am UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/8 "2017-09-14T00:37:29Z")

</div>

@ywelsch yes, I have seen this before in one of support cases. It seems to be happening on some Windows machines. We were not able to reproduce the problem locally and as a result we don't really know the reason for this issue. However, the bit about snapshot being originally created on 2.2 is very useful bit of information.

I cannot think of any snapshot-related fixes between 5.1 and 5.5, but I suspect that this bug can be in the store or lucene. So, it's possible that it was fixed on this level.

---

<div class="post-metadata">

**Author:** ![rinu](https://avatars.discourse-cdn.com/v4/letter/r/85e7bf/32.png) [@rinu](https://discuss.elastic.co/u/rinu)\
**Post date:** [September 14, 2017, 4:15am UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/9 "2017-09-14T04:15:43Z")

</div>

yes exactly, this issue is occurring when the snapshot is restored (created from ubuntu) on a windows machine. However, the similar snapshot was working fine till few days back in the same procedure on windows. Restored fine on 2.2 or 5.5 cluster on ubuntu. did not try on windows.

@ywelsch, btw, I tried to close and restore snapshot repeatedly on 5.5 cluster on ubuntu. did not try on windows machine though. And the snapshot has production data, so unable to share the repository contents.

---

<div class="post-metadata">

**Author:** ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)\
**Post date:** [October 6, 2017, 6:02pm UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/10 "2017-10-06T18:02:14Z")

</div>

@rinu do you still have this snapshot arounds somewhere? Would you be able/willing to try restoring it locally on the system where it fails with some debug logging enabled?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [November 3, 2017, 6:02pm UTC](https://discuss.elastic.co/t/snapshot-restore-failed-recovery-of-index-getting-filealreadyexistsexception/100300/11 "2017-11-03T18:02:46Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
