Setting up replication - First steps...

[Aki Tuomi]

Some answers in between.


On 07.12.2016 06:21, SH Development wrote:
> Just had my first (non-Dovecot) server failure due to dried out caps on the motherboard.  Got me to thinking about my single-point-of-failure mail server.  Currently running Dovecot and Postfix with no issues, but want to start taking steps just to be safe.
>
> I currently run a filesystem backup every 24 hours to a tar file over NFS to another server in our rack.  I am backing up:
>
> /home/vmail
> /etc/dovecot
> /etc/postfix
>
> Unfortunately, the vmail directory has grown to 27GB and takes around 7 hours now to backup as described above.  Which leads me to start thinking about how quickly I could restore the server from a backup if need be, and that time is at least 7 hours just to copy and untar the files onto another hard drive. I’m sure I could hook up a HD up directly to the backup server, then I could considerably reduce the time, but I’m making the assumption that I won’t always have quick physical access to the location.
>
> So I believe my first step is to set up another server, on another IP, different hostname, with Dovecot and Postfix, and simply use the files from the /etc directories of the existing server to configure it (changing the IP and hostname of course).
>
> Am I on the right track so far?
Yes.
> Next steps involve setting up replication with dsync?
>
> If I have successfully setup replication between the two servers, does this mean users can then actually log into either server and have their “stuff” intact?  So I could set up DNS failover in case the primary server fails?  Would this make the setup acceptable for secondary MX as everything should sync to the primary server when it comes back online?
>
> Sorry for thinking out loud, but I want to make sure I’m understanding the bigger picture here.
>
> Jeff

If you have successful replication between two servers, users should be
able to use either server. But in practice it's a good idea to not hop
users between replicas, especially since many MUAs tend to open several
connections, and it can be problematic if you have lots of concurrent
changes on both sides.

It might be a good idea to setup some sort of frontend system, like
dovecot as proxy or haproxy to handle the traffic so it ends up in one
server at a time, at least for each user.

Since you already have NFS, you could consider making a clustered setup
with proxy-director-backend infrastructure, but this might be too large
change at this juncture, but something to perhaps consider in the
future. The benefits over this is that you do no need to use replication
to synchronize changes.

Aki