Add latest changes from gitlab-org/gitlab@master

1 files changed, 6 insertions, 6 deletions

diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 1a1afe7b555..19065b27275 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -109,7 +109,7 @@ kubectl exec -it <gitlab task-runner pod> backup-utility
 Similarly to the Kubernetes case, if you have scaled out your GitLab
 cluster to use multiple application servers, you should pick a
 designated node (that won't be auto-scaled away) for running the
-backup rake task. Because the backup rake task is tightly coupled to
+backup Rake task. Because the backup Rake task is tightly coupled to
 the main Rails application, this is typically a node on which you're
 also running Unicorn/Puma and/or Sidekiq.
 
@@ -171,7 +171,7 @@ the GitLab container according to the documentation, it should be under
 `/srv/gitlab/config`.
 
 For [GitLab Helm chart Installations](https://gitlab.com/gitlab-org/charts/gitlab) on a
-Kubernetes cluster, you must follow the [Backup the secrets](https://docs.gitlab.com/charts/backup-restore/backup.html#backup-the-secrets) instructions.  
+Kubernetes cluster, you must follow the [Backup the secrets](https://docs.gitlab.com/charts/backup-restore/backup.html#backup-the-secrets) instructions.
 
 You may also want to back up any TLS keys and certificates, and your
 [SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079).
@@ -819,7 +819,7 @@ a Kubernetes cluster, the restore task expects the restore directories to be emp
 However, with docker and Kubernetes volume mounts, some system level directories
 may be created at the volume roots, like `lost+found` directory found in Linux
 operating systems. These directories are usually owned by `root`, which can
-cause access permission errors since the restore rake task runs as `git` user.
+cause access permission errors since the restore Rake task runs as `git` user.
 So, to restore a GitLab installation, users have to confirm the restore target
 directories are empty.
 
@@ -875,8 +875,8 @@ to export / backup your data yourself from GitLab.com.
 Issues are stored in the database. They can't be stored in Git itself.
 
 To migrate your repositories from one server to another with an up-to-date version of
-GitLab, you can use the [import rake task](import.md) to do a mass import of the
-repository. Note that if you do an import rake task, rather than a backup restore, you
+GitLab, you can use the [import Rake task](import.md) to do a mass import of the
+repository. Note that if you do an import Rake task, rather than a backup restore, you
 will have all your repositories, but not any other data.
 
 ## Troubleshooting
@@ -893,7 +893,7 @@ psql:/var/opt/gitlab/backups/db/database.sql:2933: WARNING:  no privileges were
 
 Be advised that, backup is successfully restored in spite of these warnings.
 
-The rake task runs this as the `gitlab` user which does not have the superuser access to the database. When restore is initiated it will also run as `gitlab` user but it will also try to alter the objects it does not have access to.
+The Rake task runs this as the `gitlab` user which does not have the superuser access to the database. When restore is initiated it will also run as `gitlab` user but it will also try to alter the objects it does not have access to.
 Those objects have no influence on the database backup/restore but they give this annoying warning.
 
 For more information see similar questions on PostgreSQL issue tracker[here](https://www.postgresql.org/message-id/201110220712.30886.adrian.klaver@gmail.com) and [here](https://www.postgresql.org/message-id/2039.1177339749@sss.pgh.pa.us) as well as [stack overflow](https://stackoverflow.com/questions/4368789/error-must-be-owner-of-language-plpgsql).