try this: http://cynici.wordpress.com/2010/12/06/how-to-migrate-32-bit-cyrus-imapd-mailboxes-to-64-bit/
On 5/5/2011 1:08 μμ, Matt Elson wrote: >> Is there a recommended procedure to do the move? Any pointers (even to >> pitfalls) are welcome. > I'm actually in the middle of migrating two backends of a Murder > (2.2.13p1) to new machines (and Cyrus version, 2.3.16, though it doesn't > sound like you're switching Cyrus versions in your case). Full > disclosure, no idea if this is the recommended procedure and 2.2.13's > probably too old to be that useful, but it's been working for me. > > The way I've been doing it is writing a small script that: > > 1) Checks $cyrus_var/proc to see if the user is logged in. > 2) If they are not, connects to one of the proxy frontends, changes > permissions on the mailbox to (temporarily) stop the user from > manipulating it if they were to log in mid transfer. > 3) Issue a rename (which I think ultimately just makes an XFER call to > the appropriate backend?) of the format: "user.melson user.melson > mailboxes3.example.com!partition1" (for example). > 4) Set the permissions back to normal after success. (I may be changing > this permission switching to temporarily deny the user authentication, > that method just didn't fit my environment when I started this). > > The script's just some perl using Cyrus::IMAP::Admin, and it should be > fairly easily to replicate in anything with an IMAP library. > > (It's basically the same process I use to shuffle people between > backends in the murder environment normally, which was handy from a > laziness standpoint; the process is used for moving from 2.3.16->2.3.16 > backends as well) > > It's been pretty successful so far, no user has noticed anything amiss > (that said, most of my users are relatively light users), and delivered > email just gets queued up during the transfer as near as I can tell. > I've found it to be an ideal way to go about migration/upgrades - I can > introduce users into the new environment slowly to catch configuration > "glitches", make sure I didn't misjudge the resources I would require, > etc, etc. Very handy. It's been good about catching problems, even (I > have a customization that extends the valid characters in mailboxes I > forgot to apply on the new machines; the XFER noticed right away and > left the user's mailbox unmoved and unmolested) > > Oh, one thing I forgot - I'm fairly sure you *do* have to set > allowusermoves: 1 in your configuration if you're using this method. > > The gotchas I've run into are probably more quirks of the environment > I'm working with or relics of a relatively old Cyrus at this point, but > I'll share them in case they are useful. > > *) I've had some weirdness if the transfer gets interrupted in the > middle (I forget the exact symptom, but the mailbox on the home spool > was flagged as REMOTE (or something like that), but it hadn't actually > made it over to the new machine - a simple ctl_mboxlist -m on the > backend fixed it up since the frontend had the right information). > *) This is probably more my environment than anything else, but I've had > to throttle the moves and not run too many simultaneous moves in > parallel or I basically overwhelm the server I'm migrating from - it > seems to actually be the delete of the mailbox from its old home that > hits the hardest. I've not looked into it much, because, old crusty > server (2.4 kernel, ext3 file system; like I said, probably my > environment :P). > -- ------------------------------------------------------------------------ *Γατσής Νίκος - Gatsis Nikos* Web developer tel.: 2108256721 - 2108256722 fax: 2108256712 email: ngat...@qbit.gr http://www.qbit.gr
---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
