Estou tentando sincronizar dois volumes montados (1 TB) em uma única máquina com rsync. Talvez isso possa não ser a melhor abordagem, mas estou tentando descobrir o que poderia estar errado, já que a cada lançamento, o rsync copia tudo de novo, não apenas as diferenças.
O comando exato é:
find . -type f|parallel -v -j 24 rsync -ar --progress /dbdata/{} /dbdata2/{}
Como estou tentando alcançar a velocidade máxima de cópia via paralelização do processo.
PS: dirs / pastas criadas anteriormente por find | mkdir
Debian Jessie
O que mais devo fornecer para você? Alguma idéia?
Por padrão, o rsync não faz cálculos delta em cópias locais, somente pela rede. Você pode adicionar -no-W ou --no-whole-file para substituir isso. --stats mostrará mais informações sobre o que aconteceu. Definir um valor --block-size= fixo permite que você escolha quais blocos de tamanho devem ser considerados.
A paralelização não é uma bala mágica que torna as coisas mais rápidas. A paralelização requer tarefas independentes , ou pelo menos vagamente acopladas. A paralelização só ajuda se as tarefas não competirem (muito) por recursos.
Como o rsync é limitado por E / S e não está ligado à CPU, não há muito a ganhar executando várias instâncias em paralelo. Se o processo de cópia é limitado pela largura de banda, então não há como ganhar nada paralelizando, você só pode perder devido à sobrecarga de paralelização. (A paralelização sempre tem uma sobrecarga, pois o sistema está alternando entre as tarefas. Só vale a pena se os ganhos compensarem o custo.)
É possível obter uma vantagem da paralelização se você não puder saturar a largura de banda disponível devido à latência, ou seja, se o rsync gastar uma fração significativa de seu tempo aguardando a conclusão de uma leitura. No entanto, é extremamente improvável que a latência seja tão alta que você obtenha algum benefício de 24 instâncias paralelas. Com a maioria dos hardwares de disco, os acessos paralelos têm um alto custo devido à debulha . Se você tem hardware capaz de paralelizar solicitações, pode haver algum ganho, mas duvido que qualquer hardware lide com 24 solicitações paralelas. Tente com duas instâncias, mas meça, não especule.
Em relação a cópias delta, isso é apenas uma otimização quando o gargalo é a largura de banda entre a origem e o destino. Cópias delta fazem sentido quando há um rsync local que pode calcular somas de verificação muito rápido, um rsync remoto que pode calcular checksums muito rápido e uma rede no meio que leva muito mais tempo para transmitir os dados do que o rsync leva para calcular checksums. Com arquivos locais, o rsync precisa ler a origem e o destino para calcular as somas de verificação. Se as gravações forem mais ou menos tão rápidas quanto as leituras, as cópias delta só poderão ser prejudicadas, já que as leituras, na melhor das hipóteses, impedirão uma quantidade igual de gravações. Se as gravações forem significativamente mais lentas que as leituras, as cópias em delta podem ajudar, mas isso seria algo incomum. Você pode passar --no-whole-file para forçar transferências delta, mas não se surpreenda se isso tornar a cópia mais lenta. Mais uma vez, perfil, não especule.
Tags rsync debian gnu-parallel