Move of mailboxes

[Nikos Gatsis - Qbit]

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 at qbit.gr
http://www.qbit.gr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20110505/a22d020a/attachment-0001.html