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

Давно не писал статей с прикладными задачами, все больше обзоры да руководства. Сегодня расскажу о том, как на практике перенести почтовый сервер postfix на другое железо или виртуальную машину. Поделюсь своим подходом к решению подобной задачи с минимальным простоем.

Введение

В статье я буду описывать почтовый сервер, настроенный примерно так же, как описано у меня в статье про настройку почтового сервера на базе postfix. Версии софта принципиального значения не имеют. Важно, что почтовая база хранится в формате maildir, все письма на сервере. Основная проблема переноса таких серверов - очень долгая синхронизация почтовой базы сообщений, состоящей из десятков и сотен тысяч мелких файлов. Если у вас обычные sata диски, просто взять и перенести почтовый сервер на новое место с минимальным простоем не получится. Надо что-то придумывать.

Я придумал такую схему переноса:

1. Подготовка системы на новом месте.
2. Копирование основной почтовой базы на новое место.
3. Остановка старого сервера, заливка изменений в базе на новый сервер.
4. Запуск нового почтового сервера как основного.

Я всегда настраиваю сервера так, что системный диск небольшого размера - 30-50 гб. Все данные, будь то почтовая база, файловый сервер, база данных, сайты и т.д. находятся на отдельном диске. Главное, не экономить сильно и не делать системные диски очень маленькими, как однажды сделал я, сэкономив место на дорогих ssd дисках. Потом пришлось на ходу расширять системный раздел. Оптимально на моей практике это не меньше 30 гб. Если меньше, то приходится ужиматься с логами, кэшами и т.д. Не очень удобно. Все, что больше 30 уже не проблема. Если надо больше места, подключаются отдельные диски и символьными ссылками расширяются проблемные места.

С таким подходом удобно бэкапить виртуальные машины. Я на уровне гипервизоров делаю бэкап только системных дисков. Для данных использую другие способы, например rsync. Иногда и то, и другое. Бэкапить только гипервизором огромные диски по несколько ТБ данных не удобно. А в некоторых случаях практически невозможно, так как нет возможности сделать инкрементный бэкап. Например, в proxmox мне не известен способ централизованного управления и создания инкрементных бэкапов. Для других гипервизоров какие-то решения есть.

Подготовка нового сервера

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

Тут важно не торопиться и все проверить тщательно. У меня была ситуация, когда после переноса почтового сервера с одного гипервизора на другой, на сервере стало очень сильно убегать вперед время. Буквально на 1-2 минуты в час. Я это сразу не заметил, не обратил внимание. А когда запустил в работу новый сервер, увидел, что к концу рабочего дня время убежало уже на 15 минут. Синхронизация тут не спасала, так как dovecot, замечая большие изменения во времени после синхронизации, просто аварийно завершал работу. Для него это типовое поведение в таком случае.

Было очень неприятно словить такую ошибку на рабочем сервере. Потом в итоге разобрался, в чем дело. Изменил настройки grub для данной виртуалки, связанные с прерываниями процессора, и время перестало убегать. Но это потребовало тестов и перезагрузок уже на рабочем сервере, что было неудобно. Лучше бы я все отладил с самого начала, благо время было. Я все это к тому, что не торопитесь с переносом. После того, как поднимите систему на новом железе, оставьте ее поработать некоторое время, убедитесь, что все в порядке.

Как я уже сказал, не важно, переносите вы текущий сервер или настраиваете новый. Если новый - то так же настройте все, отладьте, проверьте. Дальше назначьте какие-то ip адреса новому серверу, чтобы был сетевой доступ к старому. Если переносите старый сервер, не забудьте на новом месте сменить MAC и IP адрес у сетевого интерфейса. Бывало, что я забывал сменить MAC. Начинались непонятные сетевые проблемы с обрывами соединений. Не сразу догадался, в чем было дело.

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

Перенос почтовой базы

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

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

# /usr/bin/rsync -av root@10.1.4.22:/data/mail /data

Здесь мы просто копируем почтовый архив со старого сервера 10.1.4.22 из директории /data/mail на новый сервер в эту же директорию. Не ошибитесь со слешами в конце путей. Я иногда путаюсь, после запуска сразу останавливаю процесс и проверяю, что все копируется именно оттуда и именно туда, куда надо. Чтобы команда точно отработала даже при обрыве ssh соединения, запускаю ее в screen.

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

