diff --git a/howto/gitlab.md b/howto/gitlab.md
index fd0753cdf066ec182766f6340199e8314d839e09..fb37c9f9783daaf2282aec34bfd82cd048cf58c5 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: