Giuliano Gavazzi wrote:
> Sync-ing could only be done safely at a time
> when no mail is waiting to be transferred from one server to the
> other. So the sync-ing should first stop the mail servers, then check
> the queues and finally synchronise the secondary server to the main
> one (that also offers pop/imap)
Or check what users have deleted by watching for example the POP log, and delete
that from the backup. But that will be tricky as messages will look differnt on
each host (different path, different time of arrival).
Or go the coarse method: if a user POPs mail from A, assume he's seen it and
delete from B. Pity him if he just checked headers while roaming and his server
goes down. And doesn't work at all if he's using webmail or imap and just keeps
his mail around on the server - then I'd really think you need to stop incoming
mail, sync the mail, and allow deliveries again.
> My main concern is to be able to keep all incoming mail in duplicate,
> so that if a server has a hard failure new mail is not lost (except
> for what was being delivered at the time of failure) or even if the
> main server goes off-line for several hours, one could still access
> email logging in the other one.
You could solve that by setting delivery retry per domain, right?
> Clearly a RAID would be a simpler solution, but not necessarily as
> flexible, in particular when the two servers are 1500 Km apart and at
> one end there are not really technically minded people..
RAID doesn't guard against all problems. But syncing is dangerous too - what if
you sync an unmounted file system for example?
I'm curious what other ideas will come up. Double delivery is not that hard.
Double delete is. Just stick a web interface on the backup, auto delete after 7
days, and call it the 'backup server'?
