Add latest changes from gitlab-org/gitlab@master

24 files changed, 653 insertions, 635 deletions

diff --git a/doc/administration/backup_restore/backup_gitlab.md b/doc/administration/backup_restore/backup_gitlab.md
index 707b209faf3..40f93a2b7de 100644
--- a/doc/administration/backup_restore/backup_gitlab.md
+++ b/doc/administration/backup_restore/backup_gitlab.md
@@ -150,8 +150,8 @@ You may also want to back up any TLS keys and certificates (`/etc/gitlab/ssl`, `
 [SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079)
 to avoid man-in-the-middle attack warnings if you have to perform a full machine restore.
 
-In the unlikely event that the secrets file is lost, see the
-[troubleshooting section](#when-the-secrets-file-is-lost).
+In the unlikely event that the secrets file is lost, see
+[When the secrets file is lost](../../administration/backup_restore/troubleshooting_backup_gitlab.md#when-the-secrets-file-is-lost).
 
 ### Other data
 
@@ -1452,618 +1452,3 @@ There are a few possible downsides to this:
 
 There is an **experimental** script that attempts to automate this process in
 [the Geo team Runbooks project](https://gitlab.com/gitlab-org/geo-team/runbooks/-/tree/main/experimental-online-backup-through-rsync).
-
-## Troubleshooting
-
-The following are possible problems you might encounter, along with potential
-solutions.
-
-### When the secrets file is lost
-
-If you didn't [back up the secrets file](#storing-configuration-files), you
-must complete several steps to get GitLab working properly again.
-
-The secrets file is responsible for storing the encryption key for the columns
-that contain required, sensitive information. If the key is lost, GitLab can't
-decrypt those columns, preventing access to the following items:
-
-- [CI/CD variables](../../ci/variables/index.md)
-- [Kubernetes / GCP integration](../../user/infrastructure/clusters/index.md)
-- [Custom Pages domains](../../user/project/pages/custom_domains_ssl_tls_certification/index.md)
-- [Project error tracking](../../operations/error_tracking.md)
-- [Runner authentication](../../ci/runners/index.md)
-- [Project mirroring](../../user/project/repository/mirror/index.md)
-- [Integrations](../../user/project/integrations/index.md)
-- [Web hooks](../../user/project/integrations/webhooks.md)
-
-In cases like CI/CD variables and runner authentication, you can experience
-unexpected behaviors, such as:
-
-- Stuck jobs.
-- 500 errors.
-
-In this case, you must reset all the tokens for CI/CD variables and
-runner authentication, which is described in more detail in the following
-sections. After resetting the tokens, you should be able to visit your project
-and the jobs begin running again.
-
-WARNING:
-The steps in this section can potentially lead to **data loss** on the above listed items.
-Consider opening a [Support Request](https://support.gitlab.com/hc/en-us/requests/new) if you're a Premium or Ultimate customer.
-
-#### Verify that all values can be decrypted
-
-You can determine if your database contains values that can't be decrypted by using a
-[Rake task](../raketasks/check.md#verify-database-values-can-be-decrypted-using-the-current-secrets).
-
-#### Take a backup
-
-You must directly modify GitLab data to work around your lost secrets file.
-
-WARNING:
-Be sure to create a full database backup before attempting any changes.
-
-#### Disable user two-factor authentication (2FA)
-
-Users with 2FA enabled can't sign in to GitLab. In that case, you must
-[disable 2FA for everyone](../../security/two_factor_authentication.md#for-all-users),
-after which users must reactivate 2FA.
-
-#### Reset CI/CD variables
-
-1. Enter the database console:
-
-   For the Linux package (Omnibus) GitLab 14.1 and earlier:
-
-   ```shell
-   sudo gitlab-rails dbconsole
-   ```
-
-   For the Linux package (Omnibus) GitLab 14.2 and later:
-
-   ```shell
-   sudo gitlab-rails dbconsole --database main
-   ```
-
-   For self-compiled installations, GitLab 14.1 and earlier:
-
-   ```shell
-   sudo -u git -H bundle exec rails dbconsole -e production
-   ```
-
-   For self-compiled installations, GitLab 14.2 and later:
-
-   ```shell
-   sudo -u git -H bundle exec rails dbconsole -e production --database main
-   ```
-
-1. Examine the `ci_group_variables` and `ci_variables` tables:
-
-   ```sql
-   SELECT * FROM public."ci_group_variables";
-   SELECT * FROM public."ci_variables";
-   ```
-
-   These are the variables that you need to delete.
-
-1. Delete all variables:
-
-   ```sql
-   DELETE FROM ci_group_variables;
-   DELETE FROM ci_variables;
-   ```
-
-1. If you know the specific group or project from which you wish to delete variables, you can include a `WHERE` statement to specify that in your `DELETE`:
-
-   ```sql
-   DELETE FROM ci_group_variables WHERE group_id = <GROUPID>;
-   DELETE FROM ci_variables WHERE project_id = <PROJECTID>;
-   ```
-
-You may need to reconfigure or restart GitLab for the changes to take effect.
-
-#### Reset runner registration tokens
-
-1. Enter the database console:
-
-   For the Linux package (Omnibus) GitLab 14.1 and earlier:
-
-   ```shell
-   sudo gitlab-rails dbconsole
-   ```
-
-   For the Linux package (Omnibus) GitLab 14.2 and later:
-
-   ```shell
-   sudo gitlab-rails dbconsole --database main
-   ```
-
-   For self-compiled installations, GitLab 14.1 and earlier:
-
-   ```shell
-   sudo -u git -H bundle exec rails dbconsole -e production
-   ```
-
-   For self-compiled installations, GitLab 14.2 and later:
-
-   ```shell
-   sudo -u git -H bundle exec rails dbconsole -e production --database main
-   ```
-
-1. Clear all tokens for projects, groups, and the entire instance:
-
-   WARNING:
-   The final `UPDATE` operation stops the runners from being able to pick
-   up new jobs. You must register new runners.
-
-   ```sql
-   -- Clear project tokens
-   UPDATE projects SET runners_token = null, runners_token_encrypted = null;
-   -- Clear group tokens
-   UPDATE namespaces SET runners_token = null, runners_token_encrypted = null;
-   -- Clear instance tokens
-   UPDATE application_settings SET runners_registration_token_encrypted = null;
-   -- Clear key used for JWT authentication
-   -- This may break the $CI_JWT_TOKEN job variable:
-   -- https://gitlab.com/gitlab-org/gitlab/-/issues/325965
-   UPDATE application_settings SET encrypted_ci_jwt_signing_key = null;
-   -- Clear runner tokens
-   UPDATE ci_runners SET token = null, token_encrypted = null;
-   ```
-
-#### Reset pending pipeline jobs
-
-1. Enter the database console:
-
-   For the Linux package (Omnibus) GitLab 14.1 and earlier:
-
-   ```shell
-   sudo gitlab-rails dbconsole
-   ```
-
-   For the Linux package (Omnibus) GitLab 14.2 and later:
-
-   ```shell
-   sudo gitlab-rails dbconsole --database main
-   ```
-
-   For self-compiled installations, GitLab 14.1 and earlier:
-
-   ```shell
-   sudo -u git -H bundle exec rails dbconsole -e production
-   ```
-
-   For self-compiled installations, GitLab 14.2 and later:
-
-   ```shell
-   sudo -u git -H bundle exec rails dbconsole -e production --database main
-   ```
-
-1. Clear all the tokens for pending jobs:
-
-   For GitLab 15.3 and earlier:
-
-   ```sql
-   -- Clear build tokens
-   UPDATE ci_builds SET token = null, token_encrypted = null;
-   ```
-
-   For GitLab 15.4 and later:
-
-   ```sql
-   -- Clear build tokens
-   UPDATE ci_builds SET token_encrypted = null;
-   ```
-
-A similar strategy can be employed for the remaining features. By removing the
-data that can't be decrypted, GitLab can be returned to operation, and the
-lost data can be manually replaced.
-
-#### Fix integrations and webhooks
-
-If you've lost your secrets, the [integrations settings](../../user/project/integrations/index.md)
-and [webhooks settings](../../user/project/integrations/webhooks.md) pages might display `500` error messages. Lost secrets might also produce `500` errors when you try to access a repository in a project with a previously configured integration or webhook.
-
-The fix is to truncate the affected tables (those containing encrypted columns).
-This deletes all your configured integrations, webhooks, and related metadata.
-You should verify that the secrets are the root cause before deleting any data.
-
-1. Enter the database console:
-
-   For the Linux package (Omnibus) GitLab 14.1 and earlier:
-
-   ```shell
-   sudo gitlab-rails dbconsole
-   ```
-
-   For the Linux package (Omnibus) GitLab 14.2 and later:
-
-   ```shell
-   sudo gitlab-rails dbconsole --database main
-   ```
-
-   For self-compiled installations, GitLab 14.1 and earlier:
-
-   ```shell
-   sudo -u git -H bundle exec rails dbconsole -e production
-   ```
-
-   For self-compiled installations, GitLab 14.2 and later:
-
-   ```shell
-   sudo -u git -H bundle exec rails dbconsole -e production --database main
-   ```
-
-1. Truncate the following tables:
-
-   ```sql
-   -- truncate web_hooks table
-   TRUNCATE integrations, chat_names, issue_tracker_data, jira_tracker_data, slack_integrations, web_hooks, zentao_tracker_data, web_hook_logs CASCADE;
-   ```
-
-### Container registry push failures after restoring from a backup
-
-If you use the [container registry](../../user/packages/container_registry/index.md),
-pushes to the registry may fail after restoring your backup on a Linux package (Omnibus)
-instance after restoring the registry data.
-
-These failures mention permission issues in the registry logs, similar to:
-
-```plaintext
-level=error
-msg="response completed with error"
-err.code=unknown
-err.detail="filesystem: mkdir /var/opt/gitlab/gitlab-rails/shared/registry/docker/registry/v2/repositories/...: permission denied"
-err.message="unknown error"
-```
-
-This issue is caused by the restore running as the unprivileged user `git`,
-which is unable to assign the correct ownership to the registry files during
-the restore process ([issue #62759](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/62759 "Incorrect permissions on registry filesystem after restore")).
-
-To get your registry working again:
-
-```shell
-sudo chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/docker
-```
-
-If you changed the default file system location for the registry, run `chown`
-against your custom location, instead of `/var/opt/gitlab/gitlab-rails/shared/registry/docker`.
-
-### Backup fails to complete with Gzip error
-
-When running the backup, you may receive a Gzip error message:
-
-```shell
-sudo /opt/gitlab/bin/gitlab-backup create
-...
-Dumping ...
-...
-gzip: stdout: Input/output error
-
-Backup failed
-```
-
-If this happens, examine the following:
-
-- Confirm there is sufficient disk space for the Gzip operation. It's not uncommon for backups that
-  use the [default strategy](#backup-strategy-option) to require half the instance size
-  in free disk space during backup creation.
-- If NFS is being used, check if the mount option `timeout` is set. The
-  default is `600`, and changing this to smaller values results in this error.
-
-### Backup fails with `File name too long` error
-
-During backup, you can get the `File name too long` error ([issue #354984](https://gitlab.com/gitlab-org/gitlab/-/issues/354984)). For example:
-
-```plaintext
-Problem: <class 'OSError: [Errno 36] File name too long:
-```
-
-This problem stops the backup script from completing. To fix this problem, you must truncate the file names causing the problem. A maximum of 246 characters, including the file extension, is permitted.
-
-WARNING:
-The steps in this section can potentially lead to **data loss**. All steps must be followed strictly in the order given.
-Consider opening a [Support Request](https://support.gitlab.com/hc/en-us/requests/new) if you're a Premium or Ultimate customer.
-
-Truncating file names to resolve the error involves:
-
-- Cleaning up remote uploaded files that aren't tracked in the database.
-- Truncating the file names in the database.
-- Rerunning the backup task.
-
-#### Clean up remote uploaded files
-
-A [known issue](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45425) caused object store uploads to remain after a parent resource was deleted. This issue was [resolved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18698).
-
-To fix these files, you must clean up all remote uploaded files that are in the storage but not tracked in the `uploads` database table.
-
-1. List all the object store upload files that can be moved to a lost and found directory if they don't exist in the GitLab database:
-
-   ```shell
-   bundle exec rake gitlab:cleanup:remote_upload_files RAILS_ENV=production
-   ```
-
-1. If you are sure you want to delete these files and remove all non-referenced uploaded files, run:
-
-   WARNING:
-   The following action is **irreversible**.
-
-   ```shell
-   bundle exec rake gitlab:cleanup:remote_upload_files RAILS_ENV=production DRY_RUN=false
-   ```
-
-#### Truncate the file names referenced by the database
-
-You must truncate the files referenced by the database that are causing the problem. The file names referenced by the database are stored:
-
-- In the `uploads` table.
-- In the references found. Any reference found from other database tables and columns.
-- On the file system.
-
-Truncate the file names in the `uploads` table:
-
-1. Enter the database console:
-
-   For the Linux package (Omnibus) GitLab 14.2 and later:
-
-   ```shell
-   sudo gitlab-rails dbconsole --database main
-   ```
-
-   For the Linux package (Omnibus) GitLab 14.1 and earlier:
-
-   ```shell
-   sudo gitlab-rails dbconsole
-   ```
-
-   For self-compiled installations, GitLab 14.2 and later:
-
-   ```shell
-   sudo -u git -H bundle exec rails dbconsole -e production --database main
-   ```
-
-   For self-compiled installations, GitLab 14.1 and earlier:
-
-   ```shell
-   sudo -u git -H bundle exec rails dbconsole -e production
-   ```
-
-1. Search the `uploads` table for file names longer than 246 characters:
-
-   The following query selects the `uploads` records with file names longer than 246 characters in batches of 0 to 10000. This improves the performance on large GitLab instances with tables having thousand of records.
-
-      ```sql
-      CREATE TEMP TABLE uploads_with_long_filenames AS
-      SELECT ROW_NUMBER() OVER(ORDER BY id) row_id, id, path
-      FROM uploads AS u
-      WHERE LENGTH((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1]) > 246;
-
-      CREATE INDEX ON uploads_with_long_filenames(row_id);
-
-      SELECT
-         u.id,
-         u.path,
-         -- Current file name
-         (regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1] AS current_filename,
-         -- New file name
-         CONCAT(
-            LEFT(SPLIT_PART((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1], '.', 1), 242),
-            COALESCE(SUBSTRING((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1] FROM '\.(?:.(?!\.))+$'))
-         ) AS new_filename,
-         -- New path
-         CONCAT(
-            COALESCE((regexp_match(u.path, '(.*\/).*'))[1], ''),
-            CONCAT(
-               LEFT(SPLIT_PART((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1], '.', 1), 242),
-               COALESCE(SUBSTRING((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1] FROM '\.(?:.(?!\.))+$'))
-            )
-         ) AS new_path
-      FROM uploads_with_long_filenames AS u
-      WHERE u.row_id > 0 AND u.row_id <= 10000;
-      ```
-
-      Output example:
-
-      ```postgresql
-      -[ RECORD 1 ]----+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-      id               | 34
-      path             | public/@hashed/loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisitloremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisit.txt
-      current_filename | loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisitloremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisit.txt
-      new_filename     | loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisitloremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelits.txt
-      new_path         | public/@hashed/loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisitloremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelits.txt
-      ```
-
-      Where:
-
-      - `current_filename`: a file name that is currently more than 246 characters long.
-      - `new_filename`: a file name that has been truncated to 246 characters maximum.
-      - `new_path`: new path considering the `new_filename` (truncated).
-
-   After you validate the batch results, you must change the batch size (`row_id`) using the following sequence of numbers (10000 to 20000). Repeat this process until you reach the last record in the `uploads` table.
-
-1. Rename the files found in the `uploads` table from long file names to new truncated file names. The following query rolls back the update so you can check the results safely in a transaction wrapper:
-
-   ```sql
-   CREATE TEMP TABLE uploads_with_long_filenames AS
-   SELECT ROW_NUMBER() OVER(ORDER BY id) row_id, path, id
-   FROM uploads AS u
-   WHERE LENGTH((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1]) > 246;
-
-   CREATE INDEX ON uploads_with_long_filenames(row_id);
-
-   BEGIN;
-   WITH updated_uploads AS (
-      UPDATE uploads
-      SET
-         path =
-         CONCAT(
-            COALESCE((regexp_match(updatable_uploads.path, '(.*\/).*'))[1], ''),
-            CONCAT(
-               LEFT(SPLIT_PART((regexp_match(updatable_uploads.path, '[^\\/:*?"<>|\r\n]+$'))[1], '.', 1), 242),
-               COALESCE(SUBSTRING((regexp_match(updatable_uploads.path, '[^\\/:*?"<>|\r\n]+$'))[1] FROM '\.(?:.(?!\.))+$'))
-            )
-         )
-      FROM
-         uploads_with_long_filenames AS updatable_uploads
-      WHERE
-         uploads.id = updatable_uploads.id
-      AND updatable_uploads.row_id > 0 AND updatable_uploads.row_id  <= 10000
-      RETURNING uploads.*
-   )
-   SELECT id, path FROM updated_uploads;
-   ROLLBACK;
-   ```
-
-   After you validate the batch update results, you must change the batch size (`row_id`) using the following sequence of numbers (10000 to 20000). Repeat this process until you reach the last record in the `uploads` table.
-
-1. Validate that the new file names from the previous query are the expected ones. If you are sure you want to truncate the records found in the previous step to 246 characters, run the following:
-
-   WARNING:
-   The following action is **irreversible**.
-
-   ```sql
-   CREATE TEMP TABLE uploads_with_long_filenames AS
-   SELECT ROW_NUMBER() OVER(ORDER BY id) row_id, path, id
-   FROM uploads AS u
-   WHERE LENGTH((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1]) > 246;
-
-   CREATE INDEX ON uploads_with_long_filenames(row_id);
-
-   UPDATE uploads
-   SET
-   path =
-      CONCAT(
-         COALESCE((regexp_match(updatable_uploads.path, '(.*\/).*'))[1], ''),
-         CONCAT(
-            LEFT(SPLIT_PART((regexp_match(updatable_uploads.path, '[^\\/:*?"<>|\r\n]+$'))[1], '.', 1), 242),
-            COALESCE(SUBSTRING((regexp_match(updatable_uploads.path, '[^\\/:*?"<>|\r\n]+$'))[1] FROM '\.(?:.(?!\.))+$'))
-         )
-      )
-   FROM
-   uploads_with_long_filenames AS updatable_uploads
-   WHERE
-   uploads.id = updatable_uploads.id
-   AND updatable_uploads.row_id > 0 AND updatable_uploads.row_id  <= 10000;
-   ```
-
-   After you finish the batch update, you must change the batch size (`updatable_uploads.row_id`) using the following sequence of numbers (10000 to 20000). Repeat this process until you reach the last record in the `uploads` table.
-
-Truncate the file names in the references found:
-
-1. Check if those records are referenced somewhere. One way to do this is to dump the database and search for the parent directory name and file name:
-
-   1. To dump your database, you can use the following command as an example:
-
-      ```shell
-      pg_dump -h /var/opt/gitlab/postgresql/ -d gitlabhq_production > gitlab-dump.tmp
-      ```
-
-   1. Then you can search for the references using the `grep` command. Combining the parent directory and the file name can be a good idea. For example:
-
-      ```shell
-      grep public/alongfilenamehere.txt gitlab-dump.tmp
-      ```
-
-1. Replace those long file names using the new file names obtained from querying the `uploads` table.
-
-Truncate the file names on the file system. You must manually rename the files in your file system to the new file names obtained from querying the `uploads` table.
-
-#### Re-run the backup task
-
-After following all the previous steps, re-run the backup task.
-
-### Restoring database backup fails when `pg_stat_statements` was previously enabled
-
-The GitLab backup of the PostgreSQL database includes all SQL statements required to enable extensions that were
-previously enabled in the database.
-
-The `pg_stat_statements` extension can only be enabled or disabled by a PostgreSQL user with `superuser` role.
-As the restore process uses a database user with limited permissions, it can't execute the following SQL statements:
-
-```sql
-DROP EXTENSION IF EXISTS pg_stat_statements;
-CREATE EXTENSION IF NOT EXISTS pg_stat_statements WITH SCHEMA public;
-```
-
-When trying to restore the backup in a PostgreSQL instance that doesn't have the `pg_stats_statements` extension,
-the following error message is displayed:
-
-```plaintext
-ERROR: permission denied to create extension "pg_stat_statements"
-HINT: Must be superuser to create this extension.
-ERROR: extension "pg_stat_statements" does not exist
-```
-
-When trying to restore in an instance that has the `pg_stats_statements` extension enabled, the cleaning up step
-fails with an error message similar to the following:
-
-```plaintext
-rake aborted!
-ActiveRecord::StatementInvalid: PG::InsufficientPrivilege: ERROR: must be owner of view pg_stat_statements
-/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:42:in `block (4 levels) in <top (required)>'
-/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:41:in `each'
-/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:41:in `block (3 levels) in <top (required)>'
-/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:71:in `block (3 levels) in <top (required)>'
-/opt/gitlab/embedded/bin/bundle:23:in `load'
-/opt/gitlab/embedded/bin/bundle:23:in `<main>'
-Caused by:
-PG::InsufficientPrivilege: ERROR: must be owner of view pg_stat_statements
-/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:42:in `block (4 levels) in <top (required)>'
-/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:41:in `each'
-/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:41:in `block (3 levels) in <top (required)>'
-/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:71:in `block (3 levels) in <top (required)>'
-/opt/gitlab/embedded/bin/bundle:23:in `load'
-/opt/gitlab/embedded/bin/bundle:23:in `<main>'
-Tasks: TOP => gitlab:db:drop_tables
-(See full trace by running task with --trace)
-```
-
-#### Prevent the dump file to include `pg_stat_statements`
-
-To prevent the inclusion of the extension in the PostgreSQL dump file that is part of the backup bundle,
-enable the extension in any schema except the `public` schema:
-
-```sql
-CREATE SCHEMA adm;
-CREATE EXTENSION pg_stat_statements SCHEMA adm;
-```
-
-If the extension was previously enabled in the `public` schema, move it to a new one:
-
-```sql
-CREATE SCHEMA adm;
-ALTER EXTENSION pg_stat_statements SET SCHEMA adm;
-```
-
-To query the `pg_stat_statements` data after changing the schema, prefix the view name with the new schema:
-
-```sql
-SELECT * FROM adm.pg_stat_statements limit 0;
-```
-
-To make it compatible with third-party monitoring solutions that expect it to be enabled in the `public` schema,
-you need to include it in the `search_path`:
-
-```sql
-set search_path to public,adm;
-```
-
-#### Fix an existing dump file to remove references to `pg_stat_statements`
-
-To fix an existing backup file, do the following changes:
-
-1. Extract from the backup the following file: `db/database.sql.gz`.
-1. Decompress the file or use an editor that is capable of handling it compressed.
-1. Remove the following lines, or similar ones:
-
-   ```sql
-   CREATE EXTENSION IF NOT EXISTS pg_stat_statements WITH SCHEMA public;
-   ```
-
-   ```sql
-   COMMENT ON EXTENSION pg_stat_statements IS 'track planning and execution statistics of all SQL statements executed';
-   ```
-
-1. Save the changes and recompress the file.
-1. Update the backup file with the modified `db/database.sql.gz`.
diff --git a/doc/administration/backup_restore/restore_gitlab.md b/doc/administration/backup_restore/restore_gitlab.md
index 51ada659acd..0b5bf3cc0ff 100644
--- a/doc/administration/backup_restore/restore_gitlab.md
+++ b/doc/administration/backup_restore/restore_gitlab.md
@@ -38,8 +38,7 @@ before restoring the backup.
 To restore a backup, **you must also restore the GitLab secrets**.
 These include the database encryption key, [CI/CD variables](../../ci/variables/index.md), and
 variables used for [two-factor authentication](../../user/profile/account/two_factor_authentication.md).
-Without the keys, [multiple issues occur](backup_gitlab.md#when-the-secrets-file-is-lost),
-including loss of access by users with [two-factor authentication enabled](../../user/profile/account/two_factor_authentication.md),
+Without the keys, [multiple issues occur](../../administration/backup_restore/troubleshooting_backup_gitlab.md#when-the-secrets-file-is-lost), including loss of access by users with [two-factor authentication enabled](../../user/profile/account/two_factor_authentication.md),
 and GitLab Runners cannot log in.
 
 Restore:
diff --git a/doc/administration/backup_restore/troubleshooting_backup_gitlab.md b/doc/administration/backup_restore/troubleshooting_backup_gitlab.md
new file mode 100644
index 00000000000..83a02b52741
--- /dev/null
+++ b/doc/administration/backup_restore/troubleshooting_backup_gitlab.md
@@ -0,0 +1,619 @@
+---
+stage: Systems
+group: Geo
+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
+---
+
+# Troubleshooting GitLab backups
+
+When you back up GitLab, you might encounter the following issues.
+
+## When the secrets file is lost
+
+If you didn't [back up the secrets file](../../administration/backup_restore/backup_gitlab.md#storing-configuration-files), you
+must complete several steps to get GitLab working properly again.
+
+The secrets file is responsible for storing the encryption key for the columns
+that contain required, sensitive information. If the key is lost, GitLab can't
+decrypt those columns, preventing access to the following items:
+
+- [CI/CD variables](../../ci/variables/index.md)
+- [Kubernetes / GCP integration](../../user/infrastructure/clusters/index.md)
+- [Custom Pages domains](../../user/project/pages/custom_domains_ssl_tls_certification/index.md)
+- [Project error tracking](../../operations/error_tracking.md)
+- [Runner authentication](../../ci/runners/index.md)
+- [Project mirroring](../../user/project/repository/mirror/index.md)
+- [Integrations](../../user/project/integrations/index.md)
+- [Web hooks](../../user/project/integrations/webhooks.md)
+
+In cases like CI/CD variables and runner authentication, you can experience
+unexpected behaviors, such as:
+
+- Stuck jobs.
+- 500 errors.
+
+In this case, you must reset all the tokens for CI/CD variables and
+runner authentication, which is described in more detail in the following
+sections. After resetting the tokens, you should be able to visit your project
+and the jobs begin running again.
+
+WARNING:
+The steps in this section can potentially lead to **data loss** on the above listed items.
+Consider opening a [Support Request](https://support.gitlab.com/hc/en-us/requests/new) if you're a Premium or Ultimate customer.
+
+### Verify that all values can be decrypted
+
+You can determine if your database contains values that can't be decrypted by using a
+[Rake task](../raketasks/check.md#verify-database-values-can-be-decrypted-using-the-current-secrets).
+
+### Take a backup
+
+You must directly modify GitLab data to work around your lost secrets file.
+
+WARNING:
+Be sure to create a full database backup before attempting any changes.
+
+### Disable user two-factor authentication (2FA)
+
+Users with 2FA enabled can't sign in to GitLab. In that case, you must
+[disable 2FA for everyone](../../security/two_factor_authentication.md#for-all-users),
+after which users must reactivate 2FA.
+
+### Reset CI/CD variables
+
+1. Enter the database console:
+
+   For the Linux package (Omnibus) GitLab 14.1 and earlier:
+
+   ```shell
+   sudo gitlab-rails dbconsole
+   ```
+
+   For the Linux package (Omnibus) GitLab 14.2 and later:
+
+   ```shell
+   sudo gitlab-rails dbconsole --database main
+   ```
+
+   For self-compiled installations, GitLab 14.1 and earlier:
+
+   ```shell
+   sudo -u git -H bundle exec rails dbconsole -e production
+   ```
+
+   For self-compiled installations, GitLab 14.2 and later:
+
+   ```shell
+   sudo -u git -H bundle exec rails dbconsole -e production --database main
+   ```
+
+1. Examine the `ci_group_variables` and `ci_variables` tables:
+
+   ```sql
+   SELECT * FROM public."ci_group_variables";
+   SELECT * FROM public."ci_variables";
+   ```
+
+   These are the variables that you need to delete.
+
+1. Delete all variables:
+
+   ```sql
+   DELETE FROM ci_group_variables;
+   DELETE FROM ci_variables;
+   ```
+
+1. If you know the specific group or project from which you wish to delete variables, you can include a `WHERE` statement to specify that in your `DELETE`:
+
+   ```sql
+   DELETE FROM ci_group_variables WHERE group_id = <GROUPID>;
+   DELETE FROM ci_variables WHERE project_id = <PROJECTID>;
+   ```
+
+You may need to reconfigure or restart GitLab for the changes to take effect.
+
+### Reset runner registration tokens
+
+1. Enter the database console:
+
+   For the Linux package (Omnibus) GitLab 14.1 and earlier:
+
+   ```shell
+   sudo gitlab-rails dbconsole
+   ```
+
+   For the Linux package (Omnibus) GitLab 14.2 and later:
+
+   ```shell
+   sudo gitlab-rails dbconsole --database main
+   ```
+
+   For self-compiled installations, GitLab 14.1 and earlier:
+
+   ```shell
+   sudo -u git -H bundle exec rails dbconsole -e production
+   ```
+
+   For self-compiled installations, GitLab 14.2 and later:
+
+   ```shell
+   sudo -u git -H bundle exec rails dbconsole -e production --database main
+   ```
+
+1. Clear all tokens for projects, groups, and the entire instance:
+
+   WARNING:
+   The final `UPDATE` operation stops the runners from being able to pick
+   up new jobs. You must register new runners.
+
+   ```sql
+   -- Clear project tokens
+   UPDATE projects SET runners_token = null, runners_token_encrypted = null;
+   -- Clear group tokens
+   UPDATE namespaces SET runners_token = null, runners_token_encrypted = null;
+   -- Clear instance tokens
+   UPDATE application_settings SET runners_registration_token_encrypted = null;
+   -- Clear key used for JWT authentication
+   -- This may break the $CI_JWT_TOKEN job variable:
+   -- https://gitlab.com/gitlab-org/gitlab/-/issues/325965
+   UPDATE application_settings SET encrypted_ci_jwt_signing_key = null;
+   -- Clear runner tokens
+   UPDATE ci_runners SET token = null, token_encrypted = null;
+   ```
+
+### Reset pending pipeline jobs
+
+1. Enter the database console:
+
+   For the Linux package (Omnibus) GitLab 14.1 and earlier:
+
+   ```shell
+   sudo gitlab-rails dbconsole
+   ```
+
+   For the Linux package (Omnibus) GitLab 14.2 and later:
+
+   ```shell
+   sudo gitlab-rails dbconsole --database main
+   ```
+
+   For self-compiled installations, GitLab 14.1 and earlier:
+
+   ```shell
+   sudo -u git -H bundle exec rails dbconsole -e production
+   ```
+
+   For self-compiled installations, GitLab 14.2 and later:
+
+   ```shell
+   sudo -u git -H bundle exec rails dbconsole -e production --database main
+   ```
+
+1. Clear all the tokens for pending jobs:
+
+   For GitLab 15.3 and earlier:
+
+   ```sql
+   -- Clear build tokens
+   UPDATE ci_builds SET token = null, token_encrypted = null;
+   ```
+
+   For GitLab 15.4 and later:
+
+   ```sql
+   -- Clear build tokens
+   UPDATE ci_builds SET token_encrypted = null;
+   ```
+
+A similar strategy can be employed for the remaining features. By removing the
+data that can't be decrypted, GitLab can be returned to operation, and the
+lost data can be manually replaced.
+
+### Fix integrations and webhooks
+
+If you've lost your secrets, the [integrations settings](../../user/project/integrations/index.md)
+and [webhooks settings](../../user/project/integrations/webhooks.md) pages might display `500` error messages. Lost secrets might also produce `500` errors when you try to access a repository in a project with a previously configured integration or webhook.
+
+The fix is to truncate the affected tables (those containing encrypted columns).
+This deletes all your configured integrations, webhooks, and related metadata.
+You should verify that the secrets are the root cause before deleting any data.
+
+1. Enter the database console:
+
+   For the Linux package (Omnibus) GitLab 14.1 and earlier:
+
+   ```shell
+   sudo gitlab-rails dbconsole
+   ```
+
+   For the Linux package (Omnibus) GitLab 14.2 and later:
+
+   ```shell
+   sudo gitlab-rails dbconsole --database main
+   ```
+
+   For self-compiled installations, GitLab 14.1 and earlier:
+
+   ```shell
+   sudo -u git -H bundle exec rails dbconsole -e production
+   ```
+
+   For self-compiled installations, GitLab 14.2 and later:
+
+   ```shell
+   sudo -u git -H bundle exec rails dbconsole -e production --database main
+   ```
+
+1. Truncate the following tables:
+
+   ```sql
+   -- truncate web_hooks table
+   TRUNCATE integrations, chat_names, issue_tracker_data, jira_tracker_data, slack_integrations, web_hooks, zentao_tracker_data, web_hook_logs CASCADE;
+   ```
+
+## Container registry push failures after restoring from a backup
+
+If you use the [container registry](../../user/packages/container_registry/index.md),
+pushes to the registry may fail after restoring your backup on a Linux package (Omnibus)
+instance after restoring the registry data.
+
+These failures mention permission issues in the registry logs, similar to:
+
+```plaintext
+level=error
+msg="response completed with error"
+err.code=unknown
+err.detail="filesystem: mkdir /var/opt/gitlab/gitlab-rails/shared/registry/docker/registry/v2/repositories/...: permission denied"
+err.message="unknown error"
+```
+
+This issue is caused by the restore running as the unprivileged user `git`,
+which is unable to assign the correct ownership to the registry files during
+the restore process ([issue #62759](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/62759 "Incorrect permissions on registry filesystem after restore")).
+
+To get your registry working again:
+
+```shell
+sudo chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/docker
+```
+
+If you changed the default file system location for the registry, run `chown`
+against your custom location, instead of `/var/opt/gitlab/gitlab-rails/shared/registry/docker`.
+
+## Backup fails to complete with Gzip error
+
+When running the backup, you may receive a Gzip error message:
+
+```shell
+sudo /opt/gitlab/bin/gitlab-backup create
+...
+Dumping ...
+...
+gzip: stdout: Input/output error
+
+Backup failed
+```
+
+If this happens, examine the following:
+
+- Confirm there is sufficient disk space for the Gzip operation. It's not uncommon for backups that
+  use the [default strategy](../../administration/backup_restore/backup_gitlab.md#backup-strategy-option) to require half the instance size
+  in free disk space during backup creation.
+- If NFS is being used, check if the mount option `timeout` is set. The
+  default is `600`, and changing this to smaller values results in this error.
+
+## Backup fails with `File name too long` error
+
+During backup, you can get the `File name too long` error ([issue #354984](https://gitlab.com/gitlab-org/gitlab/-/issues/354984)). For example:
+
+```plaintext
+Problem: <class 'OSError: [Errno 36] File name too long:
+```
+
+This problem stops the backup script from completing. To fix this problem, you must truncate the file names causing the problem. A maximum of 246 characters, including the file extension, is permitted.
+
+WARNING:
+The steps in this section can potentially lead to **data loss**. All steps must be followed strictly in the order given.
+Consider opening a [Support Request](https://support.gitlab.com/hc/en-us/requests/new) if you're a Premium or Ultimate customer.
+
+Truncating file names to resolve the error involves:
+
+- Cleaning up remote uploaded files that aren't tracked in the database.
+- Truncating the file names in the database.
+- Rerunning the backup task.
+
+### Clean up remote uploaded files
+
+A [known issue](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45425) caused object store uploads to remain after a parent resource was deleted. This issue was [resolved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18698).
+
+To fix these files, you must clean up all remote uploaded files that are in the storage but not tracked in the `uploads` database table.
+
+1. List all the object store upload files that can be moved to a lost and found directory if they don't exist in the GitLab database:
+
+   ```shell
+   bundle exec rake gitlab:cleanup:remote_upload_files RAILS_ENV=production
+   ```
+
+1. If you are sure you want to delete these files and remove all non-referenced uploaded files, run:
+
+   WARNING:
+   The following action is **irreversible**.
+
+   ```shell
+   bundle exec rake gitlab:cleanup:remote_upload_files RAILS_ENV=production DRY_RUN=false
+   ```
+
+### Truncate the file names referenced by the database
+
+You must truncate the files referenced by the database that are causing the problem. The file names referenced by the database are stored:
+
+- In the `uploads` table.
+- In the references found. Any reference found from other database tables and columns.
+- On the file system.
+
+Truncate the file names in the `uploads` table:
+
+1. Enter the database console:
+
+   For the Linux package (Omnibus) GitLab 14.2 and later:
+
+   ```shell
+   sudo gitlab-rails dbconsole --database main
+   ```
+
+   For the Linux package (Omnibus) GitLab 14.1 and earlier:
+
+   ```shell
+   sudo gitlab-rails dbconsole
+   ```
+
+   For self-compiled installations, GitLab 14.2 and later:
+
+   ```shell
+   sudo -u git -H bundle exec rails dbconsole -e production --database main
+   ```
+
+   For self-compiled installations, GitLab 14.1 and earlier:
+
+   ```shell
+   sudo -u git -H bundle exec rails dbconsole -e production
+   ```
+
+1. Search the `uploads` table for file names longer than 246 characters:
+
+   The following query selects the `uploads` records with file names longer than 246 characters in batches of 0 to 10000. This improves the performance on large GitLab instances with tables having thousand of records.
+
+      ```sql
+      CREATE TEMP TABLE uploads_with_long_filenames AS
+      SELECT ROW_NUMBER() OVER(ORDER BY id) row_id, id, path
+      FROM uploads AS u
+      WHERE LENGTH((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1]) > 246;
+
+      CREATE INDEX ON uploads_with_long_filenames(row_id);
+
+      SELECT
+         u.id,
+         u.path,
+         -- Current file name
+         (regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1] AS current_filename,
+         -- New file name
+         CONCAT(
+            LEFT(SPLIT_PART((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1], '.', 1), 242),
+            COALESCE(SUBSTRING((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1] FROM '\.(?:.(?!\.))+$'))
+         ) AS new_filename,
+         -- New path
+         CONCAT(
+            COALESCE((regexp_match(u.path, '(.*\/).*'))[1], ''),
+            CONCAT(
+               LEFT(SPLIT_PART((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1], '.', 1), 242),
+               COALESCE(SUBSTRING((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1] FROM '\.(?:.(?!\.))+$'))
+            )
+         ) AS new_path
+      FROM uploads_with_long_filenames AS u
+      WHERE u.row_id > 0 AND u.row_id <= 10000;
+      ```
+
+      Output example:
+
+      ```postgresql
+      -[ RECORD 1 ]----+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+      id               | 34
+      path             | public/@hashed/loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisitloremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisit.txt
+      current_filename | loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisitloremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisit.txt
+      new_filename     | loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisitloremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelits.txt
+      new_path         | public/@hashed/loremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelitsedvulputatemisitloremipsumdolorsitametconsecteturadipiscingelitseddoeiusmodtemporincididuntutlaboreetdoloremagnaaliquaauctorelits.txt
+      ```
+
+      Where:
+
+      - `current_filename`: a file name that is currently more than 246 characters long.
+      - `new_filename`: a file name that has been truncated to 246 characters maximum.
+      - `new_path`: new path considering the `new_filename` (truncated).
+
+   After you validate the batch results, you must change the batch size (`row_id`) using the following sequence of numbers (10000 to 20000). Repeat this process until you reach the last record in the `uploads` table.
+
+1. Rename the files found in the `uploads` table from long file names to new truncated file names. The following query rolls back the update so you can check the results safely in a transaction wrapper:
+
+   ```sql
+   CREATE TEMP TABLE uploads_with_long_filenames AS
+   SELECT ROW_NUMBER() OVER(ORDER BY id) row_id, path, id
+   FROM uploads AS u
+   WHERE LENGTH((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1]) > 246;
+
+   CREATE INDEX ON uploads_with_long_filenames(row_id);
+
+   BEGIN;
+   WITH updated_uploads AS (
+      UPDATE uploads
+      SET
+         path =
+         CONCAT(
+            COALESCE((regexp_match(updatable_uploads.path, '(.*\/).*'))[1], ''),
+            CONCAT(
+               LEFT(SPLIT_PART((regexp_match(updatable_uploads.path, '[^\\/:*?"<>|\r\n]+$'))[1], '.', 1), 242),
+               COALESCE(SUBSTRING((regexp_match(updatable_uploads.path, '[^\\/:*?"<>|\r\n]+$'))[1] FROM '\.(?:.(?!\.))+$'))
+            )
+         )
+      FROM
+         uploads_with_long_filenames AS updatable_uploads
+      WHERE
+         uploads.id = updatable_uploads.id
+      AND updatable_uploads.row_id > 0 AND updatable_uploads.row_id  <= 10000
+      RETURNING uploads.*
+   )
+   SELECT id, path FROM updated_uploads;
+   ROLLBACK;
+   ```
+
+   After you validate the batch update results, you must change the batch size (`row_id`) using the following sequence of numbers (10000 to 20000). Repeat this process until you reach the last record in the `uploads` table.
+
+1. Validate that the new file names from the previous query are the expected ones. If you are sure you want to truncate the records found in the previous step to 246 characters, run the following:
+
+   WARNING:
+   The following action is **irreversible**.
+
+   ```sql
+   CREATE TEMP TABLE uploads_with_long_filenames AS
+   SELECT ROW_NUMBER() OVER(ORDER BY id) row_id, path, id
+   FROM uploads AS u
+   WHERE LENGTH((regexp_match(u.path, '[^\\/:*?"<>|\r\n]+$'))[1]) > 246;
+
+   CREATE INDEX ON uploads_with_long_filenames(row_id);
+
+   UPDATE uploads
+   SET
+   path =
+      CONCAT(
+         COALESCE((regexp_match(updatable_uploads.path, '(.*\/).*'))[1], ''),
+         CONCAT(
+            LEFT(SPLIT_PART((regexp_match(updatable_uploads.path, '[^\\/:*?"<>|\r\n]+$'))[1], '.', 1), 242),
+            COALESCE(SUBSTRING((regexp_match(updatable_uploads.path, '[^\\/:*?"<>|\r\n]+$'))[1] FROM '\.(?:.(?!\.))+$'))
+         )
+      )
+   FROM
+   uploads_with_long_filenames AS updatable_uploads
+   WHERE
+   uploads.id = updatable_uploads.id
+   AND updatable_uploads.row_id > 0 AND updatable_uploads.row_id  <= 10000;
+   ```
+
+   After you finish the batch update, you must change the batch size (`updatable_uploads.row_id`) using the following sequence of numbers (10000 to 20000). Repeat this process until you reach the last record in the `uploads` table.
+
+Truncate the file names in the references found:
+
+1. Check if those records are referenced somewhere. One way to do this is to dump the database and search for the parent directory name and file name:
+
+   1. To dump your database, you can use the following command as an example:
+
+      ```shell
+      pg_dump -h /var/opt/gitlab/postgresql/ -d gitlabhq_production > gitlab-dump.tmp
+      ```
+
+   1. Then you can search for the references using the `grep` command. Combining the parent directory and the file name can be a good idea. For example:
+
+      ```shell
+      grep public/alongfilenamehere.txt gitlab-dump.tmp
+      ```
+
+1. Replace those long file names using the new file names obtained from querying the `uploads` table.
+
+Truncate the file names on the file system. You must manually rename the files in your file system to the new file names obtained from querying the `uploads` table.
+
+### Re-run the backup task
+
+After following all the previous steps, re-run the backup task.
+
+## Restoring database backup fails when `pg_stat_statements` was previously enabled
+
+The GitLab backup of the PostgreSQL database includes all SQL statements required to enable extensions that were
+previously enabled in the database.
+
+The `pg_stat_statements` extension can only be enabled or disabled by a PostgreSQL user with `superuser` role.
+As the restore process uses a database user with limited permissions, it can't execute the following SQL statements:
+
+```sql
+DROP EXTENSION IF EXISTS pg_stat_statements;
+CREATE EXTENSION IF NOT EXISTS pg_stat_statements WITH SCHEMA public;
+```
+
+When trying to restore the backup in a PostgreSQL instance that doesn't have the `pg_stats_statements` extension,
+the following error message is displayed:
+
+```plaintext
+ERROR: permission denied to create extension "pg_stat_statements"
+HINT: Must be superuser to create this extension.
+ERROR: extension "pg_stat_statements" does not exist
+```
+
+When trying to restore in an instance that has the `pg_stats_statements` extension enabled, the cleaning up step
+fails with an error message similar to the following:
+
+```plaintext
+rake aborted!
+ActiveRecord::StatementInvalid: PG::InsufficientPrivilege: ERROR: must be owner of view pg_stat_statements
+/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:42:in `block (4 levels) in <top (required)>'
+/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:41:in `each'
+/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:41:in `block (3 levels) in <top (required)>'
+/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:71:in `block (3 levels) in <top (required)>'
+/opt/gitlab/embedded/bin/bundle:23:in `load'
+/opt/gitlab/embedded/bin/bundle:23:in `<main>'
+Caused by:
+PG::InsufficientPrivilege: ERROR: must be owner of view pg_stat_statements
+/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:42:in `block (4 levels) in <top (required)>'
+/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:41:in `each'
+/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:41:in `block (3 levels) in <top (required)>'
+/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/backup.rake:71:in `block (3 levels) in <top (required)>'
+/opt/gitlab/embedded/bin/bundle:23:in `load'
+/opt/gitlab/embedded/bin/bundle:23:in `<main>'
+Tasks: TOP => gitlab:db:drop_tables
+(See full trace by running task with --trace)
+```
+
+### Prevent the dump file to include `pg_stat_statements`
+
+To prevent the inclusion of the extension in the PostgreSQL dump file that is part of the backup bundle,
+enable the extension in any schema except the `public` schema:
+
+```sql
+CREATE SCHEMA adm;
+CREATE EXTENSION pg_stat_statements SCHEMA adm;
+```
+
+If the extension was previously enabled in the `public` schema, move it to a new one:
+
+```sql
+CREATE SCHEMA adm;
+ALTER EXTENSION pg_stat_statements SET SCHEMA adm;
+```
+
+To query the `pg_stat_statements` data after changing the schema, prefix the view name with the new schema:
+
+```sql
+SELECT * FROM adm.pg_stat_statements limit 0;
+```
+
+To make it compatible with third-party monitoring solutions that expect it to be enabled in the `public` schema,
+you need to include it in the `search_path`:
+
+```sql
+set search_path to public,adm;
+```
+
+### Fix an existing dump file to remove references to `pg_stat_statements`
+
+To fix an existing backup file, do the following changes:
+
+1. Extract from the backup the following file: `db/database.sql.gz`.
+1. Decompress the file or use an editor that is capable of handling it compressed.
+1. Remove the following lines, or similar ones:
+
+   ```sql
+   CREATE EXTENSION IF NOT EXISTS pg_stat_statements WITH SCHEMA public;
+   ```
+
+   ```sql
+   COMMENT ON EXTENSION pg_stat_statements IS 'track planning and execution statistics of all SQL statements executed';
+   ```
+
+1. Save the changes and recompress the file.
+1. Update the backup file with the modified `db/database.sql.gz`.
diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md
index 207dbc7b509..39d7cae5dde 100644
--- a/doc/administration/raketasks/check.md
+++ b/doc/administration/raketasks/check.md
@@ -215,7 +215,7 @@ secrets file (`gitlab-secrets.json`).
 
 Automatic resolution is not yet implemented. If you have values that
 cannot be decrypted, you can follow steps to reset them, see our
-documentation on what to do [when the secrets file is lost](../../administration/backup_restore/backup_gitlab.md#when-the-secrets-file-is-lost).
+documentation on what to do [when the secrets file is lost](../../administration/backup_restore/troubleshooting_backup_gitlab.md#when-the-secrets-file-is-lost).
 
 This can take a very long time, depending on the size of your
 database, as it checks all rows in all tables.
diff --git a/doc/api/integrations.md b/doc/api/integrations.md
index 62c433f9b54..bc6e93199f2 100644
--- a/doc/api/integrations.md
+++ b/doc/api/integrations.md
@@ -644,7 +644,7 @@ Parameters:
 
 | Parameter | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
-| `external_wiki_url` | string | true | The URL of the external wiki. |
+| `external_wiki_url` | string | true | URL of the external wiki. |
 
 ### Disable an external wiki
 
diff --git a/doc/api/vulnerability_exports.md b/doc/api/vulnerability_exports.md
index 3be1dccea29..f2e0784cda7 100644
--- a/doc/api/vulnerability_exports.md
+++ b/doc/api/vulnerability_exports.md
@@ -187,11 +187,12 @@ The response is `404 Not Found` if the vulnerability export is not finished yet
 Example response:
 
 ```csv
-Group Name,Project Name,Tool,Scanner Name,Status,Vulnerability,Details,Additional Info,Severity,CVE,CWE,Other Identifiers,Detected At,Location,Activity,Comments,Full Path
-Gitlab.org,Defend,container_scanning,Trivy,resolved,CVE-2019-14697 in musl-utils-1.1.20-r4,"musl libc through 1.1.23 has an x87 floating-point stack adjustment imbalance, related to the math/i386/ directory. In some cases, use of this library could introduce out-of-bounds writes that are not present in an application's source code.",CVE-2019-14697 in musl-utils-1.1.20-r4,critical,CVE-2019-14697,,"",2022-10-07 13:34:41 UTC,"{""image""=>""python:3.4-alpine"", ""dependency""=>{""package""=>{""name""=>""musl-utils""}, ""version""=>""1.1.20-r4""}, ""operating_system""=>""alpine 3.9.2""}",true,"2022-10-07 13:41:08 UTC|root|resolved|changed vulnerability status to resolved",group/project/1
-Gitlab.org,Defend,container_scanning,Trivy,detected,CVE-2019-19242 in sqlite-libs-3.26.0-r3,"SQLite 3.30.1 mishandles pExpr->y.pTab, as demonstrated by the TK_COLUMN case in sqlite3ExprCodeTarget in expr.c.",CVE-2019-19242 in sqlite-libs-3.26.0-r3,medium,CVE-2019-19242,,"",2022-10-07 13:34:41 UTC,"{""image""=>""python:3.4-alpine"", ""dependency""=>{""package""=>{""name""=>""sqlite-libs""}, ""version""=>""3.26.0-r3""}, ""operating_system""=>""alpine 3.9.2""}",true,"",group/project/2
-Gitlab.org,Defend,container_scanning,Trivy,detected,CVE-2020-28928 in musl-1.1.20-r4,"In musl libc through 1.2.1, wcsnrtombs mishandles particular combinations of destination buffer size and source character limit, as demonstrated by an invalid write access (buffer overflow).",CVE-2020-28928 in musl-1.1.20-r4,medium,CVE-2020-28928,,"",2022-10-07 13:34:41 UTC,"{""image""=>""python:3.4-alpine"", ""dependency""=>{""package""=>{""name""=>""musl""}, ""version""=>""1.1.20-r4""}, ""operating_system""=>""alpine 3.9.2""}",true,"",group/project/3
-Gitlab.org,Defend,dependency_scanning,Gemnasium,detected,Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in rack,Carefully crafted requests can cause shell escape sequences to be written to the terminal via Rack's Lint middleware and CommonLogger middleware. These escape sequences can be leveraged to possibly execute commands in the victim's terminal.,Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in rack,unknown,Gemfile.lock:rack:gemnasium:60b5a27f-4e4d-4ab4-8ae7-74b4b212e177,,Gemnasium-60b5a27f-4e4d-4ab4-8ae7-74b4b212e177; GHSA-wq4h-7r42-5hrr,2022-10-14 13:16:00 UTC,"{""file""=>""Gemfile.lock"", ""dependency""=>{""package""=>{""name""=>""rack""}, ""version""=>""2.2.3""}}",false,"",group/project/4
-Gitlab.org,Defend,dependency_scanning,Gemnasium,detected,Denial of Service Vulnerability in Rack Multipart Parsing in rack,"Carefully crafted multipart POST requests can cause Rack's multipart parser to take much longer than expected, leading to a possible denial of service vulnerability. Impacted code will use Rack's multipart parser to parse multipart posts.",Denial of Service Vulnerability in Rack Multipart Parsing in rack,unknown,Gemfile.lock:rack:gemnasium:20daa17a-47b5-4f79-80c2-cd8f2db9805c,,Gemnasium-20daa17a-47b5-4f79-80c2-cd8f2db9805c; GHSA-hxqx-xwvh-44m2,2022-10-14 13:16:00 UTC,"{""file""=>""Gemfile.lock"", ""dependency""=>{""package""=>{""name""=>""rack""}, ""version""=>""2.2.3""}}",false,"",group/project/5
-Gitlab.org,Defend,sast,Brakeman,detected,Possible SQL injection,,Possible SQL injection,medium,e52f23a259cd489168b4313317ac94a3f13bffde57b9635171c1a44a9f329e9a,,"""Brakeman Warning Code 0""",2022-10-13 15:16:36 UTC,"{""file""=>""main.rb"", ""class""=>""User"", ""method""=>""index"", ""start_line""=>3}",false,"",group/project/6
+Group Name,Project Name,Tool,Scanner Name,Status,Vulnerability,Details,Additional Info,Severity,CVE,CWE,Other Identifiers,Detected At,Location,Activity,Comments,Full Path,CVSS Vectors,Dismissal Reason
+Gitlab.org,Defend,container_scanning,Trivy,resolved,CVE-2019-14697 in musl-utils-1.1.20-r4,"musl libc through 1.1.23 has an x87 floating-point stack adjustment imbalance, related to the math/i386/ directory. In some cases, use of this library could introduce out-of-bounds writes that are not present in an application's source code.",CVE-2019-14697 in musl-utils-1.1.20-r4,critical,CVE-2019-14697,,"",2022-10-07 13:34:41 UTC,"{""image""=>""python:3.4-alpine"", ""dependency""=>{""package""=>{""name""=>""musl-utils""}, ""version""=>""1.1.20-r4""}, ""operating_system""=>""alpine 3.9.2""}",true,"2022-10-07 13:41:08 UTC|root|resolved|changed vulnerability status to resolved",group/project/1,,,
+Gitlab.org,Defend,container_scanning,Trivy,detected,CVE-2019-19242 in sqlite-libs-3.26.0-r3,"SQLite 3.30.1 mishandles pExpr->y.pTab, as demonstrated by the TK_COLUMN case in sqlite3ExprCodeTarget in expr.c.",CVE-2019-19242 in sqlite-libs-3.26.0-r3,medium,CVE-2019-19242,,"",2022-10-07 13:34:41 UTC,"{""image""=>""python:3.4-alpine"", ""dependency""=>{""package""=>{""name""=>""sqlite-libs""}, ""version""=>""3.26.0-r3""}, ""operating_system""=>""alpine 3.9.2""}",true,"",group/project/2,,,
+Gitlab.org,Defend,container_scanning,Trivy,detected,CVE-2020-28928 in musl-1.1.20-r4,"In musl libc through 1.2.1, wcsnrtombs mishandles particular combinations of destination buffer size and source character limit, as demonstrated by an invalid write access (buffer overflow).",CVE-2020-28928 in musl-1.1.20-r4,medium,CVE-2020-28928,,"",2022-10-07 13:34:41 UTC,"{""image""=>""python:3.4-alpine"", ""dependency""=>{""package""=>{""name""=>""musl""}, ""version""=>""1.1.20-r4""}, ""operating_system""=>""alpine 3.9.2""}",true,"",group/project/3,,,
+Gitlab.org,Defend,dependency_scanning,Gemnasium,detected,Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in rack,Carefully crafted requests can cause shell escape sequences to be written to the terminal via Rack's Lint middleware and CommonLogger middleware. These escape sequences can be leveraged to possibly execute commands in the victim's terminal.,Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in rack,unknown,Gemfile.lock:rack:gemnasium:60b5a27f-4e4d-4ab4-8ae7-74b4b212e177,,Gemnasium-60b5a27f-4e4d-4ab4-8ae7-74b4b212e177; GHSA-wq4h-7r42-5hrr,2022-10-14 13:16:00 UTC,"{""file""=>""Gemfile.lock"", ""dependency""=>{""package""=>{""name""=>""rack""}, ""version""=>""2.2.3""}}",false,group/project/4,,,
+Gitlab.org,Defend,dependency_scanning,Gemnasium,detected,Denial of Service Vulnerability in Rack Multipart Parsing in rack,"Carefully crafted multipart POST requests can cause Rack's multipart parser to take much longer than expected, leading to a possible denial of service vulnerability. Impacted code will use Rack's multipart parser to parse multipart posts.",Denial of Service Vulnerability in Rack Multipart Parsing in rack,unknown,Gemfile.lock:rack:gemnasium:20daa17a-47b5-4f79-80c2-cd8f2db9805c,,Gemnasium-20daa17a-47b5-4f79-80c2-cd8f2db9805c; GHSA-hxqx-xwvh-44m2,2022-10-14 13:16:00 UTC,"{""file""=>""Gemfile.lock"", ""dependency""=>{""package""=>{""name""=>""rack""}, ""version""=>""2.2.3""}}",false,group/project/5,,,
+Gitlab.org,Defend,sast,Brakeman,detected,Possible SQL injection,,Possible SQL injection,medium,e52f23a259cd489168b4313317ac94a3f13bffde57b9635171c1a44a9f329e9a,,"""Brakeman Warning Code 0""",2022-10-13 15:16:36 UTC,"{""file""=>""main.rb"", ""class""=>""User"", ""method""=>""index"", ""start_line""=>3}",false,"",group/project/6,,,
+Gitlab.org,Defend,sast,Semgrep,dismissed,Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'),"SQL Injection is a critical vulnerability that can lead to data or system compromise...",,critical,,CWE-89,SCS0002,2023-12-28 10:48:34 UTC,"{""file""=>""WebGoat/App_Code/DB/SqliteDbProvider.cs"", ""start_line""=>274}",false,"2023-12-28 10:51:32 UTC|root|Dismissed|""changed vulnerability status to Dismissed: Not Applicable and the following comment: ""dismiss 5""",gitlab-org/defend/579,,Not applicable,
 ```
diff --git a/doc/ci/index.md b/doc/ci/index.md
index b74b2e1735b..0dcae04c47c 100644
--- a/doc/ci/index.md
+++ b/doc/ci/index.md
@@ -2,7 +2,6 @@
 stage: Verify
 group: Pipeline Execution
 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
-description: "Learn how to use GitLab CI/CD, the GitLab built-in Continuous Integration, Continuous Deployment, and Continuous Delivery toolset to build, test, and deploy your application."
 ---
 
 # Get started with GitLab CI/CD **(FREE ALL)**
diff --git a/doc/ci/variables/index.md b/doc/ci/variables/index.md
index 86fc813b0cc..f42ffc0020d 100644
--- a/doc/ci/variables/index.md
+++ b/doc/ci/variables/index.md
@@ -244,7 +244,7 @@ malicious code can compromise both masked and protected variables.
 
 Variable values are encrypted using [`aes-256-cbc`](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)
 and stored in the database. This data can only be read and decrypted with a
-valid [secrets file](../../administration/backup_restore/backup_gitlab.md#when-the-secrets-file-is-lost).
+valid [secrets file](../../administration/backup_restore/troubleshooting_backup_gitlab.md#when-the-secrets-file-is-lost).
 
 ### Mask a CI/CD variable
 
diff --git a/doc/install/docker.md b/doc/install/docker.md
index 252f34f7120..51b3aa28396 100644
--- a/doc/install/docker.md
+++ b/doc/install/docker.md
@@ -621,7 +621,7 @@ 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/backup_gitlab.md#when-the-secrets-file-is-lost) when recovering
+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](#set-up-the-volumes-location).
 
diff --git a/doc/operations/index.md b/doc/operations/index.md
index 5690e16600f..e14d371e75d 100644
--- a/doc/operations/index.md
+++ b/doc/operations/index.md
@@ -1,6 +1,7 @@
 ---
 stage: Service Management
 group: Respond
+description: Error tracking, incident management.
 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
 ---
 
diff --git a/doc/policy/experiment-beta-support.md b/doc/policy/experiment-beta-support.md
index 0c58380d304..a563ce7919d 100644
--- a/doc/policy/experiment-beta-support.md
+++ b/doc/policy/experiment-beta-support.md
@@ -1,6 +1,7 @@
 ---
 stage: Systems
 group: Distribution
+description: Support details.
 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
 ---
 
diff --git a/doc/topics/build_your_application.md b/doc/topics/build_your_application.md
index 50d94cc5b9f..787e056a1c7 100644
--- a/doc/topics/build_your_application.md
+++ b/doc/topics/build_your_application.md
@@ -1,13 +1,13 @@
 ---
 stage: none
 group: unassigned
+description: Runners, jobs, pipelines, variables.
 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
 ---
 
 # Use CI/CD to build your application **(FREE ALL)**
 
-Add your source code to a repository, create merge requests to check in
-code, and use CI/CD to generate your application. Include packages in your app and output it to a variety of environments.
+Use CI/CD to generate your application.
 
 - [Getting started](../ci/index.md)
 - [CI/CD YAML syntax reference](../ci/yaml/index.md)
diff --git a/doc/topics/git/index.md b/doc/topics/git/index.md
index 5a6a1aecded..b8740414faa 100644
--- a/doc/topics/git/index.md
+++ b/doc/topics/git/index.md
@@ -1,6 +1,7 @@
 ---
 stage: Create
 group: Source Code
+description: Common commands and workflows.
 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"
 ---
 
diff --git a/doc/topics/manage_code.md b/doc/topics/manage_code.md
index 5fbdbee7017..4cbd97f8898 100644
--- a/doc/topics/manage_code.md
+++ b/doc/topics/manage_code.md
@@ -1,12 +1,13 @@
 ---
 stage: none
 group: unassigned
+description: Repositories, merge requests, remote development.
 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
 ---
 
 # Manage your code **(FREE ALL)**
 
-Store your source files in a repository and create merge requests. Write, debug, and compile code hosted on GitLab.
+Store your source files in a repository and create merge requests. Write, debug, and collaborate on code.
 
 - [Repositories](../user/project/repository/index.md)
 - [Merge requests](../user/project/merge_requests/index.md)
diff --git a/doc/topics/plan_and_track.md b/doc/topics/plan_and_track.md
index 3712d73929c..61c359e63ba 100644
--- a/doc/topics/plan_and_track.md
+++ b/doc/topics/plan_and_track.md
@@ -1,6 +1,7 @@
 ---
 stage: Plan
 group: Project Management
+description: Epics, issues, milestones, labels.
 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
 ---
 
diff --git a/doc/topics/release_your_application.md b/doc/topics/release_your_application.md
index 27c5cc50e5f..d46ae98d47c 100644
--- a/doc/topics/release_your_application.md
+++ b/doc/topics/release_your_application.md
@@ -1,6 +1,7 @@
 ---
 stage: none
 group: unassigned
+description: Environments, packages, review apps, GitLab Pages.
 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
 ---
 
diff --git a/doc/topics/set_up_organization.md b/doc/topics/set_up_organization.md
index 84d7bb1add0..22a594b6117 100644
--- a/doc/topics/set_up_organization.md
+++ b/doc/topics/set_up_organization.md
@@ -1,6 +1,7 @@
 ---
 stage: none
 group: unassigned
+description: Users, groups, namespaces, SSH keys.
 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
 ---
 
diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md
index d58426bd76b..eef34214c23 100644
--- a/doc/user/analytics/index.md
+++ b/doc/user/analytics/index.md
@@ -1,6 +1,7 @@
 ---
 stage: Plan
 group: Optimize
+description: Instance, group, and project analytics.
 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
 ---
 
diff --git a/doc/user/application_security/secure_your_application.md b/doc/user/application_security/secure_your_application.md
index b35de7827e8..095796f3dc4 100644
--- a/doc/user/application_security/secure_your_application.md
+++ b/doc/user/application_security/secure_your_application.md
@@ -1,6 +1,7 @@
 ---
 stage: Secure
 group: Static Analysis
+description: Container, dependency, and vulnerability scans.
 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
 ---
 
diff --git a/doc/user/application_security/vulnerability_report/index.md b/doc/user/application_security/vulnerability_report/index.md
index 8defee7ae51..620d8c75e52 100644
--- a/doc/user/application_security/vulnerability_report/index.md
+++ b/doc/user/application_security/vulnerability_report/index.md
@@ -205,6 +205,8 @@ To sort vulnerabilities by the date each vulnerability was detected, select the
 
 ## Export vulnerability details
 
+> Added "Dismissal Reason" as a column in the CSV export [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/434076) in GitLab 16.8.
+
 You can export details of the vulnerabilities listed in the Vulnerability Report. The export format
 is CSV (comma separated values). All vulnerabilities are included because filters do not
 apply to the export.
@@ -229,6 +231,7 @@ Fields included are:
 - Comments
 - Full Path
 - CVSS Vectors
+- [Dismissal Reason](../vulnerabilities/index.md#vulnerability-dismissal-reasons)
 
 NOTE:
 Full details are available through our
diff --git a/doc/user/infrastructure/index.md b/doc/user/infrastructure/index.md
index 04d6caff0ba..327b6743d01 100644
--- a/doc/user/infrastructure/index.md
+++ b/doc/user/infrastructure/index.md
@@ -1,6 +1,7 @@
 ---
 stage: Deploy
 group: Environments
+description: Terraform and Kubernetes deployments.
 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
 ---
 
diff --git a/doc/user/project/organize_work_with_projects.md b/doc/user/project/organize_work_with_projects.md
index d41825af613..1371f5e77d0 100644
--- a/doc/user/project/organize_work_with_projects.md
+++ b/doc/user/project/organize_work_with_projects.md
@@ -1,6 +1,7 @@
 ---
 stage: Data Stores
 group: Tenant Scale
+description: Project visibility, search, badges, layout.
 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
 ---
 
diff --git a/doc/user/project/repository/mirror/index.md b/doc/user/project/repository/mirror/index.md
index 34a2757bb67..9d5048a4fed 100644
--- a/doc/user/project/repository/mirror/index.md
+++ b/doc/user/project/repository/mirror/index.md
@@ -208,4 +208,4 @@ Older versions of SSH may require you to remove `-E md5` from the command.
 - [Troubleshooting](troubleshooting.md) for repository mirroring.
 - Configure a [Pull Mirroring Interval](../../../../administration/instance_limits.md#pull-mirroring-interval)
 - [Disable mirrors for a project](../../../../administration/settings/visibility_and_access_controls.md#enable-project-mirroring)
-- [Secrets file and mirroring](../../../../administration/backup_restore/backup_gitlab.md#when-the-secrets-file-is-lost)
+- [Secrets file and mirroring](../../../../administration/backup_restore/troubleshooting_backup_gitlab.md#when-the-secrets-file-is-lost)
diff --git a/doc/user/version.md b/doc/user/version.md
index d39c0394610..2dcaf16d53b 100644
--- a/doc/user/version.md
+++ b/doc/user/version.md
@@ -1,6 +1,7 @@
 ---
 stage: none
 group: none
+description: Version information.
 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
 ---