Skip to content
Snippets Groups Projects
Commit e47cbf37 authored by Evan Read's avatar Evan Read
Browse files

Merge branch 'docs-65889-gitlab-backup' into 'master'

Revert gitlab-backup command and add a note for it

Closes #65889

See merge request gitlab-org/gitlab-ce!31747
parents d7c1af98 875702df
No related branches found
No related tags found
No related merge requests found
Loading
Loading
@@ -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),
Loading
Loading
@@ -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
Loading
Loading
Loading
Loading
@@ -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.
Loading
Loading
Loading
Loading
@@ -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
Loading
Loading
@@ -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:
Loading
Loading
@@ -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:
Loading
Loading
@@ -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
Loading
Loading
@@ -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`.
Loading
Loading
@@ -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
Loading
Loading
@@ -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
Loading
Loading
@@ -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.
 
Loading
Loading
@@ -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:
Loading
Loading
@@ -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).
 
Loading
Loading
@@ -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
Loading
Loading
@@ -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
Loading
Loading
@@ -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.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment