Depende muito do trabalho em questão.
Por que você precisa do espelhamento de arquivos? Você quer atualizar algo como um site ou repositório de conteúdo, onde normalmente é recomendável 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 Preparação para a qual você carregou todos os seus dados. E de onde você distribui para os servidores. No seu caso - com dois servidores - você pode criar alguns arquivos compartilhados em srv1 para onde você transfere os dados (via FTP, NFS, DAV, SFTP, etc.) e então ter um cronjob rsync os arquivos para os diretórios "live" do 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 do 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 ideia básica. Claro que você gostaria de quebrar as chamadas rsync em alguns scripts e implementar um bloqueio adequado para que ele não seja executado duas vezes caso a sincronização demore mais de 5 minutos, etc. Além disso, não é preciso dizer que uma área de teste não é obrigatória. Você também pode sincronizar srv1: production para srv2: production diretamente. Apenas que srv2 pode mostrar dados até 5min mais antigos que o de 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. Colocá-los em um repositório central e tê-los instalar / atualizar através de algo como cfengine, monkey ou alguma solução baseada em barramento de mensagens diy. Isso tem o efeito colateral agradável de versionamento de dados implantados, mas é adequado apenas para quantidades menores de dados que você produz e implanta sozinho (como versões de seu próprio software). Você não iria querer distribuir TBs de dados com isso e também não é adequado para espelhar conteúdo que muda com uma 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, pode usar algum método baseado em inotify, como o já mencionado, para chamar seus scripts de sincronização. Outra possibilidade é usar o Gamin (que também usa inotify se estiver presente no Kernel) e escrever seu próprio daemon de sincronização. Por último, mas não menos importante, se todos os arquivos são enviados para um servidor, por exemplo, SFTP você pode verificar se seu servidor SFTP permite que você defina ganchos que são chamados após determinados eventos, como upload de arquivo. Dessa forma, você poderia dizer ao seu servidor para acionar seu script de sincronização sempre que novos dados forem enviados.
Se você precisar de espelhamento síncrono de dados em tempo real, um sistema de arquivos em cluster pode estar em ordem. O DRDB já foi nomeado. É muito bom para replicação no nível de bloco e geralmente usado para configurações de alta disponibilidade do MySQL. 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.