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

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

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

Но, проделав то же самое дважды, я бы рекомендовал подход Perdition. После первоначальной настройки это действительно избавляет от боли при миграции.

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

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

Затем 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);
}

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

1. Направляйте электронную почту на новый сервер, изменяя записи MX для рассматриваемых доменов, чтобы они указывали на новый сервер электронной почты.

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

3. Перенесите оставшуюся электронную почту со старого сервера на новый любым удобным для вас способом.

Этот рецепт мне понравился:

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 каждые x часов, чтобы всегда иметь обновленную версию на удаленном сервере.

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 часа, используя flock для создания файла блокировки и заботясь о том, чтобы второе задание rsync cronjob не запускалось, если первое не завершено. Кроме того, поскольку я не хочу забивать сервер, я изменил приоритет планирования rsync на 19 - наименее благоприятный. Наконец, я перенаправляю вывод rsync, перезаписывая файл журнала (чтобы он был маленьким). Осторожно: использование -v в rsync может привести к огромному файлу журнала.

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