How does Elastic Cloud handle snapshots and version upgrades, and what still needs your action?

## Snapshots on a hosted deployment Every hosted Elastic Cloud deployment comes with a snapshot repository already registered — it appears as `found-snapshots` — pointing at object storage managed by Elastic, together with an automatically created snapshot lifecycle management policy. This means a newly created deployment is being backed up before anyone has thought about backups, which is one of the more genuinely valuable things the managed service does. Snapshots in Elasticsearch are incremental at the **segment** level: a snapshot references segment files already in the repository and only uploads segments that are new since the last snapshot. That is why frequent snapshots of a large index are far cheaper than the index size suggests, and it is also why deleting an old snapshot rarely frees the space you expect — shared segments stay until the last snapshot referencing them is gone. Restoring from the managed repository works inside the deployment, and the console additionally lets you create a **new deployment restored from another deployment's snapshot**, which is the normal way to clone production into a staging environment or to recover from a catastrophic misconfiguration. ## Why the automatic repository is not the whole backup story The managed repository is tied to the deployment and to Elastic's storage account. Teams with regulatory retention requirements, a need for backups under their own cloud account and IAM control, cross-region copies, or a desire to keep a clean migration path to a self-managed cluster register a **second, customer-owned repository** — an S3, GCS or Azure bucket — and drive it with their own SLM policy and retention rules. That customer-owned repository doubles as the exit strategy: snapshot out, restore into a cluster you run. A further caveat: a snapshot can only be restored into a cluster of the same major version or the next one, and a restored index still carries the Lucene format it was written with. Snapshots are not a way to escape the version-compatibility rules described below. ## Upgrades: what the platform does Selecting a newer stack version in the console triggers a plan change. The platform performs a rolling upgrade — taking nodes out one at a time, restarting them on the new version, waiting for health to recover before proceeding, and upgrading Kibana and other components in the correct order. You do not write the runbook, sequence the restarts, or manage the risk of two nodes down at once. ## Upgrades: what remains yours **Deprecations.** Kibana's Upgrade Assistant lists deprecated settings, mappings and API usage for the target major. Clearing these is application work — renaming settings, changing mapping constructs, adjusting queries — and it must happen before the upgrade, not after. **Old index formats.** Elasticsearch reads indices created by the **previous major version only**. Before a major upgrade, any index created two majors back must be reindexed into a current-format index or deleted. On long-lived clusters with old time-series indices this is the single most common upgrade blocker, and it takes real time and disk headroom. **Extensions and plugins.** Custom bundles and plugins are version-pinned. A synonym bundle or a plugin that has not been rebuilt for the target version will block or break the upgrade, so bundle compatibility is checked and updated as part of preparation. **Clients and integrations.** Language clients, Logstash pipelines and Beats have their own compatibility matrices. A major upgrade that leaves a client behind produces application errors that look like cluster problems. **Capacity and timing.** A rolling upgrade removes one node at a time from service, so indexing and search capacity dip for the duration and shard recovery consumes I/O afterward. On a tight cluster this is a real availability event; schedule it, and make sure indices have replicas so that a node leaving does not turn shards unavailable. **A verified snapshot.** Even with automatic snapshots, confirm a recent successful snapshot exists before a major upgrade rather than assuming it. ## Rehearsing the upgrade The strongest answer names the rehearsal: create a temporary deployment restored from a production snapshot, upgrade that, run the application's query suite and check relevance and aggregation results, then repeat on production. Managed hosting makes this cheap — the clone is a console action and the deployment can be deleted afterward — which turns "we hope it works" into a tested change. ## Failure modes to be able to name An upgrade that stalls because a shard cannot be allocated; an index in the old format discovered mid-upgrade; a query that silently changes behaviour because a deprecated construct was removed; an SLM policy quietly failing for days because nobody watches it; and a restore that fails because the target cluster is on an older major than the snapshot's source. Each of these is squarely on the customer's side of the line.