From 9140e6ce78dbe4ee03a8e7db6d9dd0996ac6228c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anarcat@debian.org>
Date: Tue, 12 Jul 2022 15:14:47 -0400
Subject: [PATCH] warn about email in the gitlab restore procedure
 (tpo/tpa/team#40820)

---
 howto/gitlab.md | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/howto/gitlab.md b/howto/gitlab.md
index fd0753cd..fb37c9f9 100644
--- a/howto/gitlab.md
+++ b/howto/gitlab.md
@@ -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:
-- 
GitLab