Copiar / sincronizar email de um servidor ativo pela rede

Question

O cenário é o seguinte:

Copiando e sincronizando de um servidor de e-mail ativo via rede (somente) para outro servidor.

O servidor de e-mail está ativo, o que significa que muitos arquivos (e-mails) estão sendo alterados, excluídos e criados. Eu tentei rsync mas é extremamente lento e depois de algum tempo eu recebo:

warning: some files vanished before they could be transferred (code 24) at main.c(1040) [sender=3.0.5]

Como o servidor está ativo, prefiro não aumentar significativamente a carga no servidor.

Qual é a melhor opção, de preferência com contras e vantagens de cada abordagem.

Fatos importantes:

• 15 milhões de arquivos de e-mail (em sua maioria de tamanho pequeno)
• 1,45 TB de dados

Atualizar

Propósito: Migrando para um novo servidor

ETA: o mais rápido possível

Atualização 2

Limitação do servidor: O servidor de e-mail ativo é executado em software e hardware antigos e eu não me arrisco a instalar nada lá.

Atualização 3

Eu preferiria soluções de código aberto.

    

Answer 1

Esta receita funcionou muito bem para mim:

1. Copiando o primeiro grupo de arquivos, exemplo:

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

No gzip você pode ter diferentes níveis de compressão, onde -1 indica o método de compactação mais rápido (menos compactação) e -9 ou --best indica o método de compactação mais lento (melhor compactação). O nível de compressão padrão é -6 (isto é, inclinado para alta compressão em detrimento da velocidade). - gzip man page.

2. Usando o daemon do rsync

Após os dados terem sido copiados, o trabalho do rsync é mais fácil e usando o daemon do rsync (supondo que você esteja em um ambiente controlado, já que os dados não são criptografados) o desempenho geral é de longe melhor.

Como tive que lidar com muitos arquivos pequenos, desativei a compactação rsync, os processos ficaram ~ 40% mais rápidos sem compactação.

3. Fazendo um cronjob a cada x horas para ter uma versão sempre atualizada no servidor remoto.

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

No meu exemplo, inicio um processo de rsync a cada 3 horas, usando flock para criar um arquivo de bloqueio e cuido para que nenhum segundo job de rsync seja iniciado se o primeiro não for concluído. Além disso, desde que eu não quero martelar o servidor eu modifiquei a prioridade de agendamento do rsync para 19 -final favorável. Por fim, eu redireciono a saída rsync sobrescrevendo o arquivo de log (para mantê-lo em tamanho pequeno). Cuidado : o uso de -v em rsync pode levar a um arquivo de log enorme.

Toda duração do processo de rsync leva de ~ 16 a 30 minutos, dependendo da carga do servidor.

    

Answer 2

Uma abordagem seria usar Perdição para tratamento de conexões POP / IMAP e, em seguida, configurar o Postfix para rotear o SMTP para um servidor antigo ou novo, dependendo de onde a caixa de correio do usuário está localizada. Dessa forma, você pode migrar seu servidor ao vivo uma caixa de correio de cada vez, sem qualquer tempo de inatividade.

Claro que você pode configurar uma pausa de manutenção programada e, em seguida, apenas rsync os arquivos. Copiar 15 milhões de arquivos vai demorar um pouco, no entanto. Dependendo do seu servidor e principalmente do sistema de E / S, pode ser útil executar vários processos de rsync em paralelo; um copiando arquivos / dirs começando com [a-e], o segundo com [f-j], terceiro com [k-p] e assim por diante.

Mas, tendo feito algo parecido duas vezes, eu recomendaria a abordagem da Perdição. Após a configuração inicial, a dor da migração é eliminada.

EDIT: Você pediu mais informações sobre a configuração da Perdition, você conseguiu.

Você precisa ter um local central onde tenha as informações da sua conta de usuário armazenadas. Isso pode ser MySQL, PostgreSQL, OpenLDAP ou qualquer outra coisa. Eu sempre usei o OpenLDAP com grande sucesso. De qualquer forma, você precisa ter uma tabela de banco de dados / esquema LDAP que contenha o nome de usuário e o nome do servidor onde a caixa de correio do usuário está localizada. Existem utilitários de migração Perdition disponíveis que ajudarão você na configuração inicial.

Em seguida, Perdition recebe as conexões POP / IMAP, pesquisa a localização do usuário do LDAP ou qualquer outra, e faz uma proxy transparente do tráfego entre o cliente de e-mail do usuário e o servidor real. O postfix também pode procurar este local de servidor real do LDAP / SQL e enviar o email para lá.

Aqui está um PDF sobre Perdition + configuração LDAP e aqui é o manual LDAP do Postfix .

Em seguida, basta criar um script de migração que copie as caixas de correio uma a uma pelo IMAP com imapsync ou utilitário semelhante, e após cada migração bem-sucedida da caixa de correio, atualize o OpenLDAP ou qualquer local central sobre a localização da caixa de correio do usuário. >

EDIT # 2: O imapsync de que estou falando é software livre e disponível na maioria Distribuições Linux de seus repositórios de pacotes. Você me pediu para elaborar mais sobre a abordagem rsync ; Não importa se você escolher imapsync ou rsync, os princípios básicos são os mesmos. Você acabou de criar um script com bash, Perl ou algum outro idioma com o qual se sinta confortável. Aqui está um pseudo código.

@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);
}

    

Answer 3

Você pode procurar hospedar o servidor em um sistema de arquivos distribuído. Você pode usar o DRBD para executar uma replicação do sistema de arquivos. Seu servidor atual pode servidor primário com um secundário (que você já tem como um novo servidor). Se o primário falhar, o secundário se tornará o principal. Você pode implementar o DRBD no servidor atual e a sincronização inicial ocorrerá de forma transparente (sem tempo de inatividade) no segundo plano para o secundário (novo servidor) sem que você perceba. Não há arquivos para copiar manualmente por você. - link

    

Answer 4

1. Encaminhe o e-mail para o novo servidor alterando o (s) registro (s) MX do (s) domínio (s) em questão para apontar para o novo servidor de e-mail.

2. Mova todo o conteúdo da caixa de correio do usuário e direcione todos os clientes de e-mail para o novo servidor.

3. Transfira qualquer email restante no servidor antigo para o novo servidor da maneira que desejar.