Copiar uma árvore de diretórios grande localmente? cp ou rsync?

219

Eu tenho que copiar uma árvore de diretórios grande, cerca de 1,8 TB. Tudo é local. Fora do hábito eu usaria rsync , no entanto, eu me pergunto se há muito sentido, e se eu deveria usar cp .

Estou preocupado com permissões e uid / gid, já que eles precisam ser preservados na cópia (eu sei que o rsync faz isso). Bem como coisas como links simbólicos.

O destino está vazio, então não preciso me preocupar em atualizar condicionalmente alguns arquivos. É todo disco local, então não tenho que me preocupar com ssh ou rede.

A razão pela qual eu teria sido tentado a sair do rsync, é porque o rsync pode fazer mais do que eu preciso. arquivos checksums rsync. Eu não preciso disso, e estou preocupado que isso possa levar mais tempo do que o cp.

Então, o que você acha, rsync ou cp ?

    
por Rory 20.07.2009 / 16:36

14 respostas

189

Eu usaria o rsync porque significa que, se ele for interrompido por algum motivo, você poderá reiniciá-lo facilmente com um custo muito pequeno. E, sendo rsync, pode até reiniciar parte do caminho através de um arquivo grande. Como outros mencionam, ele pode excluir arquivos facilmente. A maneira mais simples de preservar a maioria das coisas é usar o -a flag - ‘archive’. Então:

rsync -a source dest

Embora UID / GID e links simbólicos sejam preservados por -a (consulte -lpgo ), sua pergunta implica que você pode querer uma cópia completa das informações do sistema de arquivos; e -a não inclui links físicos, atributos estendidos ou ACLs (no Linux) ou os forks de recursos nem acima (no OS X.) Assim, para uma cópia robusta de um sistema de arquivos, você precisará incluir esses sinalizadores:

rsync -aHAX source dest # Linux
rsync -aHE source dest  # OS X

O cp padrão será iniciado novamente, embora o sinalizador -u "copie somente quando o arquivo SOURCE for mais recente que o arquivo de destino ou quando o arquivo de destino estiver ausente" . E o sinalizador -a (archive) será recursivo, e não recopiar arquivos se você precisar reiniciar e preservar as permissões. Então:

cp -au source dest
    
por 20.07.2009 / 16:40
92

Ao copiar para o sistema de arquivos local, eu sempre uso as seguintes opções de rsync:

# rsync -avhW --no-compress --progress /src/ /dst/

Aqui está o meu raciocínio:

-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, so I can see what's happening (optional)
-h is for human-readable, so the transfer rate and file sizes are easier to read (optional)
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--no-compress as there's no lack of bandwidth between local devices
--progress so I can see the progress of large files (optional)

Eu vi transferências 17% mais rápidas usando as configurações de rsync acima sobre o seguinte comando tar, como sugerido por outra resposta:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)
    
por 07.05.2013 / 21:09
78

Quando tenho que copiar uma grande quantidade de dados, geralmente uso uma combinação de tar e rsync. A primeira passagem é tar, algo assim:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

Normalmente, com uma grande quantidade de arquivos, haverá alguns que o tar não pode manipular por qualquer motivo. Ou talvez o processo seja interrompido ou, se for uma migração do sistema de arquivos, talvez você queira fazer a cópia inicial antes da etapa de migração real. De qualquer forma, após a cópia inicial, eu faço um passo rsync para sincronizar tudo:

# cd /dst; rsync -avPHSx --delete /src/ .

Observe que a barra no final em /src/ é importante.

    
por 20.07.2009 / 17:15
13

rsync

Aqui está o rsync que eu uso, eu prefiro o cp para comandos simples, não isso.

$ rsync -ahSD --ignore-errors --force --delete --stats $SRC/ $DIR/

cpio

Aqui está uma maneira ainda mais segura, o cpio. É tão rápido quanto o alcatrão, talvez um pouco mais rápido.

$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null

tar

Isso também é bom e continua nas falhas de leitura.

$ tar --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -

