From 75c103ccc990650e1175f662aab2d8d0e2c18eef Mon Sep 17 00:00:00 2001 From: Paul Binks Date: Thu, 1 Mar 2018 16:46:21 +0000 Subject: [PATCH] Update maintain.rst --- docs/maintain.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/maintain.rst b/docs/maintain.rst index e14d911c..d570690e 100644 --- a/docs/maintain.rst +++ b/docs/maintain.rst @@ -20,25 +20,25 @@ simply pull the latest images and recreate the containers : Monitoring the mail server -------------------------- -Logs are managed by Docker directly. You can easily read your logs using : +Logs are managed by Docker directly. You can easily read your logs using: .. code-block:: bash docker-compose logs -Docker is able to forward logs to multiple log engines. Read the following documentation or details: https://docs.docker.com/engine/admin/logging/overview/. +Docker is able to forward logs to multiple log engines. Read the following documentation for details: https://docs.docker.com/engine/admin/logging/overview/. Migrating an instance --------------------- -The SMTP protocol has an embedded retry mechanism and multiple MX that can serve a single domain, so that most migration process or maintenance process do not require any specific care. +The SMTP protocol has an embedded retry mechanism and multiple MX that can serve a single domain, so that most migration processes or maintenance processes do not require any specific care. -Mailu relys heavily on files for storing everything, which helps the migration process, that can be performed based on file synchronization. +Mailu relies heavily on files for storing everything, which helps the migration process, that can be performed based on file synchronization. -The suggested migration process consists in setting up a new backup server that drops incoming emails (Mailu not started), synchronizing both servers, stopping the main server and launching the backup server. Then, the backup server is switched as a main MX and the old server is deleted. +The suggested migration process consists of setting up a new backup server that drops incoming emails (Mailu not started), synchronizing both servers, stopping the main server and launching the backup server. Then, the backup server is switched as a main MX and the old server is deleted. 1. Prepare your new server, copy your ``docker-compose.yml``, ``.env`` and basic configuration files to the server, so that it is ready to start configuration Mailu, *do not start Mailu* -2. Setup your DNS so that the backup server is an additional, deprioritized MX for the domain; this can be complex if you serve many domains, in which case you can simply accept that some remote MX will retry for a couple minutes, skip this step +2. Setup your DNS so that the backup server is an additional, deprioritized MX for the domain; this can be complex if you serve many domains, in which case you can simply accept that some remote MX will retry for a couple of minutes, skip this step 3. While your DNS TTL expires and your modification propagates, start *rsyncing* your Mailu directory (``data``, ``dkim``, ``mail``, etc.) to the new server, repeat until there are only a couple files synchronized 4. Stop Mailu on the old server and run a final ``rsync`` while no process is writing to the files 5. Start Mailu on the new server, and production should be back to normal