Migrating from one IP and server to a new one

1

What is the preferred way of migrating from one server to a new one with a different IP?

I would like to preserve accounts and emails.

2

Create a user-data user on the new machine (adduser user-data I think), copy /home/user-data over from the old machine (e.g. rsync -avz ... ...), then install Mail-in-a-Box as usual.

I haven’t actually tested this, but it’s designed to work this way, and I think someone has reported that it worked.

If you could take notes on what you do and/or submit a pull request to the setup guide, that’d be really helpful.

3

Thanks Josh,

Is there a way to make sure mail doesn’t get lost or delivered to the old server when migrating?

I’ve already moved the DNS entries to an external box and reduced the TTLs.

4

I guess I would shut down the old server. Mail normally will get queued by the sender in that case, and then will get delivered once the DNS updates and the new server is in place.

5

I am eager to know if this worked as intended? Would like to do this myself as well, but not sure if it worked out the way it should for OP :slight_smile:
Thanks

6

The migration was surprisingly smooth. I can’t comment on importing the Mailinabox data to a new server because I left Linux for FreeBSD and had to leave it behind unfortunately.

Anyhow, no emails were lost in the process. For the curious, I used imapsync to transfer mail from a handful of accounts and didn’t encounter any problems.

Make sure you’ve got a backup, just in case.

1 Like
7

Thanks! I just finished migrating to another server and it went silky smooth.
Just like Joshua mentioned:

  • adduser user-data on new machine
  • sudo service dovecot stop on old one
  • rsync -avz /home/user-data user-data@newbox:/home/user-data
  • run mailinabox setup on new box
  • ensure everything works
  • be thankful to Josh and other mailinabox contributors for the solid work :slight_smile:
3 Likes
8

I have a new install only since yesterday working OK.

Can I run the rsync command with the source not a MIAB install but a standalone postfix/dovecot install?

rsync -avz /home/auser/Maildir user-data@datamaskinaggie.xyz:/home/user-data

Then rerun ./mailinabox ?

1 Like
9

@pimpedoutgeek Maybe, but the destination directory isn’t right (you’ll need to figure it out).

After doing some research on this I realize we should be using a different storage format (sdbox), so the answer may be “no” in the future.

10

I followed these instructions and had some real issues with the new box getting configured correctly. I would like to add a caveat to your instructions. the rsync command should be:
‘rsync -avz /home/user-data/mail/mailboxes user-data@newbox:/home/user-data/mail’

Only syncing the mailboxes will prevent issues with configuration on the new box, but will still preserve all the existing mail on the old box.

11

I just went through this process earlier this week. I read the comments from this post to help me figure out the right strategy. I was fully successful, and I wanted to share the steps that I took. I’m on v0.43 for both the old and new MIAB servers.

Background: I was on a $5/month box that offered 2 CPUs, 1GB RAM, and 350GB HDD. Initially, there were three users on the machine. No complaints, except that one user with 100k messages in his INBOX complained that it took a few seconds to log in to webmail and load his message list. That is to be expected with that many messages. Once I added my 5th user, I started noticing some occasional performance issues. By the time the 6th user was added, disk IO would cause the load on the machine to climb beyond the number of CPUs. I felt like I needed to take some corrective action. After doing some research on dovecot performance tuning, improving disk IO was the number one concern. I am now on a new box for $12/month, which offers 1CPU, 2GB RAM, and 50GB NVMe. I currently have 19GB stored on the / partition. The user with 100k messages in his INBOX now says that it only takes 1 second for his webmail login to complete.

  1. I have a few domains that I control, mainly for email. I had previously used my domain registrar’s control panel to manage DNS externally. I decided that instead of spending over an hour updating individual DNS entries for multiple domains, now would be a good time to have MIAB control DNS for all domains. I edited the domain servers for each domain on the registrar’s website, and then waited a few hours for these changes to propagate. I mainly wanted to make sure that there were no DNS issues prior to beginning the mail migration.

  2. I ordered the new virtual host. By default, it only accepted ssh key login. I edited /etc/ssh/sshd_config to temporarily enable password login and verified that root login was permitted. Then service sshd restart

  3. I added the user-data account to the new server.

