Restore .kibana index only or full cluster snapshot in Kibana?

Direct answer

Restore only the .kibana index when dashboards, index patterns, and saved objects are missing or corrupted but the underlying data indices still exist. Restore the full cluster snapshot when data indices themselves are missing, corrupted, or must be rolled back to an earlier point in time. A .kibana-only restore is faster and typically non-disruptive; a full snapshot restore recovers data but can overwrite recent writes and requires Kibana to be compatible with the Elasticsearch version that produced the snapshot.

Likely explanation versus confirmed facts

Likely explanation

• The .kibana index stores Kibana saved objects. Restoring it alone preserves UI state but does not recreate data indices created after the snapshot.
• Visualizations that reference missing or modified indices will show empty panels or broken references after a .kibana-only restore.
• A full cluster snapshot restores every index in the snapshot, including .kibana, but reverts the cluster to the snapshot point in time. Writes after that point may be lost unless replayed.

Confirmed facts

• Kibana must be compatible with the Elasticsearch version that produced the snapshot. A Kibana version older than the snapshot's Elasticsearch version may fail to parse saved object formats or mappings.
• A .kibana-only restore can run while the cluster is online; a full snapshot restore uses explicit restore API calls and may affect cluster health during shard recovery.
• Restoring .kibana alone does not verify that referenced data indices exist.

Steps for this case

1. Determine what was lost. If only Kibana UI objects are missing, proceed with .kibana-only. If data indices are missing, use the full snapshot.
2. Confirm the snapshot repository exists:

GET _snapshot/<repository_name>/_all

3. For .kibana-only restore, target only that index:

POST _snapshot/<repository_name>/<snapshot_name>/_restore
{
  "indices": ".kibana",
  "include_aliases": false
}

4. For a full cluster restore, omit the indices filter:

POST _snapshot/<repository_name>/<snapshot_name>/_restore

5. Monitor recovery:

GET _cat/recovery?v

Verification without service interruption

1. Run GET _cat/indices?v to confirm expected indices are present and green or yellow.
2. Query .kibana document count and spot-check a known dashboard type:

GET .kibana/_search
{
  "query": {
    "term": {
      "type": "dashboard"
    }
  },
  "size": 5
}

3. Open Kibana and load one dashboard and one index pattern. Confirm visualizations return data, not empty panels.
4. Compare GET _cluster/health before and after to ensure no unassigned shards remain.

Missing diagnostic detail

Are the missing items limited to Kibana saved objects (dashboards, index patterns, saved searches), or are data indices also absent or corrupted? This determines whether .kibana-only restore is sufficient or whether a full snapshot is required.

Assumptions and uncertainty

• Assumes access to the Elasticsearch restore API and a valid snapshot repository.
• Version compatibility between Kibana and the snapshot's Elasticsearch version has not been verified in your environment. Test in a staging cluster first if possible.
• This draft requires current verification because restore behavior varies by Elasticsearch version and snapshot method.