Email Migration Strategy

Saw this topic had cropped up before here Email migration tool GUI, so tagging @jlguerrero

I like imapsync too, and have used it before, but there are a couple of problems. First of all you have to know the passwords of all accounts (or set up dovecot with a super user). Secondly it doesn’t ever quite get the IMAP / POP indexes right, so that when people connect to the new server, they end up re-downloading a bunch of emails.

So I’ve been thinking through an alternative approach. First of all, set up the mail domain on the new server with all the correct accounts, forwards, etc. And then use doveadm sync over ssh to sync a list of email addresses. This allows you to sync without passwords (using root or sudo), and will take care of all the dovecot indexing for you.

I have the sync command working for one test user. I’m now thinking about copying the settings over. Would this approach work?

  • Locate the mail domain in $HESTIA/data/users/username/mail.conf and copy the entry to the new server.
  • Copy the config files from /home/username/conf/mail/ from the old server to the new one
  • Run v-rebuild-mail-domain username

Would that transfer all the mail accounts over?
Then it would just be a case of generating a list of mail users and feeding them to my doveadm sync command.

Afterwards, I guess, set up SSL certs, DNS.

Does that seem like it might work? Anything I missed?

Questions to be asked first:

From Hestia → Hestia use backup system you can always only backup email domains.
From cpanel → Hestia you might be able to use hestiacp/v-restore-user-cpanel at c87c0d4af81f9c53f30fb75a746053f9bc1c47c8 · hestiacp/hestiacp · GitHub how ever you can also create a new mail domain and move the mails manually
Direct admin: Same as above

Gmail or any other 3rd party without ssh access use imapsync…

1 Like

Thanks eris. Its from an old Vesta server. I have used the backup system before to “exclude everything but the thing I want to backup”, make a backup, transfer to a new server, and “restore just the thing I need”.
However in this case there is a LOT of mail in the domain (150 Gb), so I was wondering if I can do it this way instead. If I can, then the accounts can be set up in a leisurely fashion, then the doveadm sync can be run several times, resulting in no downtime for the cutover.
If I sync the mail domain WITH the mails, I’m looking at a backup time of an hour or more, a transfer time of possibly an hour, and then restore of maybe 20 mins. So quite a lot of downtime in there. Plus still the problem of duplicate mails when the users connect to the new server (also with imapsync).

So basically I just wanted to try this way to see if it was better than the ‘official method’ you outline above.

I’m looking through the v-restore-user script to see what that does. While I’m in there, it occurs to me, that it might be useful to have a similar function which would only backup/restore the user settings, but not the data. Just thinking out loud.

1 Like

I beleive you can already do that, from GUI and from CLI. I never did it just for user settings, but it should works.

Hi @pluto the thing with imap sync is that it works with any server in origin and destination and your solution works from hestia to hestia mostly.

Sure. I’ve used imapsync for several large migrations. And the backup-restore method too. Just wanting to try something different, and as dovecot is running on both servers, its a good chance to try it.

I couldn’t figure out the details of how to copy just the mail config over this time using hestia tools (will try later on a demo server when I have time). So what I decided to do is to run the backup-restore to get the 150Gb of mail over to the new server (had to add on a new disk to fit the backup). As predicted it took several hours, and I left it going over night.

So now, I have the mail accounts set up on both servers, and I’m using doveadm to sync the accounts. Its working well, and its very fast. I’ll do one last sync before I switch over the DNS later today. The script runs on the target server, so uses the -R switch to PULL the mail from the source server. You could do it the other way around too. It looks like this

for MAILUSER in [email protected] [email protected] [email protected]

echo "$(date) Processing $MAILUSER"

# -v verbose, -f Full sync, -R Reverse, i.e. suck from remote to local
doveadm -v sync -u "$MAILUSER" -f -R \
	ssh -p 22 -i /root/.ssh/id_rsa [email protected] \
	doveadm dsync-server -u "$MAILUSER"

I just ran it and it processed 120 accounts in about a minute.

Getting closer to a very very hacky solution …
So I set the backup exclusion preferences for the user on the old server to exclude everything but the email domain I wanted to migrate.

I then took a copy of the v-backup-user script and hacked it so that when it was backing up the mail domain, it skipped the step where it makes the mail archive.

    # Mail Domains
    # Compress archive
    #if [ ${#accounts[@]} -gt 0 ]; then
    #    tar -cpf- ${accounts[@]} |gzip -$BACKUP_GZIP - > $tmpdir/mail/$domain/accounts.tar.gz

Just three lines need to be commented out. So when I ran that backup, it backed up the mail domain with settings, but without the actual mail

On the target server, I ran the v-restore-command to restore that mail domain only. And I got all the mail accounts, aliases, forwards added as I wanted.

v-restore-user bob bob-2021-04-29.tar.gz "no" "no" "" "no" "no" "no" "no"

The directories weren’t created, but doveadm does that when you sync. Looking good so far.
Don’t try this at home! :slight_smile:

Maybe you could create v-email-export and v-email-import
And make a pull request

Import / Export is all ready done in Hestia. For users who need to backup large quanities probally an automated system is not the best thing.

I can see the use of been backup function that only backups the configuration. (2nd backup systems like duplicity do the backup of “files”)

One use case would be:

  • I have ran out of space in my server and I want to migrate some clients.
    Since I do not have enough space, I can backup the configuration so I do not have to create the accounts again and then move the emails.
  • I have 3 alternatives to move my emails:
    ** Imapsync. I will have to know all passwords
    ** doveadm as pluto said
    ** Hestia backup, but I would have to do it one by one since I have no space left.

The thing is that the solution @pluto has proposed works like a charm and makes minimal changes.

That is why I am suggesting to make new CLI commands with that and include them in the main hestia distribution.

We can also load HestiaCP with tools that only one user uses. We will and u with an dragon like Cpanel / Plesk and so one. The risk of adding new this will also mean it ned get supported and as I have all ready seen the current users don’t know how to setup ssh keys between servers we should keep it simple at is.

We should probably add it to a knowledge base / docs system but it should not go in Hestia if we can’t make it 100% fool proof with out setting up it before hand. Because questions will raise about it.

1 Like

Yes, definitely not suggesting this for general use, but just documenting my experience here in case its useful for others in the future.