adduser user-data

  1. Copying the mail from one server to the next takes some time. I did an initial rsync from the old server to the new server. Future incremental rsyncs are much quicker.

rsync -avz /home/user-data user-data@107.xxx.xxx.xxx:/home

  1. I waited until late at night to perform the next steps. I updated the glue record IP addresses on the domain associated with my MIAB server at the registrar’s website. I set them to the IP of the new virtual host.

  2. I asked the hosting provider to set the PTR record of the new virtual machine to be the same as what was associated with the old IP. They were actually very helpful and would leave the PTR record on the old IP intact until the next morning to help with the transition. Their support response time has typically been 10 minutes.

  3. I ran tail -f /var/mail/mail.log on the old and new servers. I could see that activity was slowly shifting from the old box to the new box. I waited until traffic was minimal on the old box.

  4. I stopped postfix on the old box, so that mail would no longer be delivered to it.

service postfix stop

  1. I ran one last rsync. I did it as the root user this time, since I encountered some errors using the user-data account. Also, when running rsync, it has the appearance of wiping out messages on the new server that don’t exist on the old server. I think what happens is that it copies the dovecot indexes, which don’t account for the messages on the new server. The indexes seem to get rebuilt periodically, and any missing messages will eventually reappear.

rsync -avz /home/user-data root@107.xxx.xxx.xxx:/home

  1. I have a custom DNS record for one of my domains. I noticed that the nameserver on the new box wasn’t resolving the IP correctly. In other words, the nameserver was behaving as if the custom record didn’t exist. I did try restarting the domain name server with service nsd restart, but that didn’t help. I ended up deleting the entry and adding it back, which resolved the issue.

  2. I visited the Backup Status page and re-entered the settings. I use AWS for backups.

  3. It took about 14 hours for the last IMAP user to stop hitting the old box. After that point, I shut down the old box and followed up with my provider to make sure the PTR record was removed from the old IP. I also set up ssh keys and disabled password logins on the new box. This was a very seamless transition for all of the users with no appearance of downtime.

1 Like
12

@Netwerked

Thank you for sharing your migration experience. That was a very positive experience and an interesting read. I too did a similar migration and like you, used rsync rather than doing a backup restoration. I honestly recommend this path when possible rather than the documented method of downloading and restoring backups.

I do have a question for you, and a potential concern based around the answer to that question.

You mentioned that you "have a few domains that I control, mainly for email.’ This comment leads me to believe that you do have at least one, if not more, domain(s) with other services external to the email server on MiaB. There is IMHO a problem with this set up. Your MiaB is now a single point of failure for those specific domains.

To address this issue, I highly recommend that you set up Secondary DNS service to provide backup DNS in the case that your MiaB server should go offline for some unknown reason. Your email only domains do not need this, as if the MiaB is offline, there will be no email delivery anyways. But with Secondary DNS set up, if your MiaB does go offline, no matter how unlikely, the domains with other services will still continue to function.

There are several free and paid Secondary DNS providers. One that works well is https://puck.nether.net/dns/

13

@alento – Thanks for the advice! I have been meaning to set up a secondary nameserver, and I’ll definitely check out the link. The non-MIAB website is really just an Owncloud server, and I’m the main user.

I actually thought about ditching the Owncloud server, since MIAB offers Nextcloud. I hear that, aside from contacts and calendar, file storage is not supported. At least in v0.42 and 0.43, file storage is enabled out of the box.

In my case, I need NVMe speed and less storage for the mail servers, while I need less speed and more storage for the Owncloud server. I’ll probably continue to run them as two separate boxes for economical reasons, but will build a new Nextcloud box soon.