diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-24 06:09:28 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-24 06:09:28 +0300 |
commit | be2f4c5788975597dd7be1c8a3525549770c1216 (patch) | |
tree | 083ed0d7e29e26d479c00e00d9cb89d74ebbb0ef /doc/raketasks | |
parent | 2711c26beaca6c3a5a3be4b65e01557faf0185b6 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/raketasks')
-rw-r--r-- | doc/raketasks/backup_restore.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index 54c550f999c..4245822a8fc 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -850,7 +850,7 @@ 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. +> The backup includes all repositories, uploads and PostgreSQL data. Example: LVM snapshots + rsync @@ -858,7 +858,7 @@ Example: LVM snapshots + rsync > 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. -> The replica includes all repositories, uploads and Postgres data. +> The replica includes all repositories, uploads and PostgreSQL data. If you are running GitLab on a virtualized server you can possibly also create VM snapshots of the entire GitLab server. It is not uncommon however for a VM snapshot to require you to power down the server, so this approach is probably of limited practical use. |