From 875702dfabb545eaa3eb575ae7ad12fff2179d27 Mon Sep 17 00:00:00 2001 From: Hossein Pursultani Date: Tue, 10 Sep 2019 03:44:34 +0000 Subject: Revert gitlab-backup command and add a note for it --- doc/install/aws/index.md | 6 ++++++ doc/migrate_ci_to_ce/README.md | 3 +++ doc/raketasks/backup_restore.md | 47 ++++++++++++++++++++++++++++++++++++++--- 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 +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 06048ad618f..c230bb413f2 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 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 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. -- cgit v1.2.1