DOC-852 Add Whole Cluster Restore and Topic Recovery to the enterpris…

…e feature table (#912)

modules/get-started/pages/licensing/overview.adoc

@@ -102,10 +102,18 @@ The following table lists the Enterprise features for Redpanda and how Redpanda
 | Validates schema IDs server-side to ensure schema compatibility. With schema ID validation, records associated with unregistered schemas are detected and dropped by a broker rather than a consumer.
 | Topics with schema validation settings cannot be created or modified.
 
+| xref:manage:topic-recovery.adoc[Topic Recovery]
+| Allows restoring a single topic from Tiered Storage using remote recovery properties.
+| You cannot create topics with the `redpanda.remote.recovery=true` property or perform topic recovery operations. To proceed, add a valid license to the target cluster. Without a valid license, topic recovery is blocked.
+
 | xref:manage:tiered-storage.adoc[Tiered Storage]
 | Enables data storage in cloud object storage for long-term retention and retrieval.
 | Topics cannot be created or modified to enable Tiered Storage features. Additional partitions cannot be added to topics with Tiered Storage properties enabled.
 
+| xref:manage:whole-cluster-restore.adoc[Whole Cluster Restore] (WCR)
+| Enables the recovery of cluster data from a source cluster's snapshot.
+| If the license is expired, you cannot perform WCR. To proceed, add a valid license to the target cluster. If the source cluster has an expired license, the target cluster inherits the restriction until a valid license is applied.
+
 |===
 
 [[console]]

modules/manage/partials/topic-recovery.adoc

@@ -4,17 +4,31 @@ endif::[]
 ifndef::env-kubernetes[]
 :link-tiered-storage: manage:tiered-storage.adoc
 endif::[]
-When you create a topic, you can use remote recovery to download the topic data from object storage. This is useful when you need to restore a single topic in xref:{link-tiered-storage}[Tiered Storage] that was accidentally deleted from a cluster.
 
-include::manage:partial$topic-recovery-warning.adoc[]
-
-[IMPORTANT]
+[NOTE]
 ====
-* Remote recovery is only safe when no other clusters are writing to the specified bucket or container.
-* You must enable `redpanda.remote.read` when using remote recovery.
-* If you later disable `redpanda.remote.read` on the remote recovery topic, previously hydrated (downloaded) data will not be used to serve requests.
+include::shared:partial$enterprise-license.adoc[]
 ====
 
+When you create a topic, you can use remote recovery to download the topic data from object storage. This is useful when you need to restore a single topic in Tiered Storage that was accidentally deleted from a cluster.
+
+include::manage:partial$topic-recovery-warning.adoc[]
+
+== Prerequisites
+
+You must have:
+
+- xref:{link-tiered-storage}[Tiered Storage] enabled on your Redpanda cluster.
+
+- xref:{link-tiered-storage}#remote-read[Remote read] (`redpanda.remote.read`) enabled on the topic you want to recover.
+
+== Limitations
+
+- Remote recovery is only safe when no other clusters are writing to the same bucket or container.
+- If you disable `redpanda.remote.read` after remote recovery, previously downloaded data will not be used to serve requests.
+
+== Recover a topic
+
 To create a new topic using remote recovery, in which the recovered topic can read and write in the cloud:
 
 [,bash]

modules/manage/partials/whole-cluster-restore.adoc

@@ -7,18 +7,21 @@ ifndef::env-kubernetes[]
 :link-recovery-mode: manage:recovery-mode.adoc
 endif::[]
 
-With xref:{link-tiered-storage}[Tiered Storage] enabled, you can use whole cluster restore to restore data from a failed cluster (source cluster), including its metadata, onto a new cluster (target cluster). This is a simpler and cheaper alternative to active-active replication, for example with xref:upgrade:migrate/data-migration.adoc[MirrorMaker 2]. Use this recovery method to restore your application to the latest functional state as quickly as possible.
+[NOTE]
+====
+include::shared:partial$enterprise-license.adoc[]
+====
 
-NOTE: You cannot use whole cluster restore if the target cluster is in xref:{link-recovery-mode}[recovery mode].
+With xref:{link-tiered-storage}[Tiered Storage] enabled, you can use Whole Cluster Restore to restore data from a failed cluster (source cluster), including its metadata, onto a new cluster (target cluster). This is a simpler and cheaper alternative to active-active replication, for example with xref:upgrade:migrate/data-migration.adoc[MirrorMaker 2]. Use this recovery method to restore your application to the latest functional state as quickly as possible.
 
 [CAUTION]
 ====
-Whole cluster restore is not a fully-functional disaster recovery solution. It does not provide snapshot-style consistency. Some partitions in some topics will be more up-to-date than others. Committed transactions are not guaranteed to be atomic.
-
-If you need to restore only a subset of topic data, consider using xref:manage:topic-recovery.adoc[topic recovery] instead of a whole cluster restore.
+Whole Cluster Restore is not a fully-functional disaster recovery solution. It does not provide snapshot-style consistency. Some partitions in some topics will be more up-to-date than others. Committed transactions are not guaranteed to be atomic.
 ====
 
-The following metadata is included in a whole cluster restore:
+TIP: If you need to restore only a subset of topic data, consider using xref:manage:topic-recovery.adoc[topic recovery] instead of a Whole Cluster Restore.
+
+The following metadata is included in a Whole Cluster Restore:
 
 * Topic definitions. If you have enabled Tiered Storage only for specific topics, topics without Tiered Storage enabled will be restored empty.
 * Users and access control lists (ACLs).
@@ -47,7 +50,7 @@ The following metadata is included in a whole cluster restore:
 
 By default, Redpanda uploads cluster metadata to object storage periodically. You can manage metadata uploads for your source cluster, or disable them entirely, with the following cluster configuration properties:
 
-* xref:reference:cluster-properties.adoc#enable_cluster_metadata_upload_loop[`enable_cluster_metadata_upload_loop`]: Enable metadata uploads. This property is enabled by default and is required for whole cluster restore.
+* xref:reference:cluster-properties.adoc#enable_cluster_metadata_upload_loop[`enable_cluster_metadata_upload_loop`]: Enable metadata uploads. This property is enabled by default and is required for Whole Cluster Restore.
 * xref:reference:properties/object-storage-properties.adoc#cloud_storage_cluster_metadata_upload_interval_ms[`cloud_storage_cluster_metadata_upload_interval_ms`]: Set the time interval to wait between metadata uploads.
 * xref:reference:cluster-properties.adoc#controller_snapshot_max_age_sec[`controller_snapshot_max_age_sec`]: Maximum amount of time that can pass before Redpanda attempts to take a controller snapshot after a new controller command appears. This property affects how current the uploaded metadata can be.
 
@@ -71,7 +74,9 @@ You must have the following:
 
 === Limitations
 
-- Whole cluster restore supports only one source cluster. It is not possible to consolidate multiple clusters onto the target cluster.
+- You cannot use Whole Cluster Restore if the target cluster is in xref:{link-recovery-mode}[recovery mode].
+
+- Whole Cluster Restore supports only one source cluster. It is not possible to consolidate multiple clusters onto the target cluster.
 
 - If a duplicate cluster configuration is found in the target cluster, it will be overwritten by the restore.