2

I have a Zarafa server (with Postfix as delivery agent) that I would like to add realtime backup to. It already:

  • Backs up it's database with mysqldump and all the file system using rdiff-backup every night.
  • Has a fallback using DRBD (machine is a Xen virtual machine with DRBD backend). So in case primary goes down, I can bring up the virtual machine on the backup host instantly.

In case of file system/database corruption, I would like to have a realtime backup of incoming mail as to prevent loss of those messages received after the nightly backup.

Zarafa delivery works like this (excerpt from Postfix' main.cf):

mailbox_transport = zarafa: zarafa_destination_recipient_limit = 1
virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf

The mailbox transport (as defined in master.cf) is a tool that accepts data on stdin to deliver into Zarafa's store (mysql + file based). Virtual_alias_maps is an SQL command which basically return the j.doe in [email protected], but only for existing users. In other words, it retrieves the Zarafa username from the e-mail address.

One thing I can think of, is to deliver all mail to a second transport which sends it to another server. This server can be a simple courier maildir server and fetchmail can be configured to redeliver using SMTP to a server restored from backup.

But, this is not 100% elegant and I wouldn't even know how to do it...

Any better/implementation ideas...?

Edit: I now have a second mailserver configured so that it dumps all incoming mail for the relevant domain into one mailbox with X-Original-To: and Delivered-To: headers, so I can retrieve them using fetchmail and deliver them to those addresses (fetchmail has an option for that, I've been told). Now to let Postfix on the primary deliver to two transports...

1 Answer 1

2

Several approaches might fit your needs here. One of them is DRBD, but I would recommend that only for High Availability and mission critical systems.

  • MTA-level backup does not take changes to your mail into account (flags, read/unread, move to folders, sent items) and doesn't include other groupware items like calendering for example. I consider this not an option.
  • MySQL-level replication does it near-realtime. Set up a slave on a remote location and in case of an emergency just promote it to be your master. Additionally, using mysqldump on a slave has way less impact on your production environment. Do also check that you keep your attachments in sync (usually on file system) and you need to check your slave's integrity regularly.
  • MySQL-level InnoDB hotbackup. You could use Percona's toolkit to create hot backups of your Zarafa database not-so-frequently and rsyncing the binary log files very frequently (after flushing the logs). One can replay the logs on the older consistent snapshot to get a point-in-time recovery.
  • Use Zarafa's Archiver. It also provides Archive-on-delivery in combination with the dagent and while it's called 'Archiver' it can do more that just archive mails.
  • Use Zarafa's MSR and keep it running in the background. It will keep your stores in sync on Zarafa-level.

If you're unsure about how to set up this at MySQL-level, I'd recommend playing around with it first, to get comfortable. I do recommend reading "High Performance MySQL" (O'Reilly) too.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .