[DOCS] Add definitions & remove fully-remote storage.

Author: debadair

docs/reference/glossary.asciidoc

@@ -39,6 +39,12 @@ An <<glossary-index-pattern,index pattern>> that automatically configures new in
 For more information, see {ref}/ccr-auto-follow.html[Managing auto follow patterns].
 // end::auto-follow-pattern-def[]
 
+[[glossary-backup-snapshot]] backup snapshot ::
+// tag::backup-snapshot-def[]
+A snapshot of a cluster, data stream, or index that resides in a remote data store such as S3 
+and is used for backup and recovery.
+// end::backup-snapshot-def[]
+
 [[glossary-cluster]] cluster ::
 // tag::cluster-def[]
 One or more <<glossary-node,nodes>> that share the
@@ -450,6 +456,12 @@ in the <<glossary-mapping,mapping>>.
 // end::routing-def[]
 --
 
+[[glossary-searchable-snapshot]] searchable snapshot ::
+// tag::searchable-snapshot-def[]
+A <<glossary-snapshot, snapshot>> of an index or data stream that resides in a remote data store 
+such as S3 and can be accessed dynamically at query time.
+// end::searchable-snapshot-def[]
+
 [[glossary-shard]] shard ::
 +
 --
@@ -486,9 +498,13 @@ See the {ref}/indices-shrink-index.html[shrink index API].
 
 [[glossary-snapshot]] snapshot ::
 // tag::snapshot-def[]
-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.
+Captures the state of a cluster, index, or data stream at a particular point in time. 
+See <<glossary-backup-snapshot, backup snapshot>> and <<glossary-searchable-snapshot, searchable snapshot>>.
+// end::snapshot-def[]
+
+[[glossary-snapshot]] snapshot-backed index ::
+// tag::snapshot-def[]
+A read-only index that relies on a <<glossary-searchable-snapshot, searchable snapshot>> for redundancy.
 // end::snapshot-def[]
 
 [[glossary-snapshot-lifecycle-policy]] snapshot lifecycle policy ::

docs/reference/searchable-snapshots/index.asciidoc

@@ -3,29 +3,22 @@
 
 {search-snaps-cap} enable you to significantly reduce costs by 
 leveraging external storage for read-only data. 
-Searchable snapshots can be used in two ways:
+Like snapshots used for backup and recovery, a searchable snapshot is a point-in-time copy 
+of an index or data stream stored in a remote data store such as S3. 
 
-* Snapshot-backed indices: Instead of maintaining replicas of your data within the cluster, 
-a snapshot-backed index relies on a searchable snapshot for redundancy. 
-You can perform all regular data retrieval operations, but cannot write to the index. 
+Snapshot-backed indices use searchable snapshots for redundancy rather than replicas within the cluster. 
+They support all regular data retrieval operations with performance comparable to a normal index.
 In the event of a failure, data is recovered from the snapshot. 
 Latency increases during recovery, but you can continue to query your data.
 
-* Fully-remote storage: Data is only brought into the cluster from the snapshot 
-when it is needed to service a query. 
-Because of the additional overhead, querying your data takes significantly longer 
-and it’s only accessible via asynchronous search.
-
 A snapshot-backed index essentially halves the number of nodes you need for read-only data. 
-If you are using ILM to manage your data, in the cold phase it can 
+If you are using {ilm-init} to manage your data, in the cold phase it can 
 automatically create a searchable snapshot, convert your index to a snapshot-backed index, 
 and move it to nodes in the cold tier.
 
-When you use fully-remote storage, you have access to your data when you need it, 
-without the expense of maintaining it in the cluster at all. 
-
 While searchable snapshots are separate from the snapshots used for backup and recovery, 
 they are just snapshots. In fact, you can mount any existing snapshot as a snapshot-backed index. 
 When you use the same repository for both types of snapshots, each snapshot is incremental. 
 Files are shared among searchable snapshots and backup snapshots to avoid data duplication. 
 This means that the additional storage costs for using searchable snapshots are negligible.
+