diff --git a/doc/install/docker/backup.md b/doc/install/docker/backup.md
new file mode 100644
index 0000000000000000000000000000000000000000..7e33ba09db9c50210d356fd3d16a9ff12ce58789
--- /dev/null
+++ b/doc/install/docker/backup.md
@@ -0,0 +1,45 @@
+---
+stage: Systems
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Back up GitLab running in a Docker container
+
+DETAILS:
+**Tier:** Free, Premium, Ultimate
+**Offering:** Self-managed
+
+You can create a GitLab backup with:
+
+```shell
+docker exec -t <container name> gitlab-backup create
+```
+
+For more information, see [Back up and restore GitLab](../../administration/backup_restore/index.md).
+
+NOTE:
+If your GitLab configuration is provided entirely using the `GITLAB_OMNIBUS_CONFIG` environment variable
+(by using the ["Pre-configure Docker Container"](configuration.md#pre-configure-docker-container) steps),
+the configuration settings are not stored in the `gitlab.rb` file so you do not need
+to back up the `gitlab.rb` file.
+
+WARNING:
+To avoid [complicated steps](../../administration/backup_restore/troubleshooting_backup_gitlab.md#when-the-secrets-file-is-lost) when recovering
+GitLab from a backup, you should also follow the instructions in
+[Backing up the GitLab secrets file](../../administration/backup_restore/backup_gitlab.md#storing-configuration-files).
+The secrets file is stored either in the `/etc/gitlab/gitlab-secrets.json` file inside the container or in the
+`$GITLAB_HOME/config/gitlab-secrets.json` file [on the container host](installation.md#create-a-directory-for-the-volumes).
+
+## Create a database backup
+
+Before you upgrade GitLab, create a database-only backup. If you encounter issues during the GitLab upgrade, you can restore the database backup to roll back the upgrade. To create a database backup, run this command:
+
+```shell
+docker exec -t <container name> gitlab-backup create SKIP=artifacts,repositories,registry,uploads,builds,pages,lfs,packages,terraform_state
+```
+
+The backup is written to `/var/opt/gitlab/backups` which should be on a
+[volume mounted by Docker](installation.md#create-a-directory-for-the-volumes).
+
+For more information on using the backup to roll back an upgrade, see [Downgrade GitLab](upgrade.md#downgrade-gitlab).
diff --git a/doc/install/docker/backup_restore.md b/doc/install/docker/backup_restore.md
index 0560dc22b97fa7d7fdd222031a006bdc370696ea..f989443a49eec317e9cae07ff547fc2e920e7628 100644
--- a/doc/install/docker/backup_restore.md
+++ b/doc/install/docker/backup_restore.md
@@ -1,44 +1,14 @@
 ---
-stage: Systems
-group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: 'backup.md'
+remove_date: '2025-01-05'
 ---
 
-# Back up GitLab running in a Docker container
+<!-- markdownlint-disable -->
 
-DETAILS:
-**Tier:** Free, Premium, Ultimate
-**Offering:** Self-managed
+This document was moved to [another location](backup.md).
 
-You can create a GitLab backup with:
+<!-- This redirect file can be deleted after <2025-01-05>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
 
-```shell
-docker exec -t <container name> gitlab-backup create
-```
-
-Read more on how to [back up and restore GitLab](../../administration/backup_restore/index.md).
-
-NOTE:
-If configuration is provided entirely via the `GITLAB_OMNIBUS_CONFIG` environment variable
-(per the ["Pre-configure Docker Container"](configuration.md#pre-configure-docker-container) steps),
-meaning no configuration is set directly in the `gitlab.rb` file, then there is no need
-to back up the `gitlab.rb` file.
-
-WARNING:
-[Backing up the GitLab secrets file](../../administration/backup_restore/backup_gitlab.md#storing-configuration-files) is required
-to avoid [complicated steps](../../administration/backup_restore/troubleshooting_backup_gitlab.md#when-the-secrets-file-is-lost) when recovering
-GitLab from backup. The secrets file is stored at `/etc/gitlab/gitlab-secrets.json` inside the container, or
-`$GITLAB_HOME/config/gitlab-secrets.json` [on the container host](installation.md#create-a-directory-for-the-volumes).
-
-## Create a database backup
-
-Before upgrading GitLab, you should create a database-only backup. If you encounter issues during the GitLab upgrade, you can restore the database backup to roll back the upgrade. To create a database backup, run this command:
-
-```shell
-docker exec -t <container name> gitlab-backup create SKIP=artifacts,repositories,registry,uploads,builds,pages,lfs,packages,terraform_state
-```
-
-The backup is written to `/var/opt/gitlab/backups` which should be on a
-[volume mounted by Docker](installation.md#create-a-directory-for-the-volumes).
-
-For more information on using the backup to roll back an upgrade, see [Downgrade GitLab](upgrade.md#downgrade-gitlab).
diff --git a/doc/install/docker/configuration.md b/doc/install/docker/configuration.md
index f516bc3ccc7a9d539c56fc9bb8e8248f9b12b11a..f46d763ae68b3b5db4da4ff05050f7a596ac5c86 100644
--- a/doc/install/docker/configuration.md
+++ b/doc/install/docker/configuration.md
@@ -10,45 +10,51 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** Self-managed
 
-This container uses the official Linux package, so all configuration
-is done in the unique configuration file `/etc/gitlab/gitlab.rb`.
+This container uses the official Linux package, so you can use
+the unique configuration file `/etc/gitlab/gitlab.rb` to configure the instance.
+
+## Edit the configuration file
 
 To access the GitLab configuration file, you can start a shell session in the
-context of a running container. This will allow you to browse all directories
-and use your favorite text editor:
+context of a running container.
 
-```shell
-sudo docker exec -it gitlab /bin/bash
-```
+1. Start the session:
 
-You can also just edit `/etc/gitlab/gitlab.rb`:
+   ```shell
+   sudo docker exec -it gitlab /bin/bash
+   ```
 
-```shell
-sudo docker exec -it gitlab editor /etc/gitlab/gitlab.rb
-```
+   Alternatively, you can open `/etc/gitlab/gitlab.rb` in an editor directly:
+
+   ```shell
+   sudo docker exec -it gitlab editor /etc/gitlab/gitlab.rb
+   ```
 
-Once you open `/etc/gitlab/gitlab.rb` make sure to set the `external_url` to
-point to a valid URL.
+1. In your preferred text editor, open `/etc/gitlab/gitlab.rb` and update the following fields:
 
-To receive emails from GitLab you have to configure the
-[SMTP settings](https://docs.gitlab.com/omnibus/settings/smtp.html) because the GitLab Docker image doesn't
-have an SMTP server installed. You may also be interested in
-[enabling HTTPS](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
+   1. Set the `external_url` field to
+      a valid URL for your GitLab instance.
 
-After you make all the changes you want, you will need to restart the container to reconfigure GitLab:
+   1. To receive emails from GitLab, configure the
+      [SMTP settings](https://docs.gitlab.com/omnibus/settings/smtp.html). The GitLab Docker image
+      doesn't have an SMTP server pre-installed.
 
-```shell
-sudo docker restart gitlab
-```
+   1. If desired [enable HTTPS](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
 
-GitLab will reconfigure itself whenever the container starts.
-For more options about configuring GitLab, check the
+1. Save the file and restart the container to reconfigure GitLab:
+
+   ```shell
+   sudo docker restart gitlab
+   ```
+
+GitLab reconfigures itself each time the container starts.
+For more configuration options in GitLab, see the
 [configuration documentation](https://docs.gitlab.com/omnibus/settings/configuration.html).
 
 ## Pre-configure Docker container
 
 You can pre-configure the GitLab Docker image by adding the environment variable
-`GITLAB_OMNIBUS_CONFIG` to Docker run command. This variable can contain any
+`GITLAB_OMNIBUS_CONFIG` to the Docker run command. This variable can contain any
 `gitlab.rb` setting and is evaluated before the loading of the container's
 `gitlab.rb` file. This behavior allows you to configure the external GitLab URL,
 and make database configuration or any other option from the
@@ -57,7 +63,7 @@ The settings contained in `GITLAB_OMNIBUS_CONFIG` aren't written to the
 `gitlab.rb` configuration file, and are evaluated on load. To provide multiple
 settings, separate them with a colon (`;`).
 
-Here's an example that sets the external URL, enables LFS, and starts
+The following example sets the external URL, enables LFS, and starts
 the container with a [minimal shm size required for Prometheus](../docker/troubleshooting.md#devshm-mount-not-having-enough-space-in-docker-container):
 
 ```shell
@@ -105,10 +111,10 @@ You can then access your GitLab instance at `http://198.51.100.1/` and `https://
 
 ## Expose GitLab on different ports
 
-GitLab will occupy [some ports](../../administration/package_information/defaults.md)
+GitLab occupies [specific ports](../../administration/package_information/defaults.md)
 inside the container.
 
-If you want to use a different host port than `80` (HTTP), `443` (HTTPS), or `22` (SSH),
+If you want to use different host ports from the default ports `80` (HTTP), `443` (HTTPS), or `22` (SSH),
 you need to add a separate `--publish` directive to the `docker run` command.
 
 For example, to expose the web interface on the host's port `8929`, and the SSH service on
@@ -131,7 +137,7 @@ port `2424`:
    ```
 
    NOTE:
-   The format for publishing ports is `hostPort:containerPort`. Read more in the
+   The format to publish ports is `hostPort:containerPort`. Read more in the
    Docker documentation about
    [exposing incoming ports](https://docs.docker.com/network/#published-ports).
 
@@ -155,8 +161,8 @@ port `2424`:
 
    The port specified in this URL must match the port published to the host by Docker.
    Additionally, if the NGINX listen port is not explicitly set in
-   `nginx['listen_port']`, it will be pulled from the `external_url`.
-   For more information see the [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html).
+   `nginx['listen_port']`, the `external_url` is used instead.
+   For more information, see the [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html).
 
 1. Set the SSH port:
 
@@ -170,15 +176,15 @@ port `2424`:
    gitlab-ctl reconfigure
    ```
 
-Following the above example, you will be able to reach GitLab from your
-web browser under `<hostIP>:8929` and push using SSH under the port `2424`.
+Following the above example, your web browser can reach your GitLab instance
+at `<hostIP>:8929` and push over SSH on port `2424`.
 
-A `docker-compose.yml` example that uses different ports can be found in the
+You can see a `docker-compose.yml` example that uses different ports in the
 [Docker compose](installation.md#install-gitlab-by-using-docker-compose) section.
 
 ## Configure multiple database connections
 
-In [GitLab 16.0](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/6850),
+Starting in [GitLab 16.0](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/6850),
 GitLab defaults to using two database connections that point to the same PostgreSQL database.
 
 If, for any reason, you wish to switch back to single database connection:
@@ -197,12 +203,12 @@ If, for any reason, you wish to switch back to single database connection:
 
 1. Restart the container:
 
-```shell
-sudo docker restart gitlab
-```
+   ```shell
+   sudo docker restart gitlab
+   ```
 
-## Recommended next steps
+## Next steps
 
-After configuring your installation, consider taking the
+After you configure your installation, consider taking the
 [recommended next steps](../next_steps.md), including authentication options
 and sign-up restrictions.
diff --git a/doc/install/docker/troubleshooting.md b/doc/install/docker/troubleshooting.md
index f61998d569de1f6bceba88b914b0d86b430359e1..2fa446dee39d4ec4bfdec4efa04afea7cd090764 100644
--- a/doc/install/docker/troubleshooting.md
+++ b/doc/install/docker/troubleshooting.md
@@ -10,10 +10,12 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** Self-managed
 
-When installing GitLab in a Docker container, you might encounter the following issues.
+When installing GitLab in a Docker container, you might encounter the following problems.
 
 ## Diagnose potential problems
 
+The following commands are useful when troubleshooting your GitLab instance in a Docker container:
+
 Read container logs:
 
 ```shell
@@ -26,14 +28,13 @@ Enter running container:
 sudo docker exec -it gitlab /bin/bash
 ```
 
-From within the container you can administer the GitLab container as you would
-usually administer a [Linux package installation](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md).
+You can administer the GitLab container from within the container as you would
+administer a [Linux package installation](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md).
 
 ## 500 Internal Error
 
-When updating the Docker image you may encounter an issue where all paths
-display a `500` page. If this occurs, restart the container to try to rectify the
-issue:
+When updating the Docker image, you may encounter an issue where all paths
+display a `500` page. If this occurs, restart the container:
 
 ```shell
 sudo docker restart gitlab
@@ -41,9 +42,9 @@ sudo docker restart gitlab
 
 ## Permission problems
 
-When updating from older GitLab Docker images you might encounter permission
-problems. This happens when users in previous images were not
-preserved correctly. There's script that fixes permissions for all files.
+When updating from older GitLab Docker images, you might encounter permission
+problems. This happens when user permissions in previous images were not
+preserved correctly. There's a script that fixes permissions for all files.
 
 To fix your container, execute `update-permissions` and restart the
 container afterwards:
@@ -55,7 +56,7 @@ sudo docker restart gitlab
 
 ## Error executing action run on resource `ruby_block`
 
-This error occurs when using Docker Toolbox with VirtualBox on Windows or Mac,
+This error occurs when using Docker Toolbox with Oracle VirtualBox on Windows or Mac,
 and making use of Docker volumes:
 
 ```plaintext
@@ -63,16 +64,16 @@ Error executing action run on resource ruby_block[directory resource: /data/GitL
 ```
 
 The `/c/Users` volume is mounted as a
-VirtualBox Shared Folder, and does not support the all POSIX file system features.
+VirtualBox Shared Folder, and does not support all POSIX file system features.
 The directory ownership and permissions cannot be changed without remounting, and
 GitLab fails.
 
-Our recommendation is to switch to using the native Docker install for your
+Switch to using the native Docker install for your
 platform, instead of using Docker Toolbox.
 
 If you cannot use the native Docker install (Windows 10 Home Edition, or Windows 7/8),
-then an alternative solution is to set up NFS mounts instead of VirtualBox shares for
-Docker Toolbox's boot2docker.
+an alternative solution is to set up NFS mounts instead of VirtualBox shares for
+the Docker Toolbox Boot2docker.
 
 ## Linux ACL issues
 
@@ -95,20 +96,20 @@ default:mask::rwx
 default:other::r-x
 ```
 
-If these are not correct, set them with:
+If these values are not correct, set them with:
 
 ```shell
 sudo setfacl -mR default:group:docker:rwx $GITLAB_HOME
 ```
 
-The default group is `docker`. If you changed the group, be sure to update your
-commands.
+The default group is named `docker`. If you changed the group name, you need to adjust the
+command.
 
 ## `/dev/shm` mount not having enough space in Docker container
 
-GitLab comes with a Prometheus metrics endpoint at `/-/metrics` to expose a
-variety of statistics on the health and performance of GitLab. The files
-required for this gets written to a temporary file system (like `/run` or
+GitLab comes with a Prometheus metrics endpoint at `/-/metrics` to expose
+statistics about the health and performance of GitLab. The files
+required for this are written to a temporary file system (like `/run` or
 `/dev/shm`).
 
 By default, Docker allocates 64 MB to the shared memory directory (mounted at
@@ -125,11 +126,11 @@ writing value to /dev/shm/gitlab/sidekiq/histogram_sidekiq_0-0.db failed with un
 writing value to /dev/shm/gitlab/sidekiq/histogram_sidekiq_0-0.db failed with unmapped file
 ```
 
-Other than disabling the Prometheus Metrics from the **Admin** area, the recommended
-solution to fix this problem is to [install](configuration.md#pre-configure-docker-container) with shared memory set to at least 256 MB.
-If using `docker run`, this can be done by passing the flag `--shm-size 256m`.
-If using a `docker-compose.yml` file, the `shm_size` key can be used for this
-purpose.
+While you can turn off the Prometheus Metrics in the **Admin** area, the recommended
+solution to fix this problem is to
+[install](configuration.md#pre-configure-docker-container) with shared memory set to at least 256 MB.
+If you use `docker run`, you can pass the flag `--shm-size 256m`.
+If you use a `docker-compose.yml` file, you can set the `shm_size` key.
 
 ## Docker containers exhausts space due to the `json-file`
 
@@ -154,9 +155,9 @@ can't create Thread: Operation not permitted
 ```
 
 This error occurs when running a container built with newer `glibc` versions on a
-[host that doesn't have support for the new clone3 function](https://github.com/moby/moby/issues/42680). In GitLab 16.0 and later, the container image includes
-the Ubuntu 22.04 Linux package which is built with this newer `glibc`.
+[host that doesn't support the clone3 function](https://github.com/moby/moby/issues/42680). In GitLab 16.0 and later, the container image includes
+the Ubuntu 22.04 Linux package, which is built with newer `glibc` versions.
 
-This problem is fixed with newer container runtime tools like [Docker 20.10.10](https://github.com/moby/moby/pull/42836).
+This problem does not occur in newer container runtime tools like [Docker 20.10.10](https://github.com/moby/moby/pull/42836).
 
 To resolve this issue, update Docker to version 20.10.10 or later.
diff --git a/doc/install/docker/upgrade.md b/doc/install/docker/upgrade.md
index 436afa0e58ce89fd2469c2f4686619eb01f4357c..75b30eda300a3718d23668e9bc8d0289559ffa1a 100644
--- a/doc/install/docker/upgrade.md
+++ b/doc/install/docker/upgrade.md
@@ -15,9 +15,9 @@ image tag.
 
 ## Upgrade GitLab using Docker Engine
 
-To upgrade GitLab that was [installed using Docker Engine](installation.md#install-gitlab-by-using-docker-engine):
+To upgrade a GitLab instance that was [installed using Docker Engine](installation.md#install-gitlab-by-using-docker-engine):
 
-1. Take a [backup](backup_restore.md). As a minimum, back up [the database](backup_restore.md#create-a-database-backup) and
+1. Create a [backup](backup.md). As a minimum, back up [the database](backup.md#create-a-database-backup) and
    the GitLab secrets file.
 
 1. Stop the running container:
@@ -44,7 +44,7 @@ To upgrade GitLab that was [installed using Docker Engine](installation.md#insta
    echo $GITLAB_HOME
    ```
 
-1. Create the container once again with the
+1. Create the container again with the
    [previously specified](installation.md#install-gitlab-by-using-docker-engine) options:
 
    ```shell
@@ -60,16 +60,16 @@ To upgrade GitLab that was [installed using Docker Engine](installation.md#insta
    gitlab/gitlab-ee:<version>-ee.0
    ```
 
-On the first run, GitLab will reconfigure and upgrade itself.
+On the first run, GitLab reconfigures and upgrades itself.
 
 Refer to the GitLab [Upgrade recommendations](../../policy/maintenance.md#upgrade-recommendations)
-when upgrading between versions.
+when upgrading to different versions.
 
 ## Upgrade GitLab using Docker compose
 
-To upgrade GitLab that was [installed using Docker Compose](installation.md#install-gitlab-by-using-docker-compose):
+To upgrade a GitLab instance that was [installed using Docker Compose](installation.md#install-gitlab-by-using-docker-compose):
 
-1. Take a [backup](backup_restore.md). As a minimum, back up [the database](backup_restore.md#create-a-database-backup) and
+1. Take a [backup](backup.md). As a minimum, back up [the database](backup.md#create-a-database-backup) and
    the GitLab secrets file.
 1. Edit `docker-compose.yml` and change the version to pull.
 1. Download the newest release and upgrade your GitLab instance:
@@ -81,38 +81,38 @@ To upgrade GitLab that was [installed using Docker Compose](installation.md#inst
 
 ## Convert Community Edition to Enterprise Edition
 
-You can convert an existing Docker-based GitLab Community Edition (CE) container
+You can convert an existing GitLab Community Edition (CE) container for Docker
 to a GitLab [Enterprise Edition](https://about.gitlab.com/pricing/) (EE) container
 using the same approach as [upgrading the version](upgrade.md).
 
 We recommend you convert from the same version of CE to EE (for example, CE 14.1 to EE 14.1).
-This is not explicitly necessary, and any standard upgrade (for example, CE 14.0 to EE 14.1) should work.
-The following steps assume that you are upgrading the same version.
+However, this is not required. Any standard upgrade (for example, CE 14.0 to EE 14.1) should work.
+The following steps assume that you are converting to the same version.
 
-1. Take a [backup](backup_restore.md). As a minimum, back up [the database](backup_restore.md#create-a-database-backup) and
+1. Take a [backup](backup.md). At minimum, back up [the database](backup.md#create-a-database-backup) and
    the GitLab secrets file.
 
 1. Stop the current CE container, and remove or rename it.
 
 1. To create a new container with GitLab EE,
    replace `ce` with `ee` in your `docker run` command or `docker-compose.yml` file.
-   However, reuse the CE container name, port and file mappings, and version.
+   Reuse the CE container name, port mappings, file mappings, and version.
 
 ## Downgrade GitLab
 
-WARNING:
-You must at least have a database backup created under the exact same version and edition you are downgrading to.
-Restoring the backup is required to revert the schema changes (migrations) made as part of the upgrade.
 The restore overwrites all newer GitLab database content with the older state.
-We can therefore only recommend a downgrade,
-if for example post-upgrade tests reveal problems that can not be resolved quickly.
+A downgrade is only recommended where necessary. For example, if post-upgrade tests reveal problems that cannot be resolved quickly.
+
+WARNING:
+You must have at least a database backup created with the exact same version and edition you are downgrading to.
+The backup is required to revert the schema changes (migrations) made during the upgrade.
 
 To downgrade GitLab shortly after an upgrade:
 
 1. Follow the upgrade procedure, by [specifying an earlier version](installation.md#find-the-gitlab-version-and-edition-to-use)
    than you have installed.
 
-1. Restore the [database backup you made](backup_restore.md#create-a-database-backup) before the upgrade.
+1. Restore the [database backup you made](backup.md#create-a-database-backup) before the upgrade.
 
    - [Follow the restore steps for Docker images](../../administration/backup_restore/restore_gitlab.md#restore-for-docker-image-and-gitlab-helm-chart-installations), including
      stopping Puma and Sidekiq. Only the database must be restored, so add