Depende muito do trabalho em questão.
Por que você precisa de espelhamento de arquivos. Deseja atualizar algo como um site ou repositório de conteúdo em que normalmente não há problema em atualizar periodicamente. Ou você precisa de sincronização de dados em tempo real?
Para o espelhamento assíncrono periódico de arquivos, geralmente é suficiente ter uma área de armazenamento temporário na qual você carrega todos os seus dados. E de onde você o distribui para os servidores. No seu caso - com dois servidores - você pode criar algum compartilhamento de arquivos temporário no srv1 para onde transfere os dados (via FTP, NFS, DAV, SFTP etc.) e depois fazer um cronograma sincronizar os arquivos nos diretórios "ao vivo" de srv1 e srv2. A maneira mais fácil de usar o rsync nesse caso é gerar um par de chaves ssh que você usará para transferências de dados e que está autorizado em todos os servidores em seu cluster.
Exemplo:
srv1:/data/staging/ <= is where you upload your data
srv1:/data/production/ <= is where your servers get their production data from
srv2:/data/production/
srv1$ cat /etc/cron.d/syncdata.cron
=====
*/5 * * * * syncuser rsync -a --delete /data/staging/ /data/production/
*/5 * * * * syncuser rsync -az --delete -e ssh /data/staging/ srv2:/data/production/
=====
Isso deve lhe dar uma idéia básica. É claro que você deseja agrupar as chamadas rsync em alguns scripts e implementar um bloqueio adequado para que não seja executado duas vezes, caso a sincronização demore mais de 5 minutos, etc. Além disso, não é necessário dizer que uma área de teste não é obrigatória. Você também pode sincronizar srv1: production com srv2: production diretamente. Apenas o srv2 pode mostrar dados até 5 minutos mais antigos que o srv1. O que pode ser um problema, dependendo de como você equilibra os dois.
Outra maneira de distribuir arquivos de forma assíncrona é empacotá-los como rpm ou, no seu caso, arquivos deb. Coloque-os em um repositório central e instale-os / atualize através de algo como cfengine, monkey ou alguma solução baseada em barramento de mensagem diy. Isso tem o bom efeito colateral da versão dos dados implantados, mas é adequado apenas para quantidades menores de dados que você produz e implanta (como versões do seu próprio software). Você não gostaria de distribuir TBs de dados com isso e também não é adequado para espelhar conteúdo que muda com alta frequência, como a cada dois minutos.
Se você precisar replicar dados quase em tempo real, mas não necessariamente síncrono, em vez de chamar um cron de vez em quando, poderá usar algum método baseado em inotify, como o incron já mencionado, para chamar seus scripts de sincronização. Outra possibilidade é usar o Gamin (que também usa inotify, se presente no Kernel) e escrever seu próprio pequeno daemon de sincronização. Por último, mas não menos importante, se todos os arquivos forem carregados em um servidor via, por exemplo, SFTP, você poderá verificar se o seu servidor SFTP permite definir ganchos que são chamados após determinados eventos, como o upload de arquivos. Dessa forma, você pode dizer ao seu servidor para ativar seu script de sincronização sempre que novos dados forem carregados.
Se você precisar de espelhamento síncrono de dados em tempo real, um sistema de arquivos em cluster pode estar em ordem. DRDB já foi nomeado. É muito bom para replicação no nível do bloco e frequentemente usado para configurações MySQL disponíveis com alta disponibilidade. Você também pode querer dar uma olhada no GFS2, OCFS2, Luster e GlusterFS. Embora o Luster e o GlusterFS não sejam realmente adequados para uma configuração de dois servidores.