* docs: fix numbering in restore-snapshot.asciidoc
Fix numbering in "Restore an entire cluster" section.
Remove "3." for "Universal Profiling" and add "3." just before "If you use Elasticsearch security features"
* Keep ID, fix list rendering
---------
Co-authored-by: Abdon Pijpelink <abdon.pijpelink@elastic.co>
This commit updates the docs to call out that custom certificate
authorities for S3 repositories will need to be reinstalled every time
ES is upgraded, is the node is using the bundled JDK
These docs have various subsections under the _Client settings_ and
_Repository settings_ sections which are nothing to do with those
settings. The reasons for this are historical and no longer relevant.
This commit moves these subsections together and up a level so that they
better reflect the structure of the information.
We don't mention linearizable registers in the snapshot/restore docs
today, but these things are verified for correctness by the repository
analysis API and some users with incorrect repository implementations
struggle to understand the verification errors. This commit adds some
docs to describe them and their various implementations.
Adds the `?register_operation_count` parameter that allows to control
the number of register operations separately from the number of regular
blob operations.
It's often useful to quote these docs to users encountering problems
with their not-quite-S3-compatible storage system. In practice we don't
need to quote the bits in the middle but we do need the last sentence
about working with the supplier to address incompatibilities. This
commit reorders things so that the most commonly quoted sentences form a
standalone paragraph.
👋 howdy, team! Expanding reference to [internal](https://github.com/elastic/cloud/pull/118105) update, we've just confirmed ILM requires the repository name to be the same among migrating clusters. This is a hard block for Searchable Snapshots which requires un-Searchable-Snapshotting or redoing migration to resolve.
* [DOC+] snapshot-restore single index example
👋🏼 howdy, team! I'd like to append an example to snapshot-restore a single index. Support usually points users to [this page](https://www.elastic.co/guide/en/elasticsearch/reference/master/restore-snapshot-api.html) but then users attempt the `rename_pattern` example (which makes sense!). I'd like to point them to a more literal "close index > restore on that index" example in the future.
* Fix test failure and reword
---------
Co-authored-by: Abdon Pijpelink <abdon.pijpelink@elastic.co>
👋🏼 Regardless of if we decide to validation enforce #78276, may we please drop a doc note that users should avoid duplicating repositories (particularly bucket / base paths).
To make it clear that repository snapshots should be available and reliable for any mounted searchable snapshots.
Co-authored-by: David Turner <david.turner@elastic.co>
If the recovery node bandwidth settings exist,
then the default value for max snapshot speed will
be infinite, and the speed will be rate limited
by the recovery rate limit as well.
Fixes#57023
The get snapshot status API will currently return a value of `STARTED` for the state of a snapshot that is currently running. The documentation says that the `state` value for a running snapshot is `IN_PROGRESS`. This documentation change will align the docs with the actual result of the get snapshot status API.
Co-authored-by: Austin Smith <76973609+asmith-elastic@users.noreply.github.com>
1. Adds a note that you can restore older snapshots (to recover from a
failed upgrade) even after newer snapshots were taken.
2. Copies the note about incompatible S3 repo implementations to the top
level to avoid misunderstandings.
Adds a parameter `index_names` to the get snapshots API so that users may exclude the potentially very long index name lists when listing out snapshots.
closes#82937
Today the docs say that new major versions need new snapshot
repositories or else corruption may occur. This isn't true, we support
using the same repository across upgrades.
This commit adds back some notes which were lost when we consolidated
the snapshot/restore documentation into a single location.
The notes in question are that:
1) If a Snapshot repository contains Security's feature state, then
that repository contains security-sensitive information. This may
be obvious to some, but is good to state explicitly.
2) Some files, such as the keystore and TLS keys, are not included in
snapshots and are important to back up via other means.
Today the note in the docs about S3-compatible repositories notes that
the repo must behave correctly, but it's also important that it has the
same performance profile. This commit extends the docs to include this
info.
This commit corrects the snapshot creation and restoration docs to
describe the usage of `"none"` to restore no feature states. Previously,
they incorrectly stated that using an empty array would accomplish this,
but specifying an empty array results in the default behavior (rather
than preventing feature state snapshot/restoration).
Fabien Baligand
Tim Vernum
Iraklis Psaroudakis
Sanjay J
David Turner
Tanguy Leroux
Stef Nestor
Peter Dyson
David Kilfoyle
debadair
Daniel Mitterdorfer
Francisco Fernández Castaño
Stef Nestor
amyjtechwriter
Andrei Dan
Anthony McGlone
Joe Gallo
Pooya Salehi
Seth Michael Larson
Yannick Welsch
Armin Braun
Gordon Brown
James Rodewig
Tobias Stadler