# Shard data is missing without any reason or log

**URL:** https://discuss.elastic.co/t/shard-data-is-missing-without-any-reason-or-log/161248
**Category:** Elasticsearch
**Created:** [December 18, 2018, 6:31am UTC](https://discuss.elastic.co/t/shard-data-is-missing-without-any-reason-or-log/161248 "2018-12-18T06:31:37Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### 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: [December 18, 2018, 8:19am UTC](https://discuss.elastic.co/t/shard-data-is-missing-without-any-reason-or-log/161248/3 "2018-12-18T08:19:15Z")

</div>

Relates to [Failed shard recovery after hard shutdown](https://discuss.elastic.co/t/failed-shard-recovery-after-hard-shutdown/160998).

It sounds like you have other lurking corruptions after your power outage. Unfortunately with zero replicas and storage that isn't resilient to powerloss there's no way to get out of this situation without losing yet more data. If it were me, I would start again.

Setting [`index.shard.check_on_startup: true`](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html#_static_index_settings) will at least check the whole index for corruption at startup rather than waiting for a corruption to be detected during a merge. This'll take a while, and you should set it back to `null` afterwards otherwise that check will happen every time.

If you are using version ≥ 6.5 then [the `elasticsearch-shard` tool](https://www.elastic.co/guide/en/elasticsearch/reference/6.5/shard-tool.html) will delete any corrupted segments, but as with `elasticsearch-translog` this entails arbitrary data loss.

---

_[View the full topic](https://discuss.elastic.co/t/shard-data-is-missing-without-any-reason-or-log/161248)._