1 files changed, 22 insertions, 22 deletions
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 2d2f5409c15..78d634b7795 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -21,7 +21,7 @@ If you installed GitLab:
 - Using the Omnibus package, you're all set.
 - From source, make sure `rsync` is installed:
 
-  ```sh
+  ```shell
   # Debian/Ubuntu
   sudo apt-get install rsync
 
@@ -35,7 +35,7 @@ Backup and restore tasks use `tar` under the hood to create and extract
 archives. Ensure you have version 1.30 or above of `tar` available in your
 system. To check the version, run:
 
-```sh
+```shell
 tar --version
 ```
 
@@ -76,7 +76,7 @@ You are highly advised to [read about storing configuration files](#storing-conf
 
 Use this command if you've installed GitLab with the Omnibus package:
 
-```sh
+```shell
 sudo gitlab-backup create
 ```
 
@@ -85,13 +85,13 @@ For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
 
 Use this if you've installed GitLab from source:
 
-```sh
+```shell
 sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
 ```
 
 If you are running GitLab within a Docker container, you can run the backup from the host:
 
-```sh
+```shell
 docker exec -t <container name> gitlab-backup create
 ```
 
@@ -102,7 +102,7 @@ If you are using the [GitLab Helm chart](https://gitlab.com/gitlab-org/charts/gi
 Kubernetes cluster, you can run the backup task using `backup-utility` script on
 the GitLab task runner pod via `kubectl`. Refer to [backing up a GitLab installation](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/backup.md#backing-up-a-gitlab-installation) for more details:
 
-```sh
+```shell
 kubectl exec -it <gitlab task-runner pod> backup-utility
 ```
 
@@ -204,7 +204,7 @@ installations. This is why the `copy` strategy is not the default in 8.17.
 To use the `copy` strategy instead of the default streaming strategy, specify
 `STRATEGY=copy` in the Rake task command. For example:
 
-```sh
+```shell
 sudo gitlab-backup create STRATEGY=copy
 ```
 
@@ -215,7 +215,7 @@ For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
 
 By default a backup file is created according to the specification in [the Backup timestamp](#backup-timestamp) section above. You can however override the `[TIMESTAMP]` part of the filename by setting the `BACKUP` environment variable. For example:
 
-```sh
+```shell
 sudo gitlab-backup create BACKUP=dump
 ```
 
@@ -230,7 +230,7 @@ To make sure the generated archive is intelligently transferable by rsync, the `
 
 Note that the `--rsyncable` option in `gzip` is not guaranteed to be available on all distributions. To verify that it is available in your distribution you can run `gzip --help` or consult the man pages.
 
-```sh
+```shell
 sudo gitlab-backup create BACKUP=dump GZIP_RSYNCABLE=yes
 ```
 
@@ -258,7 +258,7 @@ will be skipped during a backup.
 
 For Omnibus GitLab packages:
 
-```sh
+```shell
 sudo gitlab-backup create SKIP=db,uploads
 ```
 
@@ -267,7 +267,7 @@ For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
 
 For installations from source:
 
-```sh
+```shell
 sudo -u git -H bundle exec rake gitlab:backup:create SKIP=db,uploads RAILS_ENV=production
 ```
 
@@ -579,7 +579,7 @@ policy as described here](https://stackoverflow.com/questions/37553070/gitlab-om
 
 To schedule a cron job that backs up your repositories and GitLab metadata, use the root user:
 
-```sh
+```shell
 sudo su -
 crontab -e
 ```
@@ -608,7 +608,7 @@ For installations from source:
 
 1. [Restart GitLab] for the changes to take effect.
 
-```sh
+```shell
 sudo -u git crontab -e # Edit the crontab for the git user
 ```
 
@@ -796,7 +796,7 @@ backup location (default location is `/var/opt/gitlab/backups`).
 
 For docker installations, the restore task can be run from host:
 
-```sh
+```shell
 docker exec -it <name of container> gitlab-backup restore
 ```
 
@@ -906,13 +906,13 @@ backup beforehand.
 
    For Omnibus GitLab packages:
 
-   ```sh
+   ```shell
    sudo gitlab-rails dbconsole
    ```
 
    For installations from source:
 
-   ```sh
+   ```shell
    sudo -u git -H bundle exec rails dbconsole RAILS_ENV=production
    ```
 
@@ -941,13 +941,13 @@ backup beforehand.
 
    For Omnibus GitLab packages:
 
-   ```sh
+   ```shell
    sudo gitlab-rails dbconsole
    ```
 
    For installations from source:
 
-   ```sh
+   ```shell
    sudo -u git -H bundle exec rails dbconsole RAILS_ENV=production
    ```
 
@@ -974,13 +974,13 @@ backup beforehand.
 
    For Omnibus GitLab packages:
 
-   ```sh
+   ```shell
    sudo gitlab-rails dbconsole
    ```
 
    For installations from source:
 
-   ```sh
+   ```shell
    sudo -u git -H bundle exec rails dbconsole RAILS_ENV=production
    ```
 
@@ -1017,7 +1017,7 @@ unable to assign the correct ownership to the registry files during the restore
 
 To get your registry working again:
 
-```bash
+```shell
 sudo chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/docker
 ```
 
@@ -1033,7 +1033,7 @@ want to run the `chown` against your custom location instead of
 
 While running the backup, you may receive a gzip error:
 
-```sh
+```shell
 sudo /opt/gitlab/bin/gitlab-backup create
 ...
 Dumping ...