diff options
Diffstat (limited to 'doc/raketasks/backup_restore.md')
| -rw-r--r-- | doc/raketasks/backup_restore.md | 29 |
1 files changed, 15 insertions, 14 deletions
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index 8a01975f771..20131a795c5 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -1,10 +1,10 @@ --- -stage: none -group: unassigned +stage: Enablement +group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -# Back up and restore GitLab **(CORE ONLY)** +# Back up and restore GitLab **(FREE SELF)** GitLab provides Rake tasks for backing up and restoring GitLab instances. @@ -16,7 +16,7 @@ of GitLab on which it was created. The best way to migrate your repositories from one server to another is through backup restore. WARNING: -GitLab doesn't back up items that aren't stored in the filesystem. If you're +GitLab doesn't back up items that aren't stored in the file system. If you're using [object storage](../administration/object_storage.md), be sure to enable backups with your object storage provider, if desired. @@ -100,7 +100,7 @@ the host, based on your installed version of GitLab: - GitLab 12.1 and earlier: ```shell - gitlab-rake gitlab:backup:create + docker exec -t <container name> gitlab-rake gitlab:backup:create ``` If you're using the [GitLab Helm chart](https://gitlab.com/gitlab-org/charts/gitlab) @@ -240,7 +240,7 @@ The resulting file is named `dump_gitlab_backup.tar`. This is useful for systems that make use of rsync and incremental backups, and results in considerably faster transfer speeds. -#### Rsyncable +#### Confirm archive can be transferred To ensure the generated archive is transferable by rsync, you can set the `GZIP_RSYNCABLE=yes` option. This sets the `--rsyncable` option to `gzip`, which is useful only in @@ -810,7 +810,7 @@ data into (`gitlabhq_production`). All existing data is either erased To restore a backup, you must restore `/etc/gitlab/gitlab-secrets.json` (for Omnibus packages) or `/home/git/gitlab/.secret` (for installations from source). This file contains the database encryption key, -[CI/CD variables](../ci/variables/README.md#gitlab-cicd-environment-variables), and +[CI/CD variables](../ci/variables/README.md), and variables used for [two-factor authentication](../user/profile/account/two_factor_authentication.md). If you fail to restore this encryption key file along with the application data backup, users with two-factor authentication enabled and GitLab Runner @@ -1024,7 +1024,7 @@ restoring a single project or group, you can use a workaround by restoring your backup to a separate, temporary GitLab instance, and then export your project or group from there: -1. [Install a new GitLab](../install/README.md) instance at the same version as +1. [Install a new GitLab](../install/index.md) instance at the same version as the backed-up instance from which you want to restore. 1. [Restore the backup](#restore-gitlab) into this new instance, then export your [project](../user/project/settings/import_export.md) @@ -1042,12 +1042,12 @@ is being discussed in [issue #17517](https://gitlab.com/gitlab-org/gitlab/-/issu If your GitLab server contains a lot of Git repository data, you may find the GitLab backup script to be too slow. In this case you can consider using -filesystem snapshots as part of your backup strategy. +file system snapshots as part of your backup strategy. 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`. +> An EBS drive containing an ext4 file system 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 PostgreSQL data. @@ -1055,7 +1055,7 @@ Example: LVM snapshots + rsync > A GitLab server using Omnibus GitLab, with an LVM logical volume mounted at `/var/opt/gitlab`. > 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`. +> Instead of rsync-ing `/var/opt/gitlab`, we create a temporary LVM snapshot, which we mount as a read-only file system at `/mnt/gitlab_backup`. > Now we can have a longer running rsync job which creates a consistent replica on the remote server. > The replica includes all repositories, uploads and PostgreSQL data. @@ -1204,9 +1204,9 @@ and the jobs begin running again. Use the information in the following sections at your own risk. -#### Check for undecryptable values +#### Verify that all values can be decrypted -You can determine if you have undecryptable values in the database by using the +You can determine if your database contains values that can't be decrypted by using the [Secrets Doctor Rake task](../administration/raketasks/doctor.md). #### Take a backup @@ -1285,6 +1285,7 @@ You may need to reconfigure or restart GitLab for the changes to take effect. UPDATE namespaces SET runners_token = null, runners_token_encrypted = null; -- Clear instance tokens UPDATE application_settings SET runners_registration_token_encrypted = null; + UPDATE application_settings SET encrypted_ci_jwt_signing_key = null; -- Clear runner tokens UPDATE ci_runners SET token = null, token_encrypted = null; ``` @@ -1370,7 +1371,7 @@ To get your registry working again: sudo chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/docker ``` -If you changed the default filesystem location for the registry, run `chown` +If you changed the default file system location for the registry, run `chown` against your custom location, instead of `/var/opt/gitlab/gitlab-rails/shared/registry/docker`. ### Backup fails to complete with Gzip error |