[DOCS] Update snapshot/restore and SLM docs for data streams (#58513)

Updates the existing snapshot/restore and SLM docs to make them
aware of data streams.

Author: jrodewig

docs/reference/glossary.asciidoc

@@ -480,8 +480,9 @@ See the {ref}/indices-shrink-index.html[shrink index API].
 
 [[glossary-snapshot]] snapshot ::
 // tag::snapshot-def[]
-A backup taken from a running {es} cluster. 
-You can take snapshots of individual indices or of the entire cluster. 
+A backup taken from a running {es} cluster.
+A snapshot can include backups of an entire cluster or only data streams and
+indices you specify.
 // end::snapshot-def[]
 
 [[glossary-snapshot-lifecycle-policy]] snapshot lifecycle policy ::

docs/reference/ilm/ilm-and-snapshots.asciidoc

@@ -1,9 +1,9 @@
 [role="xpack"]
 [testenv="basic"]
 [[index-lifecycle-and-snapshots]]
-== Restore a managed index
+== Restore a managed data stream or index
 
-When you restore a snapshot that contains managed indices, 
+When you restore a managed index or a data stream with managed backing indices, 
 {ilm-init} automatically resumes executing the restored indices' policies.
 A restored index's `min_age` is relative to when it was originally created or rolled over, 
 not its restoration time. 
@@ -12,8 +12,8 @@ an index has been restored from a snapshot.
 If you restore an index that was accidentally deleted half way through its month long lifecycle,
 it proceeds normally through the last two weeks of its lifecycle.
 
-In some cases, you might want to restore a managed index and 
-prevent {ilm-init} from immediately executing its policy. 
+In some cases, you might want to prevent {ilm-init} from immediately executing
+its policy on a restored index.
 For example, if you are restoring an older snapshot you might want to 
 prevent it from rapidly progressing through all of its lifecycle phases. 
 You might want to add or update documents before it's marked read-only or shrunk, 

docs/reference/slm/apis/index.asciidoc

@@ -4,12 +4,12 @@
 == Manage the snapshot lifecycle
 
 You can set up snapshot lifecycle policies to automate the timing, frequency, and retention of snapshots.
-Snapshot policies can apply to multiple indices.
+Snapshot policies can apply to multiple data streams and indices.
 
 The snapshot lifecycle management (SLM) <<snapshot-lifecycle-management-api, CRUD APIs>> provide
 the building blocks for the snapshot policy features that are part of the Management application in {kib}.
-The  Snapshot and Restore UI makes it easy to set up policies, register snapshot repositories,
-view and manage snapshots, and restore indices.
+The Snapshot and Restore UI makes it easy to set up policies, register snapshot repositories,
+view and manage snapshots, and restore data streams or indices.
 
 You can stop and restart SLM to temporarily pause automatic backups while performing
 upgrades or other maintenance.

docs/reference/slm/apis/slm-put.asciidoc

@@ -56,7 +56,7 @@ Configuration for each snapshot created by the policy.
 ====
 `ignore_unavailable`::
 (Optional, boolean)
-If `true`, missing indices do *not* cause snapshot creation to fail and return
+If `true`, missing data streams or indices do *not* cause snapshot creation to fail and return
 an error. Defaults to `false`.
 
 `include_global_state`::
@@ -65,14 +65,15 @@ If `true`, cluster states are included in snapshots. Defaults to `false`.
 
 `indices`::
 (Optional, array of strings)
-Array of index names or wildcard pattern of index names included in snapshots. It
-supports <<date-math-index-names,date math>> expressions.
+Array of data streams and indices to include in snapshots.
+<<date-math-index-names,Date math>> and wildcard (`*`) expressions are
+supported.
 ====
 
 `name`::
 (Required, string)
-Name automatically assigned to each snapshot created by the policy. This value
-supports the same <<date-math-index-names,date math>> supported in index names.
+Name automatically assigned to each snapshot created by the policy.
+<<date-math-index-names,Date math>> is supported.
 To prevent conflicting snapshot names, a UUID is automatically appended to each 
 snapshot name.
 
@@ -141,7 +142,7 @@ PUT /_slm/policy/daily-snapshots
 <2> The name each snapshot should be given
 <3> Which repository to take the snapshot in
 <4> Any extra snapshot configuration
-<5> Which indices the snapshot should contain
+<5> Data streams and indices the snapshot should contain
 <6> Optional retention configuration
 <7> Keep snapshots for 30 days
 <8> Always keep at least 5 successful snapshots, even if they're more than 30 days old

docs/reference/slm/apis/slm-stop.asciidoc

@@ -27,7 +27,7 @@ cluster privilege to use this API. For more information, see
 
 Halts all {slm} ({slm-init}) operations and stops the {slm-init} plugin.
 This is useful when you are performing maintenance on a cluster and need to
-prevent {slm-init} from performing any actions on your indices. 
+prevent {slm-init} from performing any actions on your data streams or indices. 
 Stopping {slm-init} does not stop any snapshots that are in progress.
 You can manually trigger snapshots with the <<slm-api-execute-lifecycle>> even if {slm-init} is stopped.
 

docs/reference/slm/getting-started-slm.asciidoc

@@ -3,8 +3,8 @@
 [[getting-started-snapshot-lifecycle-management]]
 === Tutorial: Automate backups with {slm-init}
 
-This tutorial demonstrates how to automate daily backups of {es} indices using an {slm-init} policy.
-The policy takes <<modules-snapshots, snapshots>> of all indices in the cluster 
+This tutorial demonstrates how to automate daily backups of {es} data streams and indices using an {slm-init} policy.
+The policy takes <<modules-snapshots, snapshots>> of all data streams and indices in the cluster 
 and stores them in a local repository.
 It also defines a retention policy and automatically deletes snapshots 
 when they are no longer needed.
@@ -47,7 +47,7 @@ PUT /_snapshot/my_repository
 
 Once you have a repository in place, 
 you can define an {slm-init} policy to take snapshots automatically. 
-The policy defines when to take snapshots, which indices should be included, 
+The policy defines when to take snapshots, which data streams or indices should be included, 
 and what to name the snapshots. 
 A policy can also specify a <<slm-retention,retention policy>> and 
 automatically delete snapshots when they are no longer needed.
@@ -58,7 +58,7 @@ Snapshots are incremental and make efficient use of storage.
 You can define and manage policies through {kib} Management or with the put policy API.
 
 For example, you could define a `nightly-snapshots` policy 
-to back up all of your indices daily at 2:30AM UTC.
+to back up all of your data streams and indices daily at 2:30AM UTC.
 
 A put policy request defines the policy configuration in JSON:
 
@@ -86,13 +86,13 @@ PUT /_slm/policy/nightly-snapshots
     <<date-math-index-names,date math>> to include the current date in the snapshot name
 <3> Where to store the snapshot
 <4> The configuration to be used for the snapshot requests (see below)
-<5> Which indices to include in the snapshot: all indices
+<5> Which data streams or indices to include in the snapshot: all data streams and indices
 <6> Optional retention policy: keep snapshots for 30 days, 
 retaining at least 5 and no more than 50 snapshots regardless of age 
 
 You can specify additional snapshot configuration options to customize how snapshots are taken.
 For example, you could configure the policy to fail the snapshot 
-if one of the specified indices is missing. 
+if one of the specified data streams or indices is missing. 
 For more information about snapshot options, see <<snapshots-take-snapshot,snapshot requests>>.
 
 [discrete]

docs/reference/slm/index.asciidoc

@@ -4,12 +4,12 @@
 == {slm-init}: Manage the snapshot lifecycle
 
 You can set up snapshot lifecycle policies to automate the timing, frequency, and retention of snapshots.
-Snapshot policies can apply to multiple indices.
+Snapshot policies can apply to multiple data streams and indices.
 
 The {slm} ({slm-init}) <<snapshot-lifecycle-management-api, CRUD APIs>> provide
 the building blocks for the snapshot policy features that are part of {kib} Management.
 {kibana-ref}/snapshot-repositories.html[Snapshot and Restore] makes it easy to 
-set up policies, register snapshot repositories, view and manage snapshots, and restore indices.
+set up policies, register snapshot repositories, view and manage snapshots, and restore data streams or indices.
 
 You can stop and restart {slm-init} to temporarily pause automatic backups while performing
 upgrades or other maintenance.

docs/reference/snapshot-restore/index.asciidoc

@@ -5,25 +5,28 @@
 --
 
 // tag::snapshot-intro[]
-A _snapshot_ is a backup taken from a running {es} cluster. 
-You can take snapshots of individual indices or of the entire cluster. 
-Snapshots can be stored in either local or remote repositories. 
-Remote repositories can reside on S3, HDFS, Azure, Google Cloud Storage, 
+A _snapshot_ is a backup taken from a running {es} cluster.
+You can take snapshots of an entire cluster, including all its data streams and
+indices. You can also take snapshots of only specific data streams or indices in
+the cluster.
+
+Snapshots can be stored in either local or remote repositories.
+Remote repositories can reside on S3, HDFS, Azure, Google Cloud Storage,
 and other platforms supported by a repository plugin.
 
-Snapshots are incremental: each snapshot of an index only stores data that 
-is not part of an earlier snapshot.  
+Snapshots are incremental: each snapshot only stores data that
+is not part of an earlier snapshot.
 This enables you to take frequent snapshots with minimal overhead.
-// end::snapshot-intro[] 
+// end::snapshot-intro[]
 
 // tag::restore-intro[]
-You can restore snapshots to a running cluster with the <<snapshots-restore-snapshot,restore API>>. 
-By default, all indices in the snapshot are restored. 
-Alternatively, you can restore specific indices or restore the cluster state from a snapshot. 
-When restoring indices, you can modify the index name and selected index settings. 
+You can restore snapshots to a running cluster with the <<snapshots-restore-snapshot,restore API>>.
+By default, all data streams and indices in the snapshot are restored.
+However, you can choose to restore only the cluster state or specific data
+streams or indices from a snapshot.
 // end::restore-intro[]
 
-You must <<snapshots-register-repository, register a snapshot repository>> 
+You must <<snapshots-register-repository, register a snapshot repository>>
 before you can <<snapshots-take-snapshot, take snapshots>>.
 
 You can use <<getting-started-snapshot-lifecycle-management, snapshot lifecycle management>>
@@ -50,7 +53,7 @@ compatibility. Follow the <<setup-upgrade,Upgrade documentation>>
 when migrating between versions.
 
 A snapshot contains a copy of the on-disk data structures that make up an
-index. This means that snapshots can only be restored to versions of
+index or a data stream's backing indices. This means that snapshots can only be restored to versions of
 {es} that can read the indices:
 
 * A snapshot of an index created in 6.x can be restored to 7.x.
@@ -67,20 +70,21 @@ We do not recommend restoring snapshots from later {es} versions in earlier
 versions. In some cases, the snapshots cannot be restored. For example, a
 snapshot taken in 7.6.0 cannot be restored to 7.5.0.
 
-Each snapshot can contain indices created in various versions of {es},
-and when restoring a snapshot it must be possible to restore all of the indices
-into the target cluster. If any indices in a snapshot were created in an
-incompatible version, you will not be able restore the snapshot.
+Each snapshot can contain indices created in various versions of {es}. This
+includes backing indices created for data streams. When restoring a snapshot, it
+must be possible to restore all of these indices into the target cluster. If any
+indices in a snapshot were created in an incompatible version, you will not be
+able restore the snapshot.
 
 IMPORTANT: When backing up your data prior to an upgrade, keep in mind that you
 won't be able to restore snapshots after you upgrade if they contain indices
 created in a version that's incompatible with the upgrade version.
 
-If you end up in a situation where you need to restore a snapshot of an index
+If you end up in a situation where you need to restore a snapshot of a data stream or index
 that is incompatible with the version of the cluster you are currently running,
 you can restore it on the latest compatible version and use
-<<reindex-from-remote,reindex-from-remote>> to rebuild the index on the current
-version. Reindexing from remote is only possible if the original index has
+<<reindex-from-remote,reindex-from-remote>> to rebuild the data stream or index on the current
+version. Reindexing from remote is only possible if the original data stream or index has
 source enabled. Retrieving and reindexing the data can take significantly
 longer than simply restoring a snapshot. If you have a large amount of data, we
 recommend testing the reindex from remote process with a subset of your data to

docs/reference/snapshot-restore/monitor-snapshot-restore.asciidoc

@@ -76,15 +76,15 @@ DELETE /_snapshot/my_backup/snapshot_1
 // TEST[continued]
 
 The restore operation uses the standard shard recovery mechanism. Therefore, any currently running restore operation can
-be canceled by deleting indices that are being restored. Please note that data for all deleted indices will be removed
+be canceled by deleting data streams and indices that are being restored. Please note that data for all deleted data streams and indices will be removed
 from the cluster as a result of this operation.
 
 [float]
 === Effect of cluster blocks on snapshot and restore 
 
 Many snapshot and restore operations are affected by cluster and index blocks. For example, registering and unregistering
-repositories require write global metadata access. The snapshot operation requires that all indices and their metadata as
-well as the global metadata were readable. The restore operation requires the global metadata to be writable, however
+repositories require write global metadata access. The snapshot operation requires that all indices, backing indices, and their metadata as
+well as the global metadata be readable. The restore operation requires the global metadata to be writable, however
 the index level blocks are ignored during restore because indices are essentially recreated during restore.
 Please note that a repository content is not part of the cluster and therefore cluster blocks don't affect internal
 repository operations such as listing or deleting snapshots from an already registered repository.