kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Change gitlab-rake to gitlab-backup for backup and restore tasks

Browse source
This commit is contained in:
Hossein Pursultani 2019-08-07 09:14:52 +10:00
parent 2fd73269ef
commit 3c88ad7243
3 changed files with 15 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/install/aws/index.md
View file

@ -610,7 +610,7 @@ To back up GitLab:
1. Take a backup:
```sh
sudo gitlab-rake gitlab:backup:create
sudo gitlab-backup create
```
### Restoring GitLab from a backup
@ -628,7 +628,7 @@ released, you can update your GitLab instance:
1. Take a backup:
```sh
sudo gitlab-rake gitlab:backup:create
sudo gitlab-backup create
```
1. Update the repositories and install GitLab:

2
doc/migrate_ci_to_ce/README.md
View file

@ -67,7 +67,7 @@ Also check on your GitLab server.
```
# On your GitLab server:
# Omnibus
sudo gitlab-rake gitlab:backup:create SKIP=repositories,uploads
sudo gitlab-backup create SKIP=repositories,uploads
# Source
cd /home/git/gitlab

24
doc/raketasks/backup_restore.md
View file

@ -77,7 +77,7 @@ You are highly advised to [read about storing configuration files](#storing-conf
Use this command if you've installed GitLab with the Omnibus package:
```sh
sudo gitlab-rake gitlab:backup:create
sudo gitlab-backup create
```
Use this if you've installed GitLab from source:
@ -89,7 +89,7 @@ sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
If you are running GitLab within a Docker container, you can run the backup from the host:
```sh
docker exec -t <container name> gitlab-rake gitlab:backup:create
docker exec -t <container name> gitlab-backup create
```
If you are using the [GitLab helm chart](https://gitlab.com/charts/gitlab) on a
@ -199,7 +199,7 @@ To use the `copy` strategy instead of the default streaming strategy, specify
`STRATEGY=copy` in the Rake task command. For example:
```sh
sudo gitlab-rake gitlab:backup:create STRATEGY=copy
sudo gitlab-backup create STRATEGY=copy
```
### Backup filename
@ -207,7 +207,7 @@ sudo gitlab-rake gitlab:backup:create STRATEGY=copy
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:
```sh
sudo gitlab-rake gitlab:backup:create BACKUP=dump
sudo gitlab-backup create BACKUP=dump
```
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.
@ -219,7 +219,7 @@ To make sure the generated archive is intelligently transferable by rsync, the `
Note that the `--rsyncable` option in `gzip` is not guaranteed to be available on all distributions. To verify that it is available in your distribution you can run `gzip --help` or consult the man pages.
```sh
sudo gitlab-rake gitlab:backup:create BACKUP=dump GZIP_RSYNCABLE=yes
sudo gitlab-backup create BACKUP=dump GZIP_RSYNCABLE=yes
```
### Excluding specific directories from the backup
@ -244,7 +244,7 @@ will be skipped during a backup.
For Omnibus GitLab packages:
```sh
sudo gitlab-rake gitlab:backup:create SKIP=db,uploads
sudo gitlab-backup create SKIP=db,uploads
```
For installations from source:
@ -448,8 +448,8 @@ Note: This option only works for remote storage. If you want to group your backu
you can pass a `DIRECTORY` environment variable:
```
sudo gitlab-rake gitlab:backup:create DIRECTORY=daily
sudo gitlab-rake gitlab:backup:create DIRECTORY=weekly
sudo gitlab-backup create DIRECTORY=daily
sudo gitlab-backup create DIRECTORY=weekly
```
### Uploading to locally mounted shares
@ -566,7 +566,7 @@ crontab -e
There, add the following line to schedule the backup for everyday at 2 AM:
```
0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
```
You may also want to set a limited lifetime for backups to prevent regular
@ -726,7 +726,7 @@ restore:
```shell
# This command will overwrite the contents of your GitLab database!
sudo gitlab-rake gitlab:backup:restore BACKUP=1493107454_2018_04_25_10.6.4-ce
sudo gitlab-backup restore BACKUP=1493107454_2018_04_25_10.6.4-ce
```
Next, restore `/etc/gitlab/gitlab-secrets.json` if necessary as mentioned above.
@ -760,7 +760,7 @@ backup location (default location is `/var/opt/gitlab/backups`).
For docker installations, the restore task can be run from host:
```sh
docker exec -it <name of container> gitlab-rake gitlab:backup:restore
docker exec -it <name of container> gitlab-backup restore
```
The GitLab helm chart uses a different process, documented in
@ -966,7 +966,7 @@ want to run the chown against your custom location instead of
While running the backup, you may receive a gzip error:
```sh
sudo /opt/gitlab/bin/gitlab-rake gitlab:backup:create
sudo /opt/gitlab/bin/gitlab-backup create
Dumping ...
...
gzip: stdout: Input/output error