Temos dois grandes servidores de armazenamento (+100 TB), um roda em ZFS e outro XFS, pretendemos usar o XFS como nosso servidor de trabalho e usar o ZFS como servidor de backup (snapshots <3). Agora o problema é manter essas feras sincronizadas... (sync as in daily synced)
A opção mais fácil é usar o rsync, mas, infelizmente, a estrutura de diretórios é profunda e cheia de links físicos em todo o lugar. Portanto, isso significa que precisaríamos fazer uma varredura "global" que levaria séculos... Além disso, a maioria dos dados é criada e nunca modificada. Portanto, o rsync pode não ser o caminho a percorrer.
Pesquisei o inotify , que parece relativamente barato e, como só queremos sincronizar diariamente, seria capaz de descarregar em um bom momento ... infelizmente, se olharmos apenas para os arquivos criados, copiaríamos links físicos como dados que dobraria a quantidade de armazenamento usada em nosso backup ... (basicamente não há como fazer a verificação -H do rsync)
A única opção que eu poderia pensar seria reorganizar nosso armazenamento para usar um diretório baseado em data, infelizmente mover tantos dados não é algo que preferimos ...
Existem outras opções?
Para referência :
- O servidor com XFS possui um controlador RAID (sem opção JBOD) e discos SATA (WD RE). RAM de 32 GB
- O servidor com ZFS possui um controlador HBA e discos SAS. RAM de 126 GB
Quando faço referência ao ZFS como sendo lento, vejo 'ls' levando segundos ...
Você realmente deve usar o ZFS em ambos os lados, juntamente com uma rotina de instantâneo/replicação em nível de bloco como Sanoid .
Sem isso, você fica preso a operações baseadas em arquivos e ao trabalho de verificação de arquivos rsync.
Quão rápido é rápido o suficiente"?
Você está fazendo isso uma vez por dia, então eu suspeito que, se levar de 2 a 3 horas, isso é suficiente.
Nesse caso, "rsync -avP" deve ser tudo o que você precisa. As versões mais recentes lidam com diretórios grandes, hierarquias profundas e não requerem tanta RAM quanto as versões mais antigas.
Se nenhum arquivo for alterado, "rsync -a" será tão rápido quanto "ls -lR". Você não pode ficar mais rápido do que "ls -lR" porque ele faz um lstat () de cada arquivo no sistema.
Benchmark "ls -lR" e "rsync -a". Se eles forem mais lentos do que você pensa, consulte https://serverfault.com/a/746868/6472 para obter orientação.
Se você precisar de algo mais rápido que o benchmark "ls -lR", terá que escrever algo que use "inotify" ou usar algum tipo de sistema baseado em blocos. Em particular, usar o ZFS em ambos os sistemas permitiria que você usasse o sistema de exportação/importação de instantâneo que o ZFS incorporou.
Eu adotaria uma estratégia de 2 partes... e no final vou sugerir uma 3ª parte que é opcional.
Parte 1: Use o inotify: Escreva um programa que use o inotify para registrar quais arquivos foram criados, excluídos e modificados. Escreva outro programa que leia o log, remova todas as duplicatas e faça backup desses arquivos (e exclua os arquivos excluídos). Isso não será fácil. A programação do inotify é complexa. O log não pode ser um arquivo de texto simples, pois os nomes dos arquivos podem incluir novas linhas. Se o sistema travar enquanto o log está sendo gravado, você precisará lidar com nomes de arquivos parcialmente gravados.
Parte 2: rsync semanal apenas por precaução. A cada poucos dias, faça um "rsync -a --delete" para capturar todos os arquivos que foram perdidos. A solução da parte 1 é imperfeita. Se o seu programa não acompanhar o inotify, ele pode perder alguns arquivos. Se a máquina for reinicializada, o log de arquivos criados/excluídos/modificados pode perder os itens mais recentes. Bugs e outros problemas também podem resultar na perda de alguns arquivos.
Parte opcional 3: depois de executar isso por algumas semanas e resolver todos os bugs, você ainda descobrirá que o rsync ocasionalmente encontra arquivos que foram perdidos. Eu prometo a você que isso vai acontecer. inotify é "melhor esforço". Portanto, neste ponto, você perceberá que manter o código na Parte 1 e na Parte 2 é o dobro do trabalho que você esperava. Para resolver esse problema, jogue fora o código que você escreveu na Parte 1, porque o rsync é tudo o que você realmente precisava em primeiro lugar.