Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMarin Jankovski <marin@gitlab.com>2015-02-04 20:11:38 +0300
committerMarin Jankovski <marin@gitlab.com>2015-02-04 20:11:38 +0300
commitd685d45222b5c5e8b790e1cfc047e8dba7a0d56a (patch)
treec84423db14ba3c59c7599812d599ffbacc70cc37 /doc/raketasks
parent56a456b43dba7d772db45e2b73aa18b5eab53d37 (diff)
parent7aa3f6053efd9c1e2db962f7146a13bdf3d147c9 (diff)
Merge branch 'consolidate_ssh_docs' into 'master'
Consolidate SSH docs The two available SSH topics were quite short, so it made sense to combine them. Includes fixes a few missing words, punctuation. See merge request !328
Diffstat (limited to 'doc/raketasks')
-rw-r--r--doc/raketasks/backup_restore.md8
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 50cd0d08b5a..bbcf395c745 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.