Document shard-skipping behaviour for partial snapshots during restore in 9.6.0 - #8093
Open
SandraOKeeffe wants to merge 3 commits into
Open
Document shard-skipping behaviour for partial snapshots during restore in 9.6.0#8093SandraOKeeffe wants to merge 3 commits into
SandraOKeeffe wants to merge 3 commits into
Conversation
Contributor
Elastic Docs AI PR menuCheck the box to run an AI review for this pull request.
Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team. |
Contributor
🔍 Preview links for changed docs |
Contributor
✅ Elastic Docs Style Checker (Vale)No issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
masseyke
reviewed
Aug 26, 2026
| Index compatibility in the context of the snapshot and restore process, indicates that {{es}} can restore the index and its data from the snapshot as a regular index or in a read-only form through [archive indices](/deploy-manage/upgrade/deployment-or-cluster/reading-indices-from-older-elasticsearch-versions.md). It does not mean that every application reading that data will treat it as valid on the target cluster version. | ||
|
|
||
| For indices and data streams you own and control, a compatible restore usually means the data remains usable. For {{stack}} feature data, including {{kib}} saved objects and data that other features write to their own indices, {{es}} compatibility does not guarantee validity across versions. Those applications can expect different data formats across {{stack}} versions, so a restore that {{es}} accepts can still fail or leave data in an unusable state. | ||
| For indices and data streams you own and control, a compatible restore usually means the data remains usable. For {{stack}} feature data, including {{kib}} saved objects and data that other features write to their own indices, {{es}} compatibility does not guarantee validity across versions. Those applications can expect different data formats across {{stack}} versions, so a restore that {{es}} accepts can still fail or leave data in an unusable state. |
Member
There was a problem hiding this comment.
I'm not sure what's different here -- it looks identical.
Author
There was a problem hiding this comment.
My IDE could not see a difference either. :)
masseyke
approved these changes
Aug 26, 2026
pete-naylor
reviewed
Aug 26, 2026
|
|
||
| Once a snapshot begins copying a shard’s segments, {{es}} won’t move the shard to another node, even if rebalancing or shard allocation settings would typically trigger reallocation. {{es}} will only move the shard after the snapshot finishes copying the shard’s data. | ||
|
|
||
| {applies_to}`stack: ga 9.6.0+` {applies_to}`serverless: ga` If a shard is currently being restored from another snapshot when a new snapshot starts, {{es}} waits for the restore to complete before copying that shard’s segments. When `partial` is set to `true` in the snapshot request, however, {{es}} skips the shard instead of waiting, allowing the snapshot to make progress even when some shards are unavailable. The resulting snapshot is marked as partial and does not contain data for the skipped shard. |
Contributor
There was a problem hiding this comment.
While this is true for the snapshots we'll initially use to back the Serverless Data Recovery feature at launch, we want this to remain an internal implementation detail (that we could change in the future if desired). To avoid confusion and potential asks for direct use of snapshots in Serverless, we should probably remove the Serverless tag here.
shainaraskas
approved these changes
Aug 28, 2026
shainaraskas
left a comment
shainaraskas
left a comment
Member
There was a problem hiding this comment.
approved with a recommendation
|
|
||
| Once a snapshot begins copying a shard’s segments, {{es}} won’t move the shard to another node, even if rebalancing or shard allocation settings would typically trigger reallocation. {{es}} will only move the shard after the snapshot finishes copying the shard’s data. | ||
|
|
||
| {applies_to}`stack: ga 9.6.0+`If a shard is currently being restored from another snapshot when a new snapshot starts, {{es}} waits for the restore to complete before copying that shard’s segments. When `partial` is set to `true` in the snapshot request, however, {{es}} skips the shard instead of waiting, allowing the snapshot to make progress even when some shards are unavailable. The resulting snapshot is marked as partial and does not contain data for the skipped shard. |
Member
There was a problem hiding this comment.
we should probably split this into two paragraphs, because the first sentence is (presumably) true across versions. consider:
Suggested change
| {applies_to}`stack: ga 9.6.0+`If a shard is currently being restored from another snapshot when a new snapshot starts, {{es}} waits for the restore to complete before copying that shard’s segments. When `partial` is set to `true` in the snapshot request, however, {{es}} skips the shard instead of waiting, allowing the snapshot to make progress even when some shards are unavailable. The resulting snapshot is marked as partial and does not contain data for the skipped shard. | |
| By default, if a shard is currently being restored from another snapshot when a new snapshot starts, {{es}} waits for the restore to complete before copying that shard’s segments. | |
| {applies_to}`stack: ga 9.6+` When `partial` is set to `true` in the snapshot request, {{es}} skips the shard instead of waiting, allowing the snapshot to make progress even when some shards are unavailable. The resulting snapshot is marked as partial and does not contain data for the skipped shard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Updates the documentation to reflect the change in partial snaphot behaviour during a restore from a snapshot. See elastic/elasticsearch#157536 for details.
Generative AI disclosure
Claude Code Opus