Seu esquema básico é mais ou menos correto.
O instalador do squeeze fará um software RAID muito bem. Um ponto de diferença é que o squeeze usa o grub2 por padrão; lenny usou legado de grub (0,9 eu acho). Isso faz com que algumas administrações do grub sejam um pouco diferentes, particularmente em torno de garantir que o grub inicialize de ambos os discos em caso de falha. Você sempre pode reverter para o legado, que foi o que acabei fazendo na última vez em que fui confrontado com esse problema. Ele pagaria para testar o que você está fazendo, para ter certeza de que você pode reinicializar se o disco falhar.
Para copiar dados, use o rsync com certeza. Eu me certificaria de que as contas corretas estão configuradas primeiro, com os mesmos uids / gids e, em seguida, rsync, mas você sempre pode corrigir isso depois. rsync -avPHAX deve obter tudo (-a obtém a maioria das coisas, exceto para -H [ard links] -A [CLs] e -X [atributos tendidos], então isso é útil.
Dado que você está fazendo uma atualização efetiva ao mesmo tempo, prepare-se para que os serviços sejam interrompidos de maneira sutil. Configurações mudará um pouco. Tendo feito algo parecido recentemente, acho que prefiro fazer uma migração do tipo "gostei & gt ;, depois atualizar o host final algum tempo após o fato, já que migrar tudo e gerenciar upgrades ao mesmo tempo tornou uma tarefa gigantesca.
Atualizado para seus pontos de dor adicionais:
Para o DNS, movo todo o DNS hospedagem para a nova máquina em uma única etapa. Deixe os registros como estão para começar, mas defina a atualização imediatamente (10 minutos). Isso permite que você mova os registros DNS para a nova máquina à medida que você completa a movimentação de cada domínio. Mover seu DNS pode exigir a atualização dos registros whois para qualquer domínio que você hospede, portanto, tenha isso em mente. Defina a atualização para todos os domínios agora, de fato, antes de começar qualquer outra coisa - nada pior do que ter um resultado mal armazenado em cache causando problemas.
Com relação à perda de e-mail: ao mover e-mails para o novo servidor, verifique se os registros DNS foram atualizados para apontar o MX principal para o novo servidor e se o servidor antigo ainda está configurado para permitir a retransmissão de seus domínios . Desde que seus servidores antigos e novos tenham visões atualizadas do DNS, seu serviço de e-mail no servidor antigo funcionará e não será mais o MX principal e encaminhará qualquer e-mail para o novo primário. O Mail também lidará com pequenos atrasos na entrega - assim você pode simplesmente desligar ou bloquear todo o acesso a email para ambas as máquinas, mover tudo de uma vez, testá-lo na nova máquina, mover registros MX e abrir mensagens na nova máquina . O SMTP foi projetado para lidar com interrupções e qualquer indisponibilidade razoavelmente curta (menos de 4 horas, eu acho) nem gerará notificações de erro temporárias.
Atualizado para adicionar:
Outra possibilidade é criar uma VM em seu novo servidor e rsync todo o servidor antigo para a imagem de disco dessa nova VM. Você pode então acionar a VM e atualizar os endereços IP, etc, e ter uma réplica totalmente funcional do servidor original dentro desta VM. Potencialmente, muito menos esforço, mas se você não estiver familiarizado com pilhas de VMs como KVM ou Virtualbox, talvez não valha a pena.