How To - Mail Server Migration

NOTE: This guide works for migrating mail servers between Ubuntu 16.04LTS distros, you may need to adjust for other distros.

This is an updated guide that now preserves the permissions after transfer so that the destination user vmail has ownership of the files, this was not the case with scp and required more steps to remedy this.

Feel free to reply with your own improvements/suggestions, I plan to come back to update this initial posting, I would like to see it as a community wiki or some such, not sure what can be done there but maybe a sticky will help.

I made some assumptions in creating this guide:

• You have the time to get through this (20 read time 10 run time, 2 days wait time). Don't rush through it, take your time and get it right the first time.
• you will read this entire post before attempting any changes so that you are aware of what it entails.
• You are aware that this is not risk free and you use it at your own risk.
• You may have unexpected errors that I am unable help you with.
• You know the mysql root password on both systems.
  if not - google mysql password reset or use the ispconfig user to login if you noted these details down already.
• you have installed a standalone mail server and already joined it to ispconfig (multi server setup/clustering) and have matched your systems as much as possible, same OS & Mail server and setup so that mail can authenticate against the database, at a minimum.
• In the following commands you will know the adjustments to make to match your own systems.

Now that we have gotten the doom, gloom and scarefest out of the way lets crack on.

Note: when using password login is disabled (using ssh-keys) you will need to enable password login to use rsync, unless you already have an authorised key set up on the destination server for the root user at your source server, not sure why but you may have.

1: Log into your database on your main server where ispconfig is installed. Your user for logging in needs access to dbispconfig.

• Locate the server table and look up the id for your new server, its likely to be the last one but the hostname of the server is there to confirm. the first column, server_id is what you want here.
• Locate the mail_domain table. Look up your mail domains that you will be migrating, edit the appropriate rows under server_id giving your mail domains the id of your new server.
  
• No phpmyadmin No Problem, just mysql client (you did install it right?) via an ssh connection: mysql root can be the mysql ispconfig user instead.
  
  Code:

  $ ssh root@source
  # mysql -uroot -p
  > USE dbispconfig;
  > UPDATE mail_domain SET server_id =
    > (SELECT server_id FROM server WHERE server_name = "mail.example.com")
  > WHERE domain = "example.com";
  

  You should repeat this for each of the mail domains that you want to migrate, when you are finished:
  
  Code:

  > QUIT
  # exit;
  

2: Log into ispconfig control panel.

• Head to emails, check the mail domain(s) first, which should now show your destination servers hostname.
• (optional) Manually migrate one of your mailboxes by opening the mailbox and clicking save and verify this change.
  
  Code:

  $ ssh root@destination
  # cd /var/vmail/yourdomain;
  # ls -l;
  # exit;
  

  If all is well at this point, you will see your mailbox owned by vmail:vmail and you can continue with the rest of your migrating mailboxes.
• Either continue manually or you can go to tools > Resync select the mail options and make sure your new mail server is selected in the drop down menus, click start.
  Thank you again to Jesse for the Resync tip.
  
  Note: ISPConfig cluster servers call home each minute so when you are updating your mailboxes you will need to wait for that to complete, you may have a few pending updates to migrate to the new server, this is normal, they will queue up and complete in turn.

3: Now that you have all your mailboxes created it's simply a matter of moving over your emails if you wish to keep them ~ I mean why wouldn't you want to keep those 23,000 junk emails that you've been hourding since 2003!
You may wish wait until your DNS changes in the next step are fully propagated as you will likely get mail intermittently delivered to your old server. or run it immediately and again in a few days time. Ultimately, the choice is yours, do as you feel comfortable with.

• Using rsync you can copy over your mailboxes keeping file details intact.
  In short, this will copy the mailboxes:
  --dry-run does as it says. remove it when you are satisfied with the output.
  --exlude its apparent what it does, if you want filters moving, then you can remove that part.
  --include you can use it to specify things not under the /var/vmail directory though you probably won't need to.
  --progress Gives you a progress indicator.
  -a archive: Preserves permissions, symlinks, timestamps etc.
  -z compress to save date on transfer
  -v verbose, show the output as it proceeds.
  -P see --progress
  
  Code:

  $ ssh root@source
  # rsync -azv -e 'ssh -p22' --dry-run --progress --exclude=/var/vmail/mailfilter /var/vmail/ root@destination:/var/vmail
  

  Thank you to Jesse for the suggestion, its a vast improvement over the scp method that required even more steps to correct permissions later.

4: You may need to make some changes to the following DNS records as appropriate to your system if you have not already done so.

• [A] ipv4 host
• [CNAME]
• [AAAA] ipv6 host
• [MX]
• SPF [TXT] just not that there is no aaaa in an spf record, a matches both ipv4 and ipv6 hosts.
• DMARC [TXT]
• DKIM [TXT]

Trouble shoot:
One issue I can assist with because i came upon it myself is a missing mysql auth module preventing imap login. You will recognise this issue if you see this in your /var/log/mail.log file:

To fix it run this command.

Code:

# apt install dovecot-mysql

Your mailbox did not create on the new server? Verify the mailbox user database migration:

Code:

# ssh root@yournewserver
# mysql -uroot -p
> use dbispconfig;
> select email from mail_user;
> quit;
# exit;

you should have results from the database including the mailboxes you just edited.

Email Bouncing:
I just solved an issue that had not cropped up on my old server, receiving this in the bounce report:

This was not an issue before as (hosting my own server) I had not configured ipv6 for the system and only used ipv4 addresses. My host server now does support them which means I had one of two options, figure out how to implement ipv6 authentication within my dns/postfix installation or simply disable ipv6 in postfix. I chose to disable ipv6 until I have the time to resolve the problem (its dns related probably no AAAA IPV6 record or spf record not correct for ipv6).

Code:

$ ssh root@destination
# postconf -e "inet_protocols = ipv4"
# systemctl restart postfix;

Revert the change with:

Code:

# postconf -e "inet_protocols = all"
# systemctl restart postfix

Good luck with your migration.

PS:: Can you tell that I LOVE (Like really really) Inserting brackets

 

Hi Jesse, I did consider using rsync but scp worked for my needs here. Of course keeping the ownership upon transfer does save some steps so maybe I should adjust that.