... | ... | @@ -834,10 +834,21 @@ GitLab is taking too much time to respond.") when GitLab restarts: it |
|
|
takes a *long* time to start (think minutes)... You can follow its
|
|
|
progress in `/var/log/gitlab/gitlab-rails/*.log`.
|
|
|
|
|
|
That procedure only restores a *part* of the system, namely what is
|
|
|
covered by the nightly backup job. To restore the rest (at the time of
|
|
|
writing: artifacts and repositories, which includes wikis!), you also
|
|
|
need to specifically restore those files from the backup server.
|
|
|
Be warned that the new server *will* start sending email
|
|
|
notifications, for example for issues with an due date, which might be
|
|
|
confusing for users if this is a development server. If this is a
|
|
|
production server, that's a good thing. If it's a development server,
|
|
|
you may want to disable email altogether in the GitLab server, with
|
|
|
this line in `hiera/roles/gitlab_dev.yml` in the `tor-puppet.git`
|
|
|
repository:
|
|
|
|
|
|
profile::gitlab::app::email_enabled: false
|
|
|
|
|
|
So the above procedure only restores a *part* of the system, namely
|
|
|
what is covered by the nightly backup job. To restore the rest (at the
|
|
|
time of writing: artifacts and repositories, which includes wikis!),
|
|
|
you also need to specifically restore those files from the backup
|
|
|
server.
|
|
|
|
|
|
For example, this procedure will restore the repositories from the
|
|
|
backup server:
|
... | ... | |