Fix a number of discovered typos, capitalization of developer and

product names, plus a couple of instances of bad Markdown markup.

1 files changed, 4 insertions, 4 deletions

diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index f9d2f5dc4eb..d40d74b1e34 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -214,19 +214,19 @@ This is recommended to reduce cron spam.
 If your GitLab server contains a lot of Git repository data you may find the GitLab backup script to be too slow.
 In this case you can consider using filesystem snapshots as part of your backup strategy.
 
-Example: Amazone EBS
+Example: Amazon EBS
 
 > A GitLab server using omnibus-gitlab hosted on Amazon AWS.
 > An EBS drive containing an ext4 filesystem is mounted at `/var/opt/gitlab`.
 > In this case you could make an application backup by taking an EBS snapshot.
 > The backup includes all repositories, uploads and Postgres data.
 
-Example: LVM snapshots + Rsync
+Example: LVM snapshots + rsync
 
 > A GitLab server using omnibus-gitlab, with an LVM logical volume mounted at `/var/opt/gitlab`.
-> Replicating the `/var/opt/gitlab` directory usign Rsync would not be reliable because too many files would change while Rsync is running.
+> Replicating the `/var/opt/gitlab` directory using rsync would not be reliable because too many files would change while rsync is running.
 > Instead of rsync-ing `/var/opt/gitlab`, we create a temporary LVM snapshot, which we mount as a read-only filesystem at `/mnt/gitlab_backup`.
-> Now we can have a longer running Rsync job which will create a consistent replica on the remote server.
+> Now we can have a longer running rsync job which will create a consistent replica on the remote server.
 > The replica includes all repositories, uploads and Postgres data.
 
 If you are running GitLab on a virtualized server you can possibly also create VM snapshots of the entire GitLab server.