Vicente Aguilar <[EMAIL PROTECTED]> writes: > We'd like to configure a backup of our primary e-mail server, which runs > qmail-ldap 20031101a on a 2 power supply, 2 CPU, 3 eth, RAID-5 SCSI > Intel server (so it should never totally collapse and send all data to > /dev/null, but we're playing being paranoid here).
Unless the box catches fire. Or someone spills Coke on it. Or kicks out the power cord(s). Or the circuit breaker gets overloaded and trips (unless each power supply is on a separate circuit). I'm paranoid about single-box solutions. > The idea is having an as-exact-as-possible replica of the primary server > (same distro, same qmail version, same config...) on a lesser machine, > so that in the event of a total catastrophe on the primary one, we can > manually (or automatically by means of mon, heartbeat or whatever) move > all our mail services to the backups server in a matter of minutes. We use multiple machines running qmail-ldap (and courier-imap) all sharing the same backend, separate mailstore over NFS. We install pre-tested/configured (solaris) packages on each so they're identical.You could do the same, if you exported your main box via NFS to the smaller box. Doesn't protect you against the fire/coke/tripping single-point-of-failure though :-( > The problem of course lies in keeping all the contents of both servers > synchronized. The LDAP users database isn't a problem thanks to slurpd. Yeah, LDAP's slurpd is great for this. > We think that keeping the queues in synch isn't worth it (too complex): We believe likewise. If we had a SAN, we'd put the queues on it so we could separate that from the actual MTA machine. We'd still leave the Maildirs on the NetApp/NFS so multiple MTA boxes could write to this shared storage. > - running rsync evey n minutes: > > - sending all incoming e-mails via qmqp to the secondary server. Optimal > as all incoming mails will be immediately sent to the backup, but how do > we delete mails as the users read them from the primary server? With > rsync again? Will they have the exact same name on both servers? > > - abusing in some way the clustering capabilities in qmail-ldap? Not > suer about this one as I've never used qmail-ldap clustering before. You're cloning mail delivered to the main box via SMTP on the backup box using QMQP. You could hack your POP/IMAP server to do likewise, proxying POP/IMAP commands to the backup's mailboxes in addition to changing the main server -- but that doesn't seem trivial. We've been worrying the same issues, but want our backup server(s) at a remote location: data copying over the WAN becomes expensive. If you don't use shared storage, you're gonna have file synchronization problems after you use your backup server, then your main server comes up. Need to make sure clients only change one system at a time, then probably manual fail-over and synchronize. Not terribly pleasant -- better if automatic -- but that's a lot harder to keep synchronized sanely. > Has any of you something like this running? Any other ideas or > suggestions, besides the classical "NFS server for the mailboxes + n > SMTP/POP heads"? Is this all too complicated, or over-paranoid? Even tho we're using this classical scenario, we need to do the same thing -- at a remote site in case there's a major calamity at our primary site. Since we're offering IMAP, the mail's gotta be available even if the primary server's at the bottom of a smoldering crater. Still wrestling with how to do that. Rsync? NetApp's SnapMirror? IMAP proxy to remote site? I appreciate your question and look forward to more discussion on this. Gracias.
