Elasticsearch

Elasticsearch lets applications search and analyze records without scanning every source document themselves. It builds indexes that support queries, filters and aggregations, making it useful for search features and investigation of data such as logs. Running it on Kubernetes organizes the database processes, but the indexes and cluster configuration remain persistent data that need their own recovery plan. The historical chart here is separate from current Elastic operator-based packaging.

Current guidance

The historical package used elasticsearch-oss and a transport Service for node discovery. Current Elastic Cloud on Kubernetes manages Elasticsearch through an operator and custom resources; Elastic’s former standalone chart repository is archived. Those are packaging changes, while Elasticsearch version compatibility, image distribution, plugins and licensing remain separate choices. Do not assume an old OSS deployment can receive the newest image through a chart-only upgrade.

Inventory index creation versions, templates, aliases, ingest pipelines, security configuration and installed plugins. Take a supported Elasticsearch snapshot into an independent repository and establish which target versions can restore each index. Copying a live data directory or a PVC is not a substitute for the documented snapshot process. Some transitions require intermediate upgrades or reindexing rather than direct restoration.

Build a candidate with sufficient storage and the intended node roles, then restore a representative dataset. Compare document counts, mappings, search results and application writes, including authentication. Preserve repository contents and the original cluster through a defined rollback window. Once clients write to the replacement, reverting a Service address can lose those new writes unless the recovery plan explicitly reconciles them.