summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHossein Pursultani <hpursultani@gitlab.com>2019-08-13 10:59:50 +1000
committerHossein Pursultani <hpursultani@gitlab.com>2019-09-09 10:08:07 +1000
commit8e080834d1455e01912a406da742a1bdce0e449d (patch)
tree65d1cee1c9d448f1cedf2498e6b3050fd4cc22cc
parent54dc781a502111bda4810e528d8ef5ab49504eb9 (diff)
downloadgitlab-ce-docs-65889-gitlab-backup.tar.gz
Add notes to gitlab-backup usage on earlier versionsdocs-65889-gitlab-backup
-rw-r--r--doc/install/aws/index.md6
-rw-r--r--doc/migrate_ci_to_ce/README.md3
-rw-r--r--doc/raketasks/backup_restore.md47
3 files changed, 53 insertions, 3 deletions
diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md
index 358ba971049..ddf2b2fb738 100644
--- a/doc/install/aws/index.md
+++ b/doc/install/aws/index.md
@@ -613,6 +613,9 @@ To back up GitLab:
sudo gitlab-backup create
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
### Restoring GitLab from a backup
To restore GitLab, first review the [restore documentation](../../raketasks/backup_restore.md#restore),
@@ -631,6 +634,9 @@ released, you can update your GitLab instance:
sudo gitlab-backup create
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
1. Update the repositories and install GitLab:
```sh
diff --git a/doc/migrate_ci_to_ce/README.md b/doc/migrate_ci_to_ce/README.md
index 50e491f29a2..4a96001f2de 100644
--- a/doc/migrate_ci_to_ce/README.md
+++ b/doc/migrate_ci_to_ce/README.md
@@ -77,6 +77,9 @@ sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production SKIP=r
If this fails you need to fix it before upgrading to 8.0. Also see
<https://about.gitlab.com/get-help/>
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
### 2. Check source and target database types
Check what databases you use on your GitLab server and your CI server.
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 59b775d13bd..cf3ac04fd45 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -80,6 +80,9 @@ Use this command if you've installed GitLab with the Omnibus package:
sudo gitlab-backup create
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
Use this if you've installed GitLab from source:
```sh
@@ -92,6 +95,9 @@ If you are running GitLab within a Docker container, you can run the backup from
docker exec -t <container name> gitlab-backup create
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
If you are using the [GitLab helm chart](https://gitlab.com/gitlab-org/charts/gitlab) on a
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:
@@ -202,6 +208,9 @@ To use the `copy` strategy instead of the default streaming strategy, specify
sudo gitlab-backup create STRATEGY=copy
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
### Backup filename
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:
@@ -210,6 +219,9 @@ By default a backup file is created according to the specification in [the Backu
sudo gitlab-backup create BACKUP=dump
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
The resulting file will then be `dump_gitlab_backup.tar`. This is useful for systems that make use of rsync and incremental backups, and will result in considerably faster transfer speeds.
### Rsyncable
@@ -222,6 +234,9 @@ Note that the `--rsyncable` option in `gzip` is not guaranteed to be available o
sudo gitlab-backup create BACKUP=dump GZIP_RSYNCABLE=yes
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
### Excluding specific directories from the backup
You can choose what should be exempt from the backup up by adding the environment variable `SKIP`.
@@ -247,6 +262,9 @@ For Omnibus GitLab packages:
sudo gitlab-backup create SKIP=db,uploads
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
For installations from source:
```sh
@@ -452,6 +470,9 @@ sudo gitlab-backup create DIRECTORY=daily
sudo gitlab-backup create DIRECTORY=weekly
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
### Uploading to locally mounted shares
You may also send backups to a mounted share (`NFS` / `CIFS` / `SMB` / etc.) by
@@ -569,6 +590,9 @@ There, add the following line to schedule the backup for everyday at 2 AM:
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
You may also want to set a limited lifetime for backups to prevent regular
backups using all your disk space.
@@ -729,6 +753,14 @@ restore:
sudo gitlab-backup restore BACKUP=1493107454_2018_04_25_10.6.4-ce
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:restore`.
+
+CAUTION: **Warning:**
+`gitlab-rake gitlab:backup:restore` does not set the right file system permissions on your Registry directory.
+This is a [known issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/62759). On GitLab 12.2 or newer you can
+use `gitlab-backup restore` to avoid this issue.
+
Next, restore `/etc/gitlab/gitlab-secrets.json` if necessary as mentioned above.
Reconfigure, restart and check GitLab:
@@ -763,6 +795,14 @@ For docker installations, the restore task can be run from host:
docker exec -it <name of container> gitlab-backup restore
```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:restore`.
+
+CAUTION: **Warning:**
+`gitlab-rake gitlab:backup:restore` does not set the right file system permissions on your Registry directory.
+This is a [known issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/62759). On GitLab 12.2 or newer you can
+use `gitlab-backup restore` to avoid this issue.
+
The GitLab helm chart uses a different process, documented in
[restoring a GitLab helm chart installation](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/restore.md).
@@ -978,7 +1018,7 @@ sudo chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/doc
NOTE: **Note:**
If you have changed the default filesystem location for the registry, you will
-want to run the chown against your custom location instead of
+want to run the `chown` against your custom location instead of
`/var/opt/gitlab/gitlab-rails/shared/registry/docker`.
[reconfigure GitLab]: ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure
@@ -990,6 +1030,7 @@ While running the backup, you may receive a gzip error:
```sh
sudo /opt/gitlab/bin/gitlab-backup create
+...
Dumping ...
...
gzip: stdout: Input/output error
@@ -999,5 +1040,5 @@ Backup failed
If this happens, check the following:
-1. Confirm there is sufficent diskspace for the gzip operation.
-1. If NFS is being used, check if the mount option `timeo` is set. The default is `600`, and changing this to smaller values have resulted in this error.
+1. Confirm there is sufficient disk space for the gzip operation.
+1. If NFS is being used, check if the mount option `timeout` is set. The default is `600`, and changing this to smaller values have resulted in this error.