Migrating from a Jessie to a Stretch mail server

Upgrade or reinstall?

I recommend that you set up a new server and make sure that the new mail server is working correctly before you start migrating existing email users to it. You may argue that Debian can be upgraded easily using “apt-get dist-upgrade” but that is very dangerous on a live mail server. Automatic configuration changes may have evil side effects and you may lose emails. At least you are causing a serious downtime for your users.

If you follow my advice then get a new server and install Debian Stretch on it. Once the users are migrated properly and all works well you can tear down the old server.

However if you are really brave you may attempt an in-place upgrade. The changes from Jessie to Stretch are fortunately not that fundamental. Just rspamd

Read before you type

Follow this guide to the end. Only then start attempting a migration. Inform your users about the migration and set a time when you intend to move email accounts to the new server. The change will require a DNS change which takes a while to be visible worldwide so your users will have a period when incoming email is delayed. If you proceed properly not a single email will be lost though.

So your have your new server on Stretch up and running? Okay, then let’s start to…

Prepare the DNS record

The DNS “MX” record for your domain contains the name of your mail server. When switching to the new server you need to either change the MX record (if your new server has a different hostname) or the A record for the actual mail server. Every DNS record has a TTL (time-to-live) which defines the period of time that a record will stay valid even after you change it. Usually that TTL is rather high like 86400 seconds (=1 day). Turn that down temporarily to 60 seconds so that the rest of the internet will pick up your change quicker.

Migrate the database

You need to copy the database that contains the control data about your email domains and accounts. Log into the old (Jessie) server as root and backup the mailserver database. That is as easy as running

mysqldump mailserver > mailserver.sql

Copy that file to the new server (using scp) and import it there:

mysql mailserver < mailserver.sql

Obviously any database changes on the old server will have to be done on the new server as well.

Migrate the emails hot

Fortunately Dovecot uses the maildir format that stores emails as plain files on disk. Login to the new (Stretch) server and use rsync to copy over the mails from the old (Jessie) mail server:

rsync -va jessieserver:/var/vmail/ /var/vmail/

(Note the trailing slashes. Type them exactly as shown above or your files will end up in wrong places.)

There is no need to shut down Dovecot on your productive Jessie server. Copying the files while Dovecot is running will not break anything. This is called a “hot copy”. It may not be consistent but it will save time during the final synchronisation.


You told your users about the downtime, right? The time has come? Okay. Shut down Dovecot on both servers.

Migrate the emails cold

Let’s synchronize again. rsync will only copy those files that have changed which makes it much faster than the first sync. On your new server run:

rsync -va --delete jessieserver:/var/vmail/ /var/vmail/

(The “–delete” option makes sure that files that have been removed from the old server will also be deleted from the new server.)

Switch the DNS records

For all your domains you will have to change the DNS “MX” or “A” record to point to your new server.

Enable soft_bounce

Accidents happen. And you don’t want to lose emails. So run this command to enable your safety net on the new server:

postconf soft_bounce=yes

Now Postfix will always keep emails in the queue that it would otherwise reject. Start Postfix and Dovecot on the new server. Watch your /var/log/mail.log and run “mailq” from time to time to see what emails get stuck in the queue. If you are certain that emails can be removed then use “postsuper -d QUEUE-ID” (as shown in the “mailq” output).

Once you are certain that emails are properly received and sent you can switch off the soft_bounce mode again:

postconf soft_bounce=no

Shut down the old server

If possible do a final backup of the old server. If users are not complaining then dismiss the old system after a week.

10 thoughts on “Migrating from a Jessie to a Stretch mail server”

  1. Hi,

    It’s not yet time for migrating, but is it possible in the DNS to play with the MX priorities, the new serveur becoming the first one, and the old one becoming in some way an MX backup ?

    1. Christoph Haas

      Good idea, yes. Lower number mean higher priority. So you could say “@ MX 10 new-server” and “@ MX 20 old-server” for example.

      1. Justin L. Franks

        You’d also need to set up Dovecot replication with dsync. I don’t know if there would be issues with the mixed version numbers however.

        Database replication would also be required in order for account changes (such as when a user changes their password, or new accounts/domains are added).

        I don’t think it will be as easy as you are hoping.

  2. Yes in my idea it was only a temporary configuration during the DNS propagation. But in a second time it could be a good idea to upgrade the old desactivated server and configure it in replication with dsync and database replication. In this cas PostgreSQL would be a better choice than MySQL/Mariadb.

  3. Suggestion for “Migrate the database”
    mysqldump –add-drop-table mailserver > mailserver.sql

    with the –add-drop-table option you may repeat the import step on the new server if necessary.

  4. I did it on my own 8 years ago, but I have completely forgotten so your howto is precious 🙂

    I am not 100% sure about what I am doing here to fulfill the prerequisite.

    Maybe you could just elaborate a bit in the “Prepare the DNS record” chapter, e.g. by providing an example of a DNS zone after configuration (MX+A records)? I had to revert to some more googling (e.g. nice info on https://www.slashroot.in/mx-record-dns-explained-example-configurations — I am not affiliated to them in any way).

    Also: is it better or even required to have an MX record point to an FQDN, plus an A record for the FQDN (typically mail.mywebsite.com), or can we simply set the IP directly in the MX record? What would be the impact? I suspect that might trigger antispam/blacklisting systems.

  5. I am happy with the earlier version. I installed according to your tutorial but used openSUSE instead of Debian.
    At the time I had postfix 2.11 and Dovecot 2.2 installed.
    If I would update my OS now it would replace postfix version 2.11 with version 3.3, and Dovecot 2.2 with version 2.3.
    Do you know of any possible issues / problems this would cause?

    Kind regards,

    1. Christoph Haas

      I’m afraid I can’t say anything about those specific versions. Usually I spend a lot of time reading changelogs before coming up with a new version. And it looks as if Debian Buster is about to be released… maybe the versions are similar and you can take those instructions.

  6. hanifa yusliha rohmah

    ‘automatic configuration might have side effects’ so why do you recommend this

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to Top