Перенос почтового сервера

В 2018 году не может возникнуть такого вопроса. Никто не будет переносить сервис на сервер, где что-то уже крутится. Добро поджаловать в мир виртуализации. Один сервис (группа сервисов как единый сервис) - одна виртуалка.

Сам подход опасен. Вы собиратесь находу перелопачивать сервер в продакшене (на нем уже что-то крутится).

Но если вы все же хотите того, что вы хотите. То в вашем случае есть только конфиги и mysgql и письма. Установка пакетов, копирование конфигов, дамп/рестор базы(баз)/ синхронизация писем. Все просто.

Я переносил почтовик с реального железа в виртуалку.

На ходу без остановки исходного сервера был сделан архив его системы. Т.е. сделан stage4 архив, как в случае Gentoo, за исключением директорий с базами данных, директории с письмами и части /var/log.

В виртуалке развёрнут этот архив, сделан chroot и установлен загрузчик, отредактирован /etc/fstab, т.е. система в виртуалке подготовлена к самостоятельной загрузке.

Далее по сети rsync`ом поверх ssh копировалось содержимое maildir, когда всё скопировалось на исходном сервере были остановлены почтовые сервисы, база данных, она скопирована на целевой.

На целевом подняты сервисы почты.

Поправлена зона DNS, т.к. на новом изменилось доменное имя.

Ещё одна синхронизация rsync`ом maildir для переноса писем, которые были получены пока происходила прошлая синхронизация.

С исходного сервера удалены postfix, dovecot и прочие ненужны там сервисы.

Всё, это делалось на ходу, время простоя минут 5 пока была остановлена база данных.

На новом то и крутится сайт и облако. особо то и «перелопачивать» нечего. Сервер и был ориентирован только на облако и почту. Просто да изначально надо было все вместе перебрасывать. Ну что же что сделано то сделано.

По сути ваш вариант мне скорей всего подходит с rsync и переносом базы.

Здравствуйте, это же просто почта, а значит, нет никаких проблем приостановить сервис - по стандартам письма никуда не денутся, а будут поставлены в очередь на отправку (до 5 дней, если я не ошибаюсь, причем первые 4 часа прозрачно для отправителей, далее отправителям будет отослано письмо о возникшей задержке с доставкой и просьбой не предпринимать никаких действий, а просто подождать). Иными словами, никто не мешает Вам погасить действующий сервер и спокойно скопировать конфиги/базу/файлы на новую машину. После ее запуска все отправленные за время даунтайма письма будут получены пользователями.

Не всегда. Все зависит от отправляющей стороны. Могут и не переслать. Пример из практики, почтарь был в дауне несколько часов, отправляющая сторона толи aol толи yahoo, так не переслали. емнип между отправкой письма и поднятием сервака было часа два.

Поправлена зона DNS
время простоя минут 5

Вот уж не верю что 5 минут. Есть «личности» которые на ttl кладут.
Но дополню ваше описание, «не забыть выставить маленький ttl в dns», а то может у ТС (или кто еще прочитает) выставлен на сутки и посчитают что за 5 мин все перенесется.

IMHO, это говорит о криво настроенном smtp-сервере у отправляющей стороны.

Но дополню ваше описание, «не забыть выставить маленький ttl в dns», а то может у ТС (или кто еще прочитает) выставлен на сутки и посчитают что за 5 мин все перенесется.

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

IMHO, это говорит о криво настроенном smtp-сервере у отправляющей стороны.

Я написал или aol или yahoo (просто не помню кто из них был, они оба «веселые»). Согласитесь это все-таки не совсем поддиванные почтари.
ЗЫ Помню когда это произошло, 2015-й конец июля - начало августа.

Согласитесь это все-таки не совсем поддиванные почтари.

Ну как Вам сказать, с aol, к счастью, дел не имел, хотя наслышан о «качестве» их почты. А у Yahoo очень много закидонов. Помню, у меня в течение нескольких дней не могло уйти письмо с вложением на 2 MB на yahoo-вский адрес - у них бы установлен таймаут на продолжительность smtp-сессии. Причем дело было в начале 2000-х годов, когда каналы были сами помните какие... Да и в итоге куча знакомых ушли оттуда - у кого-то отправленные письма терялись (мало того, что до адресата не доходили, так и уведомления о невозможности доставки, которое обязано быть по стандарту, тоже не было), кто-то важную корреспонденцию не получал...

А по поводу кривых настроек - вот цитата из RFC 5321:

In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender. A mail queue entry will include not only the message itself but also the envelope information. The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery.

Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days.

.

Иными словами, как я и писал выше, стандарты требуют наличия механизма повторных отправок писем. Причем предельный срок довольно большой - 4-5 дней. А то поведение почтового сервера, которое Вы описали, является прямым нарушением этих стандартов.

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

Ну собстно говоря гугля тоже так делает.

Да и в итоге куча знакомых ушли оттуда

В рашке особой популярности у них никогда и не было. Но вот за «бугром» народ активно пользуется и по сей день.

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

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

Поймите правильно, я с вами не спорю, лишь описываю что это не будет работать на 100%. Я сам при переносе почтаря, да и просто профилактических работах ориентируюсь на стандарты. На текущий момент вариантов «почему не дошла почта» достаточно много, начиная от банального, ошибся адресом (из вспомнившегося, у юзера from был с ошибкой, народ отвечает на письмо а оно не доходит).
И юзеры уж сами как-то решают этот вопрос, т.е. кому-то, принимающей или отправляющей стороне, письмо важно, находят другие способы связаться и уточнить получение письма и в случае чего пересылают заново.

Не в тему ТС и вообще я такого не советовал :). Напомнили еще один вариант переноса. imapsync. Пришлось пользовать при переносе с маил хостинга на свой почтарь. Других вариантов не было.
Подходит для переноса не больших объемов, при этом геморно и долго. В этом случае мы не пролюбим ни одного письма. Первая синхронизация, потом меняем dns, и еще несколько раз позже запускаем повторную синхронизацию. Т.е. письма так или иначе будут оставлены у пользователя, может с задержкой если они все еще прилетели на старый сервак или были отправлены через старый сервак. Но даже в такой схеме появился нюанс, пользователь за это время перенес письма в другую папку, так что получил дупы :)
Идеальная схема это репликация между бэкэндами, но писец как сложно, и в простых вариантах перенести сервак, не вижу смысла городить такой огород.

Здравствуйте! А не проще ли просто арендовать или купить отдельный сервер для ваших нужд? для бизнеса это идеальный вариант систематизации всей информации, вот https://www.westcomp.ru/ цены в зависимости от необходимого вам хранилища