Apply 1 suggestion(s) to 1 file(s)

Co-authored-by: Michael Kozono <mkozono@gitlab.com>

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -30,10 +30,10 @@ have a high degree of confidence in being able to perform them accurately.
 
 ## Not all data is automatically replicated
 
-If you are using any GitLab features that Geo [doesn't support](../replication/datatypes.md#limitations-on-replicationverification),
+If you are using any GitLab features that Geo doesn't support,
 you must make separate provisions to ensure that the **secondary** site has an
 up-to-date copy of any data associated with that feature. This may extend the
-required scheduled maintenance period significantly.
+required scheduled maintenance period significantly. A list of features supported by Geo can be found in the [replicated data types table](../replication/datatypes.md#replicated-data-types).
 
 A common strategy for keeping this period as short as possible for data stored
 in files is to use `rsync` to transfer the data. An initial `rsync` can be

doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md

@@ -102,7 +102,7 @@ follow these steps to avoid unnecessary data loss:
    [what is excluded](../planned_failover.md#not-all-data-is-automatically-replicated).
 
    1. If you are manually replicating any
-      [data not managed by Geo](../../replication/datatypes.md#limitations-on-replicationverification),
+      [data not managed by Geo](../../replication/datatypes.md#replicated-data-types),
       trigger the final replication process now.
    1. On the **primary** site:
       1. On the left sidebar, at the bottom, select **Admin**.

doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md

@@ -131,7 +131,7 @@ follow these steps to avoid unnecessary data loss:
    [what is excluded](../planned_failover.md#not-all-data-is-automatically-replicated).
 
    1. If you are manually replicating any
-      [data not managed by Geo](../../replication/datatypes.md#limitations-on-replicationverification),
+      [data not managed by Geo](../../replication/datatypes.md#replicated-data-types),
       trigger the final replication process now.
    1. On the **primary** site:
       1. On the left sidebar, at the bottom, select **Admin**.

doc/administration/geo/index.md

@@ -230,9 +230,10 @@ This list of limitations only reflects the latest version of GitLab. If you are
 - Git clone and fetch requests with option `--depth` over SSH against a secondary site does not work and hangs indefinitely if the secondary site is not up to date at the time the request is initiated. This is due to problems related to translating Git SSH to Git https during proxying. For more information, see [issue 391980](https://gitlab.com/gitlab-org/gitlab/-/issues/391980). A new workflow that does not involve the aforementioned translation step is now available for Linux-packaged GitLab Geo secondary sites which can be enabled with a feature flag. For more details, see [comment in issue 454707](https://gitlab.com/gitlab-org/gitlab/-/issues/454707#note_2102067451). The fix for Cloud Native GitLab Geo secondary sites is tracked in [issue 5641](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5641).
 - Some customers have reported that `git fetch` over SSH when the secondary site is out of date hangs and/or times out and fails. `git clone` requests over SSH are not impacted. For more information, see [issue 454707](https://gitlab.com/gitlab-org/gitlab/-/issues/454707). A fix available for Linux-packaged GitLab Geo secondary sites which can be enabled with a feature flag. For more details, see [comment in issue 454707](https://gitlab.com/gitlab-org/gitlab/-/issues/454707#note_2102067451). The fix for Cloud Native GitLab Geo secondary sites is tracked in [issue 5641](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5641).
 
-### Limitations on replication/verification
+### Replicated data types
 
-There is a complete list of all GitLab [data types](replication/datatypes.md) and [existing support for replication and verification](replication/datatypes.md#limitations-on-replicationverification).
+There is a complete list of all GitLab [data types](replication/datatypes.md) and 
+[replicated data types](replication/datatypes.md#replicated-data-types).
 
 ## Setup instructions
 

doc/administration/geo/replication/datatypes.md

@@ -147,15 +147,7 @@ Elasticsearch is an optional database for advanced search. It can improve search
 in both source-code level, and user generated content in issues, merge requests, and discussions.
 Elasticsearch is not supported in Geo.
 
-## Limitations on replication/verification
-
-The following table lists the GitLab features along with their replication
-and verification status on a **secondary** site.
-
-You can keep track of the progress to implement the missing items in
-these epics/issues:
-
-- [Geo: Improve the self-service Geo replication framework](https://gitlab.com/groups/gitlab-org/-/epics/3761)
+## Replicated data types
 
 ### Replicated data types behind a feature flag
 

doc/administration/get_started.md

@@ -203,7 +203,7 @@ While GitLab Geo helps remote teams work more efficiently by using a local GitLa
 Learn more about using [Geo as a disaster recovery solution](../administration/geo/disaster_recovery/index.md).
 
 Geo replicates your database, your Git repositories, and a few other assets.
-Learn more about [replication limitations](../administration/geo/replication/datatypes.md#limitations-on-replicationverification).
+Learn more about the [data types Geo replicates](../administration/geo/replication/datatypes.md#replicated-data-types).
 
 ## Support for GitLab self-managed
 

doc/administration/gitaly/gitaly_geo_capabilities.md

@@ -24,7 +24,7 @@ If your availability needs to span multiple zones or multiple locations, read ab
 
 | Capability | Availability | Recoverability | Data Resiliency | Performance | Risks/Trade-offs|
 |------------|--------------|----------------|-----------------|-------------|-----------------|
-|Geo| Depends on the architecture of the Geo site. It is possible to deploy secondaries in single and multiple node configurations. | Eventually consistent. Recovery point depends on replication lag, which depends on a number of factors such as network speeds. Geo supports failover from a primary to secondary site using manual commands that are scriptable. | Geo replicates 100% of planned data types and verifies 50%. See [limitations table](../geo/replication/datatypes.md#limitations-on-replicationverification) for more detail. | Improves read/clone times for users of a secondary.  | Geo is not intended to replace other backup/restore solutions. Because of replication lag and the possibility of replicating bad data from a primary, customers should also take regular backups of their primary site and test the restore process. |
+|Geo| Depends on the architecture of the Geo site. It is possible to deploy secondaries in single and multiple node configurations. | Eventually consistent. Recovery point depends on replication lag, which depends on a number of factors such as network speeds. Geo supports failover from a primary to secondary site using manual commands that are scriptable. | Geo replicates and verifies 100% of planned data types. See the [replicated data types table](../geo/replication/datatypes.md#replicated-data-types) for more detail. | Improves read/clone times for users of a secondary.  | Geo is not intended to replace other backup/restore solutions. Because of replication lag and the possibility of replicating bad data from a primary, customers should also take regular backups of their primary site and test the restore process. |
 
 ## Scenarios for failure modes and available mitigation paths
 

doc/administration/gitaly/index.md

@@ -271,7 +271,7 @@ Gitaly Cluster and [Geo](../geo/index.md) both provide redundancy. However the r
   not aware when Gitaly Cluster is used.
 - Geo provides [replication](../geo/index.md) and [disaster recovery](../geo/disaster_recovery/index.md) for
   an entire instance of GitLab. Users know when they are using Geo for
-  [replication](../geo/index.md). Geo [replicates multiple data types](../geo/replication/datatypes.md#limitations-on-replicationverification),
+  [replication](../geo/index.md). Geo [replicates multiple data types](../geo/replication/datatypes.md#replicated-data-types),
   including Git data.
 
 The following table outlines the major differences between Gitaly Cluster and Geo:

doc/user/project/issues/design_management.md

@@ -192,7 +192,7 @@ To archive multiple designs at once:
 
 ### Replicate design management data
 
-Design Management data [can be replicated](../../../administration/geo/replication/datatypes.md#limitations-on-replicationverification)
+Design Management data [can be replicated](../../../administration/geo/replication/datatypes.md#replicated-data-types)
 and in GitLab 16.1 and later it can be [verified by Geo as well](https://gitlab.com/gitlab-org/gitlab/-/issues/355660).
 
 ## Markdown and rich text editors for descriptions