This post is older than a year. Consider some information might not be accurate anymore.
If you run Elasticsearch and use Kibana for various reasons, you better ensure to perform automatic backups. The time spend in searches, visualizations and dashboard should be worth that. If an Elasticsearch upgrade goes south, you are happy to have a backup. The main advantages of an Elasticsearch cluster, that you can join and remove additional nodes, which may differ in their resources and capacity. That’s the situation I constantly deal at work. Shard Allocation Filtering helps to setup smart rules for example hot warm architecture.
Elasticsearch can backup the kibana index to various repositories. The only possibility, for me at work, is to store the backup to a shared NAS. That is the Elasticsearch file storage repository. My clusters consists of multiple nodes where some nodes are not attached to NAS. If kibana has shard on nodes, without the attached NAS mountpoint the backup fails. Shard allocation filtering enables me to mark indices to reside only on nodes with specific attributes.
In the elasticsearch configuration - elasticsearch.yml - I put the node attribute named rack with the value with-nas.
cluster.name: test
node.name: omega
node.master: true
node.data: true
node.ingest: true
node.attr.rack: "with-nas"
In the Kibana Console (Sense) I can change settings of the kibana index.
PUT .kibana/_settings
{
"index.routing.allocation.include.rack": "with-nas"
}
After that the master node will ensure that the .kibana index will be put on the nodes with the respective value.