После того, как скопировали основную часть почтового архива, переходим к переключению на новый сервер.

Переключение на новый сервер

Самый важный и ответственный этап переноса почтового сервера. Здесь нужно еще раз хорошенько все проверить, убедиться, что все работает нормально. Непосредственно перед переключением на новый сервер, можно еще раз накатить изменения почтовой базы без остановки старого. Это позволит максимально уменьшить время простоя. Когда все готово, останавливаем службы dovecot и postfix почтового сервера. После этого сразу же запускаем синхронизацию каталогов между старым и новым сервером. Мы накатываем все изменения почтовой базы, делая ее полностью актуальной в новом сервере. Для этого надо добавить ключ --delete к rsync.

# /usr/bin/rsync --delete -av root@10.1.4.22:/data/mail /data

Важно не перепутать источник с приемником. Сначала идет старый сервер, потом новый. Перед запуском хорошенько проверяйте команды. Один раз я угробил новый сервер, ошибившись в команде и удалив с корня системы некоторые каталоги. Просто слешом ошибся на источнике, когда копировал в корень приемника. Это было не страшно, так как повредил новый сервер. Пришлось отложить перенос и восстановить его.

Ждёте окончания синхронизации. Она должна быть не долгой, так как перед остановкой почтового сервера вы и так накатили все изменения. Обычно несколько минут занимает процесс финального копирования. Когда он закончен, выключаете старый сервер, убираете его из автозагрузки гипервизора. На новом сервере меняете IP на адреса старого сервера и перезагружаете его. Можно и не перезагружать, но я для проверки всегда перезагружаю. Можно не менять IP адрес, если у вас все завязано на dns имена, отредактируйте dns запись. Но я обычно все же меняю ip, так надежнее. Обязательно найдется какое-нибудь старое оборудование, типа сканера, где адрес указан в виде ip адреса и т.д. Эти лишние проблемы потом не нужны. Лучше все сделать максимально незаметно и надежно.

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

Бывает, что не все идет гладко. У меня были ситуации, когда после перехода уже на новый сервер, начинались проблемы, которые предусмотреть заранее было нельзя. Новое хранилище начинало тормозить или возникали еще какие-то проблемы. Например, с блокировками на nfs. Вы это не проверили заранее. С работой dovecot на nfs есть свои нюансы. Если вы понимаете, что оставить в работе новый сервер нельзя и надо откатываться, то нужно опять синхронизировать почтовую базу, если для вас важна та корреспонденция, которая была доставлена в то время, как поработал новый сервер. Для этого останавливаете почтовые службы на новом сервере, меняете на нем ip, запускаете старый и выполняете синхронизацию в обратном порядке - с нового на старый. Не ошибитесь в параметрах rsync! После этого оставляете старый сервер в работе, а с новым спокойно разбираетесь и готовите его еще раз к переносу.

Вот, в принципе, и все по переносу почтового сервера из моей практики. Я их переносил штук 10 за все время админства. Можно сказать руку набил.

Заключение

Для того, чтобы любые работы на prod сервере прошли успешно, я всегда соблюдаю несколько правил:

1. Никогда не тороплюсь. Если реально нет необходимости спешить, я всегда довожу до руководства, что спешка не нужна. Она вредит и мешает все сделать хорошо. Пусть лучше я спокойно неделю или две подготовлюсь, все обдумаю, проверю и перенесу без проблем, нежели я буду спешить для соблюдения бессмысленных сроков.
2. Тщательно все проверяю и перепроверяю. Делаю все максимально незаметно. Если простой ожидается маленький, не шлю никому никаких уведомлений. Если вы предупредите, что будут работы с почтовым сервером, на следующие дни обязательно кто-то нажалуется, что после переноса все сломалось. Это мешает снимать реальные обратные связи. Когда никто не знает о переносе, отзывы будут только на реальные проблемы, а не надуманные.
3. У меня всегда есть запасной план на случай, если что-то пойдет не так. Всегда под рукой актуальные бэкапы и подменные системы. Я точно знаю, что буду делать, если новый сервер не будет введен в эксплуатацию.

Этого достаточно, чтобы успешно проводить любые работы на серверах. Главное, все запланировать заранее, чтобы не было спешки. А как вы планируете масштабные обновления или переносы prod серверов?

Помогла статья? Подписывайся на telegram канал автора