mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-24 23:27:25 -04:00
255c9a7f95
**Problem:** For historical reasons, source files for the Elasticsearch Guide's security, watcher, and Logstash API docs are housed in the `x-pack/docs` directory. This can confuse new contributors who expect Elasticsearch Guide docs to be located in `docs/reference`. **Solution:** - Move the security, watcher, and Logstash API doc source files to the `docs/reference` directory - Update doc snippet tests to use security Rel: https://github.com/elastic/platform-docs-team/issues/208
40 lines
1.9 KiB
Text
40 lines
1.9 KiB
Text
[role="xpack"]
|
|
[[operator-only-snapshot-and-restore]]
|
|
=== Operator privileges for snapshot and restore
|
|
|
|
NOTE: {cloud-only}
|
|
|
|
Invoking <<operator-only-apis,operator-only APIs>> or updating
|
|
<<operator-only-dynamic-cluster-settings,operator-only dynamic cluster settings>>
|
|
typically results in changes in the cluster state. The cluster state can be
|
|
included in a cluster <<snapshot-restore,snapshot>>. Snapshots are a great way
|
|
to preserve the data of a cluster, which can later be restored to bootstrap a
|
|
new cluster, perform migration, or disaster recovery, for example. In a
|
|
traditional self-managed environment, the intention is for the restore process
|
|
to copy the entire cluster state over when requested. However, in a more
|
|
managed environment, such as {ess-trial}[{ess}], data that is associated with
|
|
<<operator-only-functionality,operator-only functionality>> is explicitly
|
|
managed by the infrastructure code.
|
|
|
|
Restoring snapshot data associated with
|
|
operator-only functionality could be problematic
|
|
because:
|
|
|
|
1. A snapshot could contain incorrect values for operator-only functionalities.
|
|
For example, the snapshot could have been taken in a different cluster where
|
|
requirements are different or the operator privileges feature is not enabled.
|
|
Restoring data associated with operator-only functionality breaks the guarantee
|
|
of operator privileges.
|
|
2. Even when the infrastructure code can correct the values immediately after
|
|
a restore, there will always be a short period of time when the cluster could be
|
|
in an inconsistent state.
|
|
3. The infrastructure code prefers to configure operator-only functionality from
|
|
a single place, that is to say, through API calls.
|
|
|
|
Therefore,
|
|
<<configure-operator-privileges,*when the operator privileges feature is enabled*>>,
|
|
snapshot data that is associated with any operator-only functionality is *not*
|
|
restored.
|
|
|
|
NOTE: That information is still included when taking a snapshot so that all data
|
|
is always preserved.
|