Вопрос: Копирование / синхронизация электронной почты с живого сервера по сети


Сценарий выглядит следующим образом:

Копирование, а затем синхронизация с прямого почтового сервера через сеть (только) на другой сервер.

Почтовый сервер является живым, что много файлов (писем) изменяются, удаляются и создаются. Я пробовал rsync, но он очень медленный, и через некоторое время я получаю:

предупреждение: некоторые файлы исчезли, прежде чем они могут быть переданы (код   24) на main.c (1040) [отправитель = 3.0.5]

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

Это лучший вариант, желательно с минусами и плюсами для каждого подхода.

Важные факты:

  • 15 миллионов файлов электронной почты (в основном небольших размеров)
  • 1,45 ТБ данных

Обновить

Цель: Переход на новый сервер

ETA: как можно скорее

Обновление 2

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

Обновление 3

Я предпочел бы решения с открытым исходным кодом.


5
2017-08-15 11:55


Источник


Вы забыли указать временные требования и использование. Выполняете ли вы это для целей резервного копирования или для создания другого экземпляра почтового сервера? - Khaled
@Khaled - Спасибо, я обновил свой вопрос. - pl1nk


Ответы:


Один из подходов заключался в использовании Погибель для обработки соединений POP / IMAP, а затем просто настройте Postfix для маршрутизации SMTP на старый или новый сервер, в зависимости от того, где находится почтовый ящик пользователя. Таким образом, вы можете перенести свой сервер на один почтовый ящик одновременно без какого-либо простоя.

Конечно, вы можете настроить плановый перерыв на обслуживание, а затем просто rsync файлы. Однако копирование 15 миллионов файлов займет некоторое время. В зависимости от вашего сервера и, в основном, системы ввода-вывода, это может помочь запустить несколько процессов rsync параллельно; одно копирование файлов / dirs, начиная с [a-e], второе с [f-j], третье с [k-p] и т. д.

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

РЕДАКТИРОВАТЬ: Вы запросили дополнительную информацию о настройке «Порог», вы ее получили.

Вам нужно иметь центральное место, где хранятся ваши данные учетной записи пользователя. Это могут быть MySQL, PostgreSQL, OpenLDAP или что-то еще. Я всегда пользовался OpenLDAP с большим успехом. В любом случае вам необходимо иметь таблицу базы данных / схему LDAP, которая содержит имя пользователя и имя сервера, в котором находится почтовый ящик пользователя. Есть Утилиты миграции миграции которые помогут вам в начальной настройке.

Затем Perdition получает соединения POP / IMAP, ищет местоположение пользователя из LDAP или что-то еще и прозрачно проксирует трафик между почтовым клиентом пользователя и фактическим сервером. Postfix также может искать это фактическое местоположение сервера из LDAP / SQL и отправлять туда почту.

Вот PDF о настройке Perdition + LDAP а также вот руководство по Postfix LDAP,

Затем просто создайте сценарий миграции, который копирует почтовые ящики по одному через IMAP с помощью imapsync или аналогичные утилиты, и после каждой успешной миграции почтового ящика он должен просто обновить OpenLDAP или любое другое центральное расположение о местоположении почтового ящика пользователя.

РЕДАКТИРОВАТЬ № 2:  imapsync Я говорю о бесплатном программном обеспечении и доступен в большинстве дистрибутивов Linux из своих репозиториев пакетов. Вы попросили меня подробнее рассказать о rsync подход; неважно, выбираете ли вы imapsync или rsync, основные принципы одинаковы. Вы просто создаете скрипт с bash, Perl или другим языком, с которым вам комфортно. Вот какой-то псевдокод.

@accounts = fetch_all_the_account_names_from_ldap();
for (@accounts) {
    rsync -avP /var/spool/mail/$user $newserver:/var/spool/mail/
    update_user_location_in_ldap($user, $newserver);
}

3
2017-08-15 12:44



Не могли бы вы предоставить дополнительную информацию об использовании Perdition (install / config / deployment)? - pl1nk
pl1nk: Помог ли мой расширенный ответ? - Janne Pikkarainen
+1 для вашего обновления, но развертывание гибели - это немного хлопот. - pl1nk
Даже мысль о смерти, похоже, помогает с простоями. Основная проблема (основная сфера этого вопроса) по-прежнему существует How to copy the data? - pl1nk
Вы копируете данные с помощью imapsync, Или, если хотите, конечно, вы можете использовать rsync один пользовательский каталог / файл почтового ящика за раз, и после того, как каждый пользователь просто обновит информацию о пользователе LDAP / SQL, чтобы указать пользователя на новый сервер. В моем случае (50 000 - 100 000 учетных записей пользователей) у самых быстрых учетных записей почти не было электронной почты и они были скопированы за считанные секунды, более активные учетные записи с гораздо большим количеством сообщений электронной почты занимали максимум несколько минут. - Janne Pikkarainen


Вы можете посмотреть, как разместить сервер в распределенной файловой системе. Вы можете использовать DRBD для выполнения репликации файловой системы. Ваш текущий сервер может иметь первичный сервер со вторичным (который у вас уже есть как новый сервер). Если первичный сбой, вторичный станет основным. Вы можете реализовать DRBD на текущем сервере, и первоначальная синхронизация будет прозрачно (без простоя) в backgroud для вторичного (нового сервера) без вашего уведомления. Нет файлов для копирования вручную. - http://www.drbd.org/


1
2017-08-15 13:24



Спасибо за вашу идею, однако сервер довольно старый, и я не могу рисковать устанавливать вещи, поэтому внедрение DRBD не является вариантом. - pl1nk


  1. Маршрутизируйте электронную почту на новый сервер, изменив запись MX для соответствующего домена (ов), чтобы указать на новый сервер электронной почты.

  2. Переместите все содержимое почтового ящика пользователя и направьте всех почтовых клиентов на новый сервер.

  3. Передайте все оставшиеся письма на старый сервер на новый сервер любым способом.


0
2017-08-15 14:43



Вы не описываете, самый важный шаг на пути перемещения всего содержимого почтового ящика пользователя на новый сервер. - pl1nk
Возможно ли время простоя? Да, сколько? - Chida
Время простоя неприемлемо, после первого большого копирования / синхронизации файлов все почтовые запросы будут перенаправляться на новый сервер. В этот момент некоторые пользователи будут «не видеть / видеть» некоторые из своих писем до тех пор, пока последняя синхронизация не будет завершена. - pl1nk


Этот рецепт отлично работал для меня:

1. Копирование примера первой группы файлов:

tar c dir/* |gzip - | ssh user@host 'cd /dir/ && tar xz'

В gzip вы можете иметь разные уровни сжатия, где -1 указывает самый быстрый метод сжатия (меньше сжатия) и -9 или --best указывает самый медленный метод сжатия (наилучшее сжатие). Уровень сжатия по умолчанию - -6 (т. Е. Смещен в сторону высокого сжатия за счет скорости). - gzip человек стр.

2. Использование демона rsync

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

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

3. Создавать cronjob каждые х часов, чтобы всегда иметь обновленную версию на удаленном сервере.

0 */03 * * * flock -n /Any_Dir/rsync.lock -c "nice -n 19 rsync --password-file=/rsync.passwd --delete-during -ra /source_dir/ user@rsync_server::ModuleName > /var/log rsync_cgp.log" 2>&1

В моем примере я запускаю процесс rsync каждые 3 часа, используя стая, чтобы создать файл блокировки, и позаботьтесь о том, чтобы 2-й rsync cronjob не запустился, если первый не был завершен. Кроме того, поскольку я не хочу забивать сервер, я изменил приоритет планирования rsync на 19 - очень выгодно. Наконец, я перенаправляю вывод rsync, перезаписывая файл журнала (чтобы он был маленьким по размеру). предосторожность: использование -v в rsync может привести к огромному файлу журнала.

Каждая продолжительность процесса rsync занимает ~ 16-30 минут, в зависимости от нагрузки сервера.


0
2017-08-24 11:22