Upgrade cyrus and split mailboxes

cyrusmailboxmigration

I'm trying to upgrade a Cyrus IMAP server from 2.2.12 to 2.4.12/13.

Right know I'm looking for a good guide to do it, as my actual version is an old release. I guess it will not just be upgrade the version or install the new one and import the configuration, am I wrong? I assume I will need to migrate the database information, but do not know how to go about doing so.

Our main and unique Cyrus server is managing more than 10000 users and their corresponding mailboxes. With the new migration we want to split this main server into smaller servers to split the mailboxes by client. How can export I just a few mailboxes from Cyrus 2.2.12? I want to export the mailboxes selectively.

I found "Mailsync" tools, but it does not look like it can be selective with mailbox. Is there any way to migrate to the new version of Cyrus properly?

Best Answer

(About eight years ago I migrated more than 50 000 user accounts from an old mail server (running uw-imapd) to a new server 'farm' consisting three servers and running Cyrus. At that time I used my l337 Perl skills for creating a migration script which would login to old server and copy the mails the new server over IMAP one user account at a time. An OpenLDAP server + Perdition was in front of this thing deciding where a user should be forwarded (to old server or to new server). The operation was done on-line without any downtime. This is going off-topic, so I'll continue with my reply.)

A word of warning: the job you are going to do can be a bit tedious and typing a short enough reply for you is not easy, either. :-) Here are some points for you to consider.

You have some work to do. Upgrading Cyrus itself is not that impossible, but splitting the users from one server to multiple servers at the same time requires planning. Just copying everything from the old server to new does not work, since BerkeleyDB/skiplist format has been changed in the middle and the old data files are not usable out of the box.

When it comes to user/mailbox list, it's better to use ctl_mboxlist -d switch to dump the user/mailbox information at the old server to a text file, and then ctl_mboxlist -u to load the contents to the new server. This is the case if you only would upgrade Cyrus and at the same time moved to a more powerful, yet only single server. The mailboxes can be copied over with rsync, followed by reconstruct -rfx user/* command in Cyrus.

If you want to do the split at the same time, you might want to try if xfermailbox command in cyradm nowadays actually lets you move mailboxes from one server to another. If it does, you can just create a script which calls xfermailbox 10 000 times and moves your user accounts wherever you want.

Another tip: You probably need reconstruct -rfx user/someaccount command if you find that after migration some user cannot find the mail folders / mails.

All fine and dandy until this, but have you considered the following:

  • If you are going to split the users among multiple servers, do you have something like Perdition or Cyrus Murder taking care of redirecting POP/IMAP logins to correct mail server?
  • If splitting, do you have OpenLDAP or some other centralized authentication / user management in place?
  • If splitting, have you configured your Postfix or whatever SMTP server to figure out where the user account actually is?
  • Do you currently have performance problems? 10 000 user accounts is not very much and unless you truly have some serious reasons for splitting the user accounts across multiple servers, you should carefully reconsider this. A centralized storage of some kind + two semi-powerful servers configured in active/passive failover mode might be more wise and more simple in terms of system administration. Of course, having multiple smaller servers with local disks might help to spread I/O load, but Cyrus says 'Thank you' if you give it enough RAM and I/O should not be a real problem.
  • If the reason for your decision to split the load to across multiple servers is due performance problems, please double-check if your Cyrus is using BerkeleyDB or Skiplist for mailboxes.db etc. BerkeleyDB without a well-tuned DB_CONFIG might easily kill the performance and/or lead to deadlocks. Skiplist is more worry-free. Also the POP3 implementation in Cyrus is very entropy hungry and if your server doesn't have a hardware based random number generator, the logins might be VERY slow without rngd daemon, or Cyrus configured to use /dev/urandom instead of /dev/random for randomness.

I hope this helps you a bit.

Related Topic