Vicente Aguilar <[EMAIL PROTECTED]> writes: > That's the point (no pun intended). We want to configure this backup > system in order to avoid having a SPOF on the server without moving the > SPOF somewhere else (the NFS server in your scenario).
Right, but we're using a NetApp which has oodles of redundancy built into it already. We hope to get another down the road so we can cluster them. That should eliminate the NFS SPOF. > I still haven't taken a look at the source code, at this point we're > only trying to figure out the best way to do this... but as far as I > understand how the qmail-ldap clustering works (and I've never used it, > just read some docs and this list), whenever a server in a cluster > receives a POP/IMAP connection for a mailbox which is stored on another > server of the cluster, it proxies the connection to the right place > instead of doing local access to the mailbox. We would only have to > modify the behaviour of all this so that all the implied processes do > both things: local delivery/access _and_ proxying to the backup. It > shouldn't be that hard to make a quick-and-dirty(tm) hack, providing > that the code to do everything we want to is already there. Maybe > Claudio could sched some light about this... I was thinking the same thing: dupe the mail to the backup server with QMQP, then dupe the mailbox changes by doing local changes plus proxying the IMAP connections to the remote system. > Of course we would also have to deal with errors on the connection with > the backup, and provide some kind of mechanism (another queue?) to > re-sync the backup whenever there's been a network glitch. Yeah, that gets difficult. Plenty of challenges here. :-) Thanks.
