|
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: ngatsis@xxxxxxx http://www.qbit.gr |
---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
