On Fri, 12 Apr 2002, Daniel Feenberg wrote: > Wouldn't rsync do a better job with an MTA using "maildir" format for > message delivery?
No, it won't work at all. Maildir locking relies on inode numbers which will be different on different disks. [now back to the long message I was working on...] Mailbox replication is nearly impossible due to locking problems and other race conditions. You can route around this in two ways: get clever down the stack with a snapshotting filesystem (LVM or if you have the means, get a pair of NetApps with SnapMirror), or get clever up the stack by rethinking the application. NetApp SnapMirror is great for master/slave disaster recovery but can't do multimaster (except perhaps if you have two similarly sized sites; filer A in Cambridge mirrors its vol0 to vol1 on filer B in London, filer B vol0 mirrors to file A vol1). But do you really need full replication, or can you reduce the problem space to "never lose email"? You have a lot less work to do if you can assume you need to replicate new messages *appended* to a mail spool and can ignore deletions, message flags, IMAP folder reorganization, etc. most of the time (except for a daily garbage collector). I've never taken the time to do an adequate writeup of what we do (my WIP at LISA was embarrassing) but I'm quite happy with the setup we have. New mail gets delivered to two Berkeley-format mail spools per user. One is read-only, the other is snarfed (that's the official technical term in the code and documentation) into an mbx-format INBOX more efficient for large mailboxes and IMAP access patterns. We rsync the append-only spool to another server every 30 minutes and rsync INBOX (and other IMAP folders) and the read/write spool once a day. In case of server failure (or an accidentally deleted email), the user simply logs on to the slave server. On IMAP login, the slave server automatically merges together the three places their mail could be: the INBOX rsynced over at 4am, the read/write mail spool rsynced over at 4am, and today's "archive log" which gets rsynced every 30 minutes. Yes, 30 minutes is a long time. I'm trying to think of a way to replicate in "real time" via SMTP (mail.local appends to local mail spool and forwards a copy to the slave server) but it's not obvious how to deal with bounces or forwarding loops. Pieces of this are scattered around http://carumba.com/imap/ http://my.brandeis.edu/bboard/seb/00001e.html http://people.brandeis.edu/~rcgraves/duplicate-spool.diff (we run postfix) We have 3 IMAP mail stores backing each other up in a round-robin fashion. Our assumption is that users stay with the same "home" server forever, and the replication is only intended for failover, and we only intend to fail over an entire server at a time. If you have users moving around between foreign offices these are bad assumptions. However you could store the user's "home" mail server in LDAP and determine whether to play the replication master or slave role on a per-user basis. -- Rich Graves <[EMAIL PROTECTED]> UNet Systems Administrator --- Send mail for the `bblisa' mailing list to `[EMAIL PROTECTED]'. Mail administrative requests to `[EMAIL PROTECTED]'.
