mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-07 21:48:39 +00:00
018d946bba
This commit documents the backup and restore of a cluster's security configuration. It is not possible to only backup (or only restore) security configuration, independent to the rest of the cluster's conf, so this describes how a full configuration backup&restore will include security as well. Moreover, it explains how part of the security conf data resides on the special .security index and how to backup that using regular data snapshot API. Co-Authored-By: Lisa Cawley <lcawley@elastic.co> Co-Authored-By: Tim Vernum <tim@adjective.org>
63 lines
2.8 KiB
Plaintext
63 lines
2.8 KiB
Plaintext
[[backup-cluster-configuration]]
|
|
=== Back up a cluster's configuration
|
|
++++
|
|
<titleabbrev>Back up the cluster configuration</titleabbrev>
|
|
++++
|
|
|
|
In addition to backing up the data in a cluster, it is important to back up its configuration--especially when the cluster becomes large and difficult to
|
|
reconstruct.
|
|
|
|
Configuration information resides in
|
|
<<config-files-location, regular text files>> on every cluster node. Sensitive
|
|
setting values such as passwords for the {watcher} notification servers, are
|
|
specified inside a binary secure container, the
|
|
<<secure-settings, elasticsearch.keystore>> file. Some setting values are
|
|
file paths to the associated configuration data, such as the ingest geo ip
|
|
database. All these files are contained inside the `ES_PATH_CONF` directory.
|
|
|
|
NOTE: All changes to configuration files are done by manually editing the files
|
|
or using command line utilities, but *not* through APIs. In practice, these
|
|
changes are infrequent after the initial setup.
|
|
|
|
We recommend that you take regular (ideally, daily) backups of your {es} config
|
|
(`$ES_PATH_CONF`) directory using the file backup software of your choice.
|
|
|
|
TIP: We recommend that you have a configuration management plan for these
|
|
configuration files. You may wish to check them into version control, or
|
|
provision them though your choice of configuration management tool.
|
|
|
|
Some of these files may contain sensitive data such as passwords and TLS keys,
|
|
therefore you should investigate whether your backup software and/or storage
|
|
solution are able to encrypt this data.
|
|
|
|
Some settings in configuration files might be overridden by
|
|
<<cluster-update-settings,cluster settings>>. You can capture these settings in
|
|
a *data* backup snapshot by specifying the `include_global_state: true` (default)
|
|
parameter for the snapshot API. Alternatively, you can extract these
|
|
configuration values in text format by using the
|
|
<<cluster-get-settings, get settings API>>:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET _cluster/settings?pretty&flat_settings&filter_path=persistent
|
|
--------------------------------------------------
|
|
//CONSOLE
|
|
//TEST
|
|
|
|
You can store the output of this as a file together with the rest of
|
|
configuration files.
|
|
|
|
[NOTE]
|
|
====
|
|
|
|
* Transient settings are not considered for backup.
|
|
* {es} {security-features} store configuration data such as role definitions and
|
|
API keys inside a dedicate special index. This "system" data,
|
|
complements the <<secure-settings, security settings>> configuration and should
|
|
be <<backup-security-index-configuration, backed up as well>>.
|
|
* Other {stack} components, like Kibana and {ml-cap}, store their configuration
|
|
data inside other dedicated indices. From the {es} perspective these are just data
|
|
so you can use the regular <<backup-cluster-data, data backup>> process.
|
|
|
|
====
|