Check out the lightweight on-premises email archiving software developed by iRedMail team: Spider Email Archiver.
Please practise the migration on a test server first, make sure you understand the whole procedure and migrate all required data.
Since new iRedMail server will install same components as old server, you can choose what data you want to migrate.
Most important data are:
msgrcpt. Quarantined emails are stored in
quarantine, it requires other 3 tables. If you don't have any quarantined emails, it's safe to delete all records in these 4 tables.
Do not restore database
mysql exported from old server, it contains SQL
usernames/passwords for Roundcube/Amavisd/iRedAPD/iRedAdmin/... used on
old server. New iRedMail server has the same SQL usernames, but different
passwords. So please do not restore it.
Since iRedMail-0.8.7, iRedMail enforces secure POP3/IMAP/SMTP connections, please update your mail client applications to use TLS connection.
TLS), or port
TLS), or port
If you want to enable smtp authentication on port
25 (again, not
recommended), please comment out Postfix parameter
smtpd_tls_auth_only = yes
in its config file
if you want to enable SMTPS (SMTP over SSL, port
465) to support
legacy mail clients, please follow this tutorial:
How to enable SMTPS service.
Steps to migrate LDAP mail accounts:
Normally, LDAP data can be exported into LDIF format. Here's backup/restore procedure: Backup and Restore.
All mail accounts are stored in database
If both old and new servers are running same iRedMail version, you can simply
vmail database on old server, then import it on new server.
If old server is running an old iRedMail version, there might be some changes
in SQL structure, please read all upgrade tutorials for the old iRedMail
release, then apply SQL structure related changes to make sure old server
has same SQL structure. After you have same SQL structure on both servers,
you can simply export
vmail database on old server, then import it on new
server. Check upgrade tutorials for iRedMail.
If you run iRedMail server in a jailed FreeBSD system, restored SQL database on new jailed system may have privilege error like this:
ERROR 1449 (HY000): The user specified as a definer ('root'@'10.195.20.1') does not exist
iRedMail installer created SQL tables (or VIEWs, TRIGGERs) as
10.195.20.1 was private IP address of your old Jail system), but this
address was gone on new jailed system. You must replace old IP address by the
new one before restoring the SQL tables, otherwise, triggers might have to be
re-created manualy later. For example,
perl -pi -e 's#`root`@`10.195.20.1`#`root`@`10.20.21.3`#g' vmail-2020-04-26-01:25:21.sql perl -pi -e 's#`root`@`10.195.20.1`#`root`@`10.20.21.3`#g' amavisd-2020-04-26-01:25:21.sql
Then import this modified SQL file instead.
Set correct file owner and permission of mailboxes. Default owner is
vmail, permission is
With SQL backends, you can get full maildir path of user with below SQL command:
mysql> USE vmail; mysql> SELECT CONCAT(storagebasedirectory, '/', storagenode, '/', maildir) FROM mailbox WHERE email@example.com';
homeDirectoryof mail user object. You can query with
ldapsearch -x -o ldif-wrap=no -D 'cn=Manager,dc=xx,dc=xx' -W -b 'o=domains,dc=xx,dc=xx' "(firstname.lastname@example.org)" homeDirectory
mlmmj mailing list was introduced in iRedMail-0.9.8.
Mailing lists are stored in 2 places:
/var/vmail/mlmmj: it stores active mailing lists.
/var/vmail/mlmmj-archive: it stores removed mailing lists.
For mailing list accounts, they should be migrated while migrating mail accounts mentioned in steps above.
For mailing list data, you can simply copy them to new server. After copied,
the data must be owned by user/group
mlmmj:mlmmj with permission
If you run same version of SOGo on old and new server, it's ok to migrate
data by simply exporting the
sogo SQL database and import to new server.
For SQL backends, you need to re-create SQL table
sogo.users after restored
GRANT SELECT ON vmail.mailbox TO sogo@"127.0.0.1"; CREATE VIEW sogo.users ( c_uid, c_name, c_password, c_cn, mail, domain, c_webmail, c_calendar, c_activesync ) AS SELECT username, username, password, name, username, domain, enablesogowebmail, enablesogocalendar, enablesogoactivesync FROM vmail.mailbox WHERE enablesogo=1 AND active=1;
_postgresfirst, then run
psql -d vmailto connect to
vmaildatabase (SOGo is configured to query users from
vmaildatabase since iRedMail-1.6.0, so that end users can change their own passwords):
-- create SQL view in vmail database. CREATE VIEW sogo_users AS SELECT username AS c_uid, username AS c_name, password AS c_password, name AS c_cn, username AS mail, domain AS domain, enablesogowebmail AS c_webmail, enablesogocalendar AS c_calendar, enablesogoactivesync AS c_activesync FROM mailbox WHERE enablesogo=1 AND active=1; -- allow end users to change their own passwords. GRANT SELECT,UPDATE ON mailbox TO sogo; GRANT SELECT,UPDATE ON sogo_users TO sogo;
It's strongly recommended to practice with a testing machine and verify the calendars, events and contacts after migrated.
iRedMail has daily cron job to backup SOGo data with script
/var/vmail/backup/backup_sogo.sh, you should run it manually
right before migration so that all recent data are exported.
Backup copies are stored under
Copy the latest backup file to new server, then follow this tutorial to restore it: How can I backup/restore my user data?
Export those database on old server, then import them on new server.
Amavisd will read DKIM keys and sign outgoing emails. DKIM keys are stored
/var/lib/dkim by default, you can copy all keys under this directory to
new server, and make sure they have correct file owner
If you prefer generating new DKIM keys on new server, don't forget to update DNS records for mail domain names.
After migration, please recalculate mailbox quota by following this tutorial: