настройка резервного почтового сервера

Но когда я запустил основной сервер письмо так и осталось на резервном.

Интересно, а кто его должен переложить ? MTA тут вообще никаким боком, MTA только получает и куда-то складывает. Попробуй fetchmail-ом перекладывать, что ли. Или Cyrus Murder посмотри (хотя, по беглому взгляду, приём почты с мурдером останавливается, случись что).

в postfixadmin есть возможность поставить галочку «Резервный MX». тогда не понятно что делать с репликацией. делать репликацию на отдельные таблицы? как быть с синхронизацией пользователей? ручками делать изменения поочередно на каждом сервере?

в postfixadmin есть возможность поставить галочку «Резервный MX»

Я не знаю, что такое postfixadmin, а «Резервный MX» - это резервный MX. MX c худшим, относительно основного, приоритетом.

$ host -t mx gmail.com
gmail.com mail is handled by 40 alt4.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 30 alt3.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com.

Вот MX-ы, которые имеют вес более 5 (цифры от балды, главное тут больше/меньше), и есть резервные. Ничего более.

делать репликацию на отдельные таблицы ?

Какие таблицы ? Про пользователей именно ? Можно. Только это не вопрос MTA, а вопрос СУБД. Как и синхронизация ящиков не вопрос MTA, а вопрос системы хранения сообщений. Можно, наверное, DBmail посмотреть, если синхронизация нужна действительно - возможно, с ним это и получится, не знаю. Правда, тут это будет тоже дело СУБД, наверное.

Смотри. По дефолту повторы пересылки письма на упавший сервер длятся 5 дней. Если у тебя предвидятся такие авралы, то ман ocfs, gfs.

relay_domains прописан, очередь сообщений пустая на резервном сервере, записи МХ тоже прописаны корректно. PS: кластерные фс и DBMail вещи несомненно крутые, но ведь постфикс сам должен этим уметь управлять.

Умеет. Делается через relay. Но вот незадача: приоритеты в днс соблюдают единицы серверов. Т.о тебе будут слать письма на оба сервера рандомно.

Самый оптимальный способ в твоем случае: а) ручное включение релея (все письма удержит в течении 5 дней резервный сервак и как только поднимется основной — все письма придут); б) резервный сервак всегда должен быть закрыт извне пока работает основной. Альтернативное решение, как я уже предложил общий сторадж: в таком случае какой бы сервер не получил письмо, оно ляжет в общую «корзину».

relay_domains - «Домены для пересылки». Это самая короткая секция. Здесь указываются те домены, почту которых наш сервер будет стараться переслать дальше соответственно старшинству MX записей для этого домена. Например, это может быть использовано при создании резервного сервера.

http://wiki.dieg.info/postfix_backup_mx

http://it.it-vt.ru/2012/11/backup-mx-postfix.html

postfixadmin

не нужон

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

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

http://www.securitylab.ru/vulnerability/419731.php

да лучше пользоваться общаковскими дырявыми веб-мордами, чем запилить свою БД под мыло и набросать морду на пыхе.

но ведь постфикс сам должен этим уметь управлять.

Нет. Это только MTA. Кроме этого он ничего больше не обязан делать.

только твое поделие может оказаться дырявее всех «общаковских дырявых веб-морд» вместе взятых

только твое поделие может оказаться дырявее всех «общаковских дырявых веб-морд» вместе взятых

ну да, ну да. эксперты в студии.

Но вот незадача: приоритеты в днс соблюдают единицы серверов.

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

а) ручное включение релея (все письма удержит в течении 5 дней резервный сервак и как только поднимется основной — все письма придут);

Резервный тут не нужен вообще: почта спокойно полежит на релеях отправителей.

Альтернативное решение, как я уже предложил общий сторадж:

Или fetchmail, который перекладывает сообщения с резервного, или прописывать несколько серверов для получения у пользователей, правда, нужен клиент, который не ругается в окошке при ошибке получения.

У меня есть программисты, мы написали даже проще морду для эникеев, но далеко не везде есть программисты и админы способные на это, а вот поставить postfixadmin могут практически все.

далеко не везде есть программисты и админы способные на это, а вот поставить postfixadmin могут практически все.

это понятно.

любой может изучить код такого софта и структуру его БД это значительно увеличивает риски и если есть возможность его не использовать или заменить - нужно это делать.

знаешь, когда в питере или москве у админа з\п ниже 40, я не вижу смысла заменять.

По хорошему, вам не убирать записи из БД на резервном сервере надо, а передлывать конфиг, чтобы резервный postfix при приёме письма проверял существование адресата (по базе). Но не считал этот домен своим, а пытался переслать письмо дальше на основной сервер.

Иначе у вас потенциально возникает backscatter письма, так как в вашей настойке резервный будет принимать все письма для почтового домена, а основной будет принимать от резервного только письма для существующих пользователей.

Резервный тут не нужен вообще: почта спокойно полежит на релеях отправителей.

Полежит неизвестное и неконтролируемое время. Свой запасной сервер можно (попытаться) настроить проверять доступность основного хоть каждую секунду.

Вообще мне тоже интересен опыт народа в плане резервирования почты - каналов связи и/или серверов

Полежит неизвестное и неконтролируемое время.

Ох... Как утомляют эти все новые сисадмины, у которых ничего неизвестно и которые ориентируются на «в вот в Гугль почта у меня ходит» и т.п. Изучайте RFC. В частности RFC 1123 (5.3.1 SMTP Queueing Strategies). А отклонения от рекомендаций касаются только того, кто от них отклоняется. Он должен знать, что делает.

Вообще мне тоже интересен опыт народа в плане резервирования почты

А опыт этот давно описан.

1. Mail Storage. Это - самое главное. Вот он должен быть зарезервирован по самое, от него единственного всё и зависит. При нём должна быть база пользователей, ящики и т.п. База может быть в LDAP, сервер LDAP может быть сам по себе зарезервирован.

2. MX-сервер. MX принимает почту и складывает её на Mail Storage, очевидно, по LMTP.

В общем-то всё. MX-ов можно наплодить неограниченно. Как с разными приоритетами, для резервирования, так и с одинаковыми, для балансировки нагрузки. В последнем случае резервирование будет побочным эффектом.

А дальше начинаются нюансы реализации в зависимости от выбранного ПО для MX и Mail Storage (запросто могут быть даже разные MTA, главное, чтобы с одним Mail Storage работали, но это уже и так на 90% сделает LMTP).

Вы сами свою ссылку читали?

In general, the retry interval SHOULD be at least 30 minutes
... favoring a policy of two connection attempts in the first hour the message is in the queue, and then backing off to once every two or three hours.

Если связи не было несколько часов, по RFC еще несколько часов можем ждать, пока придет вся накопленная на серверах отправителей почта. Это конечно не фатально, но если можно уменьшить, почему бы и нет?

Про MX мне все понятно, интересно про хранение базы сообщений. Из конкретного выше упоминали распределенные фс, но как-то теоретически, без слов «я так делал, было N пользователей, за M месяцев K проблем связанных с распределенностью»

И X мегабайт общий размер ящиков, конечно.

Вы сами свою ссылку читали ?

Много лет назад (более десяти ;-) ). Я пол-часа где-то потратил, чтобы только вспомнить, в каком RFC это было...

по RFC еще несколько часов можем ждать

Если на сервере серьёзная авария, почему бы и нет ? Это раз. А два - если это неприемлемо, работай с системой хранения. На HA-кластер можно попробовать взгромоздить. Опять же, MX-ы могут принимать в соответствии с наличием пользователей LDAP, после чего класть в свой спул.

интересно про хранение базы сообщений.

Мне небольшой простой не критичен. Серьёзный внешний сторадж (от Infortrend). К нему по SCSI присоединена коробка с сетевой платой и процессорами. Сдохнет - прицеплю другую. Если сдохнет коробка от Infortrend, будет не сильно хорошо, тут уже долго поднимать из бакапов, на чём придётся. Но коробка от Infortrend, сама по себе, с резервированием. Сейчас бы я брал уже не с SCSI, а с Fibre Channel. Или с iSCSI, если надо подешевле.

И X мегабайт общий размер ящиков, конечно.

У меня лично около сотни гигов (в смысле один мой ящик). Софтверный сторадж - Cyrus-IMAP.

У меня лично около сотни гигов

Нет, что-то я махнул раза в два с лишним. Несколько меньше сорока, на самом деле. И не одним каталогом: всё разложено по разным фолдерам, которые организованы, как каталоги.

Я неточно выразился, имел в виду географически распределенное резервирование. Но вот сейчас подумал над возможной реализацией (как например клиенты извне сети будут переключаться с офисного сервера на находящийся в датацентре? своя AS и PI адреса? отпадает, не тот масштаб) и понял, что это не особенно нужно. Достаточно поставить сервер в самом надежном из имеющихся мест, а в остальные разливать просто бакапы.

За опыт спасибо.