# Effective strategy to recover from failed upgrade

**URL:** <https://discuss.elastic.co/t/effective-strategy-to-recover-from-failed-upgrade/252021>\
**Category:** Elasticsearch\
**Created:** [October 14, 2020, 10:43am UTC](https://discuss.elastic.co/t/effective-strategy-to-recover-from-failed-upgrade/252021 "2020-10-14T10:43:42Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![amishar](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/amishar/32/76363_2.png) [@amishar](https://discuss.elastic.co/u/amishar)\
**Post date:** [October 14, 2020, 10:43am UTC](https://discuss.elastic.co/t/effective-strategy-to-recover-from-failed-upgrade/252021/1 "2020-10-14T10:43:42Z")

</div>

For a large Elasticsearch cluster that serve frequent index creation requests(lets say 1-2 per sec) and where it is not possible to pause these index creation during the rolling upgrade, what is the most effective strategy to abort a rolling upgrade from ES6 to ES7?  
Let us say that we have taken a snapshot right before the upgrade start and have a standby ES6 cluster ready to go in case of problem that require us to abort the upgrade. How do we then recover the changes to the data during the upgrade? Is there a recommended way to handle this?

---

<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 11, 2020, 10:43am UTC](https://discuss.elastic.co/t/effective-strategy-to-recover-from-failed-upgrade/252021/2 "2020-11-11T10:43:43Z")

</div>

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