On Sun, 20 Mar 2011, Lars Schimmer wrote: > > Cyrus should be able to handle the upgrade in place if you can shut > > down the source server, copy the files over, and bring it back up. > > Sure, but I got a new hardware and want to use the new hardware ;-) Well, if you can spare some extra downtime, I highly suggest playing it even safer, and running a reconstruct, quotafix, and (if you use it) re-squat-indexing every mailbox before you re-enable external access (LMTP, NNTP, IMAP, POP). Recompiling the sieve scripts might be good, too. I.e. disable all such services before migration, and enable imap only to localhost, so as to be able to talk to cyrus imap for administration purposes. Migrate, check everything (such as mailbox ACLs, etc), have cyrus do all in-place upgrades by reconstructing the mailboxes and fixing the quotas... all with any new mail savely stuck at the MTA queue, and no users trying to read mail. That way, you can check the logs and make sure cyrus did not find any weirdness before new data comes in or users change the state of their mailboxes. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
