Há três componentes para o que você está perguntando aqui: replicação do banco de dados, redundância de e-mail e acesso do usuário.
A replicação de banco de dados é fácil e está bem coberta pela documentação do MySQL .
A replicação de email é geralmente tão fácil quanto garantir que seus registros MX estejam definidos corretamente. Se o dubdeuce não for o MX principal, ele encaminhará o e-mail para o MX principal quando o principal estiver disponível novamente.
No entanto, você não declarou isso explicitamente, mas a inclusão do roundcube implica que você deseja que o segundo sistema esteja totalmente operacional até o MUA - você quer que os usuários possam ler e-mails. Se não for esse o caso - você está feliz por o roundcube estar offline até que o dubone volte - então os componentes acima farão o trabalho para você.
Mais uma vez: se tudo o que você quer é um sistema simples que armazene e envie e-mails até que o primário volte, tudo que você precisa é de replicação de banco de dados para mysql e fazer uso de um MX secundário. Esse sistema deve estar ativo o tempo todo, não apenas em necessidade.
Se você quer um sistema totalmente redundante, em que o roundcube está sempre disponível, então o que você quer é um mailpool compartilhado entre os dois sistemas. Não há uma maneira real de configurar o dubduece como um MX principal e dar aos usuários a capacidade de ler e-mails a partir dele, e enviá-lo de maneira sensata para o dubone.
Então, você precisa de um mailpool compartilhado. Esse pode ser um terceiro sistema atuando como servidor de arquivos, servindo o conjunto de emails para os dois hosts principais, no entanto, há uma recomendação antiga contra o uso do NFS para um conjunto de emails, devido a problemas de bloqueio.
Poderia ser feito usando DRBD entre os dois nós, no modo ativo / backup - quando um nó falha, você usa um heartbeat para mudar o outro nó para ativo. Quando o primeiro nó voltar a ficar on-line, você precisará de um processo de pulsação para alternar tudo também. Você ainda precisará descobrir como replicar seu banco de dados - você pode querer uma configuração multimaster agora.
Finalmente, você poderia fazer a mesma coisa com o DRBD, mas usar um sistema de arquivos que reconhece o cluster e ter ambos os nós ativos o tempo todo. Isso é um pouco mais complicado. Você poderia DRBD todo o sistema de email entre os nós também. E há muitas maneiras de ampliar - soluções mais avançadas envolvem uma SAN e uma pilha de VMs, como Citrix Xenserver ou VMware.
Para meu dinheiro, eu ficaria com um mailpool DRBD ativo / passivo, ou mysql multimaster, ou mysql suportado ativo / passivo DRBD, e usaria heartbeat para mover habilitar serviços ativos em failover. Uma alternativa para isso é colocar todo o seu servidor de email em uma VM usando Xen ou KVM ou o que você quiser, fazendo backup da VM em um sistema DRBD e fazendo com que o heartbeat faça failover no DRBD e inicie a VM no segundo nó no caso de uma falha . Neste exemplo, você só tem um servidor de email "apenas", ele simplesmente flutua entre seus nós. A desvantagem é que você tem que esperar que ele seja inicializado no failover, o que pode demorar um pouco.
Como observação, qualquer que seja o modo como você faz as coisas, verifique se a varredura de spam / vírus / malware / etc está configurada de maneira idêntica nos dois sistemas.