Skip to content

Document shard-skipping behaviour for partial snapshots during restore in 9.6.0 #8093

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
SandraOKeeffe wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Document shard-skipping behaviour for partial snapshots during restore in 9.6.0 #8093

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
82ec84b
Document shard-skipping behaviour for partial snapshots during concur…
SandraOKeeffe Aug 26, 2026
b29e7e6
Add applies_to annotation
SandraOKeeffe Aug 26, 2026
813e610
Remove serverless tag
SandraOKeeffe Aug 27, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion deploy-manage/tools/snapshot-and-restore.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,6 +142,8 @@ A snapshot copies segments from an index’s primary shards. When you start a sn

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.

@shainaraskas shainaraskas Aug 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


### Snapshot start and stop times

A snapshot doesn’t represent a cluster at a precise point in time. Instead, each snapshot includes a start and end time. The snapshot represents a view of each shard’s data at some point between these two times.
Expand All @@ -160,7 +162,7 @@ Any index you restore from a snapshot must also be compatible with the current c

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.

@masseyke masseyke Aug 26, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what's different here -- it looks identical.

@SandraOKeeffe SandraOKeeffe Aug 27, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My IDE could not see a difference either. :)


Use snapshot restore to recover or move data you own. Do not use it as a substitute for upgrading {{stack}} features. Follow the normal upgrade path for {{kib}} and other feature states.

Expand Down
Loading