Improve language around backups before an upgrade about stack-docs HOT 5 OPEN

I'm still investigating whether my statement above regarding restoring snapshots to 6.x is completely correct.

Here is an additional note: "if in 5.x you got rid off all 2.x indices and all your internal indices were created in 5.x it is possible to upgrade to 6.x without upgrading the indices first. However, security is not going to work until you upgrade the .security index and watcher is not going to work until you upgrade the .watches index."

We'll also need to update the language on this page: https://www.elastic.co/guide/en/elasticsearch/reference/master/modules-snapshots.html

“A snapshot of an index created in 2.x can be restored to 5.x.
A snapshot of an index created in 1.x can be restored to 2.x.
A snapshot of an index created in 1.x can not be restored to 5.x.”

from stack-docs.

Strictly speaking, it's not a requirement to create a new repo / reindex every time you move major versions (I could have started off on 5.0, snapshotted through the major, and upgraded to 6.0 and we'd still be perfectly fine reading the old snapshot), but it is generally a best practice when possible. Also, you could create a snapshot repository in 5.0 that contains an index that was created in 2.x and that would be unrestorable once you move to 6.0. I think we should strive to convey a few warnings and best practices:

• Indices that were created in 2.x are unreadable in 6.x. I think we do a good job of conveying this already.
• Snapshots are incremental and may contain multiple indices that were created on various versions of Elasticsearch. This means if any of the indices in the snapshot were created prior to 5.0 (the "initial" bit before the incremental bits on top of it), they'll need to be reindex into a new snapshot repository in order to be restorable in 6.x. I think a warning like this could go in both the snapshot/restore docs and in the stack upgrade docs.
• It's best practice to create a new snapshot repository for each major version. I don't think we have this anywhere, and I'd be in favor of it being in the snapshot/restore docs.

As an aside, our snapshot/restore is hugely valuable but the semantics are pretty challenging and we'll need to address that over time. Having to write this type of documentation is challenging at best and that's generally a sign of a difficult-to-use feature.

from stack-docs.

from stack-docs.

We want to more or less completely revisit how snapshot/restore works.

from stack-docs.

from stack-docs.