Назад | Перейти на главную страницу

Резервное копирование входящей почты в реальном времени с помощью Zarafa + Postfix

У меня есть сервер Zarafa (с Postfix в качестве агента доставки), на который я хотел бы добавить резервную копию в реальном времени. Это уже:

Каждую ночь выполняет резервное копирование своей базы данных с помощью mysqldump и всей файловой системы с помощью rdiff-backup.
Имеет запасной вариант с использованием DRBD (машина представляет собой виртуальную машину Xen с серверной частью DRBD). Так что в случае выхода из строя основного я могу мгновенно подключить виртуальную машину на резервном хосте.

В случае повреждения файловой системы / базы данных, я хотел бы иметь резервную копию входящей почты в реальном времени, чтобы предотвратить потерю сообщений, полученных после ночного резервного копирования.

Доставка Zarafa работает так (отрывок из Postfix 'main.cf):

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

Транспорт почтового ящика (как определено в master.cf) - это инструмент, который принимает данные на стандартный ввод для доставки в хранилище Zarafa (на основе файла mysql +). Virtual_alias_maps - это команда SQL, которая в основном возвращает j.doe в j.doe@example.com, но только для существующих пользователей. Другими словами, он извлекает имя пользователя Zarafa из адреса электронной почты.

Одна вещь, о которой я могу думать, - это доставлять всю почту на второй транспорт, который отправляет ее на другой сервер. Этот сервер может быть простым почтовым сервером курьера, а fetchmail может быть настроен для повторной доставки с использованием SMTP на сервер, восстановленный из резервной копии.

Но это не на 100% элегантно, и я даже не знаю, как это сделать ...

Есть идеи лучше / реализации ...?

Изменить: теперь у меня есть второй почтовый сервер, настроенный так, что он сбрасывает всю входящую почту для соответствующего домена в один почтовый ящик с X-Original-To: и Delivered-To: заголовки, так что я могу получить их с помощью fetchmail и доставить по этим адресам (как мне сказали, у fetchmail есть опция для этого). Теперь, чтобы позволить Postfix на первичном сервере доставить два транспорта ...

postfix

Здесь вам могут подойти несколько подходов. Один из них - DRBD, но я бы рекомендовал его только для систем высокой доступности и критически важных систем.

Резервное копирование на уровне MTA не учитывает изменения вашей почты (флаги, чтение / непрочитание, перемещение в папки, отправленные элементы) и не включает другие элементы групповой работы, такие как, например, каландрирование. Я считаю это не вариантом.
Репликация на уровне MySQL делает это почти в реальном времени. Установите подчиненное устройство в удаленном месте и в случае чрезвычайной ситуации просто сделайте его своим хозяином. Кроме того, используя mysqldump на ведомом устройстве оказывает меньшее влияние на вашу производственную среду. Также убедитесь, что ваши вложения синхронизированы (обычно в файловой системе), и вам нужно регулярно проверять целостность вашего ведомого устройства.
Резервное копирование InnoDB на уровне MySQL. Вы можете использовать инструментарий Percona для создания горячих резервных копий базы данных Zarafa не так часто и rsyncочень часто загружать двоичные файлы журналов (после очистки журналов). Можно воспроизвести журналы на более старом согласованном снимке, чтобы получить восстановление на определенный момент времени.
Использовать Архиватор Зарафы. Он также обеспечивает архивирование при доставке в сочетании с dagent и хотя он называется «Archiver», он может делать больше, чем просто архивировать почту.
Использовать MSR Зарафы и продолжайте работать в фоновом режиме. Это позволит синхронизировать ваши магазины на уровне Zarafa.

Если вы не знаете, как настроить это на уровне MySQL, я бы рекомендовал сначала поиграть с ним, чтобы вам было удобно. Я также рекомендую прочитать «Высокопроизводительный MySQL» (O'Reilly).