Note que todos são apenas para cópias locais.

    
por 26.02.2012 / 18:06
6

Tudo o que você preferir. Apenas não esqueça a opção -a quando você decidir usar cp .

Se você realmente precisa de uma resposta: eu usaria o rsync porque é muito mais flexível. Precisa desligar antes que a cópia seja concluída? Apenas ctrl-c e continue assim que voltar. Precisa excluir alguns arquivos? Apenas use --exclude-from . Precisa alterar a propriedade ou as permissões? O rsync fará isso por você.

    
por 20.07.2009 / 16:40
6

rsync -aPhW --protocol=28 ajuda a acelerar essas cópias grandes com o RSYNC. Eu sempre rsync porque o pensamento de estar no meio 90GiB e quebrando me assusta longe de CP

    
por 20.07.2009 / 18:24
6

O comando rsync sempre calcula as somas de verificação em cada byte que ele transfere.

A opção de linha de comando --checksum refere-se apenas a se as somas de verificação dos arquivos são usadas para determinar quais arquivos transferir ou não, ou seja:

-c, --checksum skip based on checksum, not mod-time & size"

A manpage também diz isto:

Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking its whole-file checksum, but that automatic after-the-transfer verification has nothing to do with this option’s before-the-transfer "Does this file need to be updated?" check.

Portanto, rsync também, sempre, calcula uma soma de verificação de todo o arquivo no lado de recebimento, mesmo quando a opção -c/ --checksum está "desativada".

    
por 28.11.2012 / 02:20
5

O rsync é ótimo, mas tem problemas com árvores de diretórios muito grandes porque armazena as árvores na memória. Eu estava apenas olhando para ver se eles resolveriam esse problema quando eu encontrasse esse tópico.

Eu também encontrei:

link

Você também pode dividir manualmente a árvore e executar vários rsyncs.

    
por 20.07.2009 / 18:14
5

Esse tópico foi muito útil e, como havia tantas opções para alcançar o resultado, decidi comparar alguns deles. Acredito que meus resultados podem ser úteis para os outros terem uma noção do que funcionou mais rápido.

Para mover 532Gb de dados distribuídos entre 1.753.200 arquivos , tivemos esses momentos:

  • rsync demorou 232 minutos
  • tar demorou 206 minutos
  • cpio demorou 225 minutos
  • rsync + parallel demorou 209 minutos

No meu caso, preferi usar rsync + parallel . Espero que esta informação ajude mais pessoas a decidir entre estas alternativas.

O benchmark completo está publicado aqui

    
por 11.05.2017 / 21:14
2

Ao fazer local uma cópia do diretório local, minha experiência é que "cp -van src dest" é 20% mais rápido que o rsync. Em termos de capacidade de reinicialização, é o que "-n" faz. Você só precisa rm o arquivo parcialmente copiado. Não é doloroso, a menos que seja um ISO ou algo assim.

    
por 07.09.2011 / 09:26
2

ARJ É TÃO VELHA ESCOLA !! Eu realmente duvido que o ARJ e / ou o rsync ofereçam desempenho.

Definitivamente, o que sempre faço é usar o cpio:

find . -print | cpio -pdm /target/folder

Isso é quase rápido do que CP, definitivamente mais rápido que o tar e sem canalizar nada.

    
por 09.09.2012 / 06:09
0

Ambos funcionarão bem.

    
por 20.07.2009 / 16:41
0

tar também fará o trabalho, mas não será interrompido como o rsync.

    
por 20.07.2009 / 17:09
0

E se você usar o ARJ?

arj a -jm -m1 -r -je filepack /source

em que -jm -m1 são níveis de compactação e -je o torna um executável. Agora você tem uma série de arquivos encapsulados.

Em seguida, para extração para o mapa de destino

filepack -y  

onde o mapa de origem será feito (onde -y é sempre aceito, sobrescrever, pular etc)

Pode-se então scp fazer o ftp do arquivo para a área alvo e executá-lo, se isso for possível.

    
por 18.05.2011 / 08:20