Updates to Geo and DR pages

doc/administration/geo/replication/container_registry.md

@@ -11,7 +11,7 @@ You can set up a container registry on your **secondary** Geo site that mirrors
 NOTE:
 The container registry replication is used only for disaster recovery purposes. We do not recommend
 pulling the container registry data from the secondary. For a feature proposal to implement it in the
-future, see [Geo: Accelerate container images by serving read request from secondary site](https://gitlab.com/gitlab-org/gitlab/-/issues/365864) for details.
+future, see [Geo: Accelerate container images by serving read request from secondary site](https://gitlab.com/gitlab-org/gitlab/-/issues/365864) for details. You or your GitLab representative are encouraged to upvote this feature to register your interest.
 
 ## Supported container registries
 

doc/administration/geo/replication/faq.md

@@ -44,12 +44,12 @@ Read the documentation for [Disaster Recovery](../disaster_recovery/index.md).
 
 ## What data is replicated to a **secondary** site?
 
-We currently replicate project repositories, LFS objects, generated
-attachments and avatars, and the whole database. This means information such as user accounts,
+We currently replicate the whole rails database, project repositories, LFS objects, generated
+attachments, avatars and more. This means information such as user accounts,
 issues, merge requests, groups, and project data are available for
 query.
 
-For more details, see the [supported Geo data types](datatypes.md).
+For a comprehensive list of data replicated by Geo, see the [supported Geo data types page](datatypes.md).
 
 ## Can I `git push` to a **secondary** site?
 
@@ -65,10 +65,26 @@ connectivity between your sites, and your hardware.
 
 That's totally fine. We use HTTP(s) to fetch repository changes from the **primary** site to all **secondary** sites.
 
-## Is this possible to set up a container registry for a **secondary** site that mirrors the one on the **primary** site?
+## Is it possible to set up a container registry for a **secondary** site that mirrors the one on the **primary** site?
 
-Yes. See [container registry for a **secondary** site](container_registry.md).
+Yes, however, we only support this for Disaster Recovery scenarios. See [container registry for a **secondary** site](container_registry.md).
 
 ## Can you sign in to a secondary site?
 
 Yes, but secondary sites receive all authentication data (like user accounts and logins) from the primary instance. This means you are re-directed to the primary for authentication and then routed back.
+
+## Do all Geo sites need to be the same as the primary?
+
+No, Geo sites can be based on different reference architectures. For example, you can have the primary site based on a 3K reference architecture, one secondary site based 3K reference architecture, and another one based on a 1K reference architecture.
+
+## Does Geo replicate archived projects?
+
+Yes, provided they are not excluded through [selective sync](../replication/configuration.md#selective-synchronization).
+
+## Does Geo replicate personal projects?
+
+Yes, provided they are not excluded through [selective sync](../replication/configuration.md#selective-synchronization).
+
+## Are delayed deletion projects replicated to secondary sites?
+
+Yes, projects scheduled for deletion by [delayed deletion](../../settings/visibility_and_access_controls.md#delayed-project-deletion), but are yet to be permanently deleted, are replicated to secondary sites.

doc/administration/geo/replication/usage.md

@@ -10,6 +10,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 After you set up the [database replication and configure the Geo nodes](../index.md#setup-instructions), use your closest GitLab site as you would do with the primary one.
 
+## Git operations
+
 You can push directly to a **secondary** site (for both HTTP, SSH including
 Git LFS), and the request is proxied to the primary site instead.
 
@@ -34,6 +36,12 @@ for Unix-like operating systems or `_netrc` for Windows. In that case, the crede
 are stored as a plain text. If you're looking for a more secure way to store credentials,
 you can use [Git Credential Storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage).
 
+## Web user interface
+
+The web user interface on the **secondary** site is read/write. As a user, all actions permitted on the **primary** site can be performed on the **secondary** site without limitations.
+
+Web interface access requests on the **secondary** sites are automatically and transparently proxied to the **primary** site.
+
 ## Fetch Go modules from Geo secondary sites
 
 Go modules can be pulled from secondary sites, with a number of limitations: