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

Eu tenho que copiar uma grande árvore de diretórios, cerca de 1,8 TB. É tudo local. Por hábito, eu usaria rsync, no entanto, me pergunto se há muito sentido e se devo preferir cp.

Estou preocupado com permissões e uid / gid, pois elas precisam ser preservadas 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 o disco local, então não preciso me preocupar com ssh ou rede.

A razão pela qual eu ficaria tentado a sair do rsync é porque o rsync pode fazer mais do que eu preciso. arquivos de somas de verificação rsync. Não preciso disso e estou preocupado que isso possa levar mais tempo que o cp.

Então, o que você acha, rsyncou cp?

Eu usaria o rsync, pois significa que, se for interrompido por qualquer motivo, você poderá reiniciá-lo facilmente com muito pouco custo. E sendo o rsync, pode até reiniciar parcialmente 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 a -abandeira - 'arquivo'. Assim:

rsync -a source dest

Embora o UID / GID e os 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 -anão inclui hard-links, atributos estendidos ou ACLs (no Linux) ou os acima nem bifurcações de recursos (no OS X.) Assim, por uma cópia robusta de um sistema de arquivos, você precisa incluir essas bandeiras:

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

O cp padrão será iniciado novamente, embora o -usinalizador "copie somente quando o arquivo SOURCE for mais novo que o arquivo de destino ou quando o arquivo de destino estiver ausente" . E o -asinalizador (arquivo morto) será recursivo, não copia novamente os arquivos se você precisar reiniciar e preservar as permissões. Assim:

cp -au source dest

Ao copiar para o sistema de arquivos local, 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)

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

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

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

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

Geralmente, 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, você poderá fazer a cópia inicial antes da etapa real da migração. De qualquer forma, após a cópia inicial, eu faço uma etapa rsync para sincronizar tudo:

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

Observe que a barra final /src/é importante.

rsync

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

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

cpio

Aqui está uma maneira ainda mais segura, 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

alcatrão

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

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

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

O que você preferir. Só não esqueça a -aopção quando você decidir usar cp.

Se você realmente precisa de uma resposta: eu usaria o rsync porque é muito mais flexível. Precisa desligar antes de concluir a cópia? Basta pressionar Ctrl-C e continuar assim que estiver de costas. Precisa excluir alguns arquivos? Apenas use --exclude-from. Precisa alterar a propriedade ou as permissões? O rsync fará isso por você.

O rsynccomando sempre calcula somas de verificação em cada byte transferido.

A opção de linha de comando --checksumrefere-se apenas ao uso de somas de verificação de arquivos para determinar quais arquivos transferir ou não, ou seja:

-c, --checksum pular com base na soma de verificação, não no tempo e tamanho da modificação "

A página de manual também diz o seguinte:

Observe que o rsync sempre verifica se cada arquivo transferido foi reconstruído corretamente no lado receptor, verificando a soma de verificação de todo o arquivo, mas essa verificação automática após a transferência não tem nada a ver com a opção antes da transferência "Este arquivo precisa ser atualizado?" Verifica.

Assim rsynctambém, sempre, calcula uma soma de verificação de todo o arquivo no lado de recebimento, mesmo quando a -c/ --checksumopção está "desativada".

rsync -aPhW --protocol=28ajuda a acelerar essas cópias grandes com o RSYNC. Eu sempre vou rsync porque o pensamento de estar no meio do 90GiB e quebrar me afasta da CP

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

Eu também encontrei:

http://matthew.mceachen.us/geek/gigasync/

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

Esse tópico foi muito útil e, como havia muitas opções para alcançar o resultado, decidi fazer o benchmark de algumas delas. Acredito que meus resultados podem ser úteis para que outras pessoas tenham uma noção do que funcionou mais rapidamente.

Para mover 532Gb de dados distribuídos entre 1.753.200 arquivos , tivemos o seguinte:

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

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

A referência completa é publicada aqui

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

ARJ É UMA ESCOLA TÃO VELHA !! Eu realmente duvido que o ARJ e / ou o rsync dêem desempenho.

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

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

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

Você definitivamente quer experimentar o rclone . Essa coisa é louca rápido:

sudo rclone sync /usr /home/fred/temp -P -L --transfers 64

Transferred:       17.929G / 17.929 GBytes, 100%, 165.692 MBytes/s, ETA 0s
Errors:                75 (retrying may help)
Checks:            691078 / 691078, 100%
Transferred:       345539 / 345539, 100%
Elapsed time:     1m50.8s

Esta é uma cópia local de e para um SSD LITEONIT LCS-256 (256GB).

Você pode adicionar --ignore-checksumna primeira execução para torná-la ainda mais rápida.

Ambos irão funcionar muito bem.

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

E se você usar ARJ?

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

onde -jm -m1estão os níveis de compactação e o -jetorna um executável. Agora você tem uma lista de arquivos encapsulada.

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

filepack -y  

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

Pode-se então scp ftp o pacote de arquivos para a área de destino e executá-lo, se isso for possível.

Existem algumas acelerações que podem ser aplicadas a rsync:

Evitar

• -z/ --compress: a compactação carregará apenas a CPU, pois a transferência não está na rede, mas na RAM.
• --append-verify: retoma uma transferência interrompida. Parece uma boa idéia, mas tem o caso de falha perigosa: qualquer arquivo de destino do mesmo tamanho (ou maior) que a fonte será IGNORADO. Além disso, verifica o arquivo inteiro no final, o que significa que não há aceleração significativa --no-whole-fileao adicionar um caso de falha perigoso.

Usar

• -S/ --sparse: transforma sequências de nulos em blocos esparsos
• --partialou -Pqual é --partial --progress: salve os arquivos parcialmente transferidos para futura retomada. Nota: os arquivos não terão um nome temporário, portanto, garanta que nada mais espere usar o destino até que toda a cópia seja concluída.
• --no-whole-filepara que qualquer coisa que precise ser reenviada use transferência delta. Ler metade de um arquivo parcialmente transferido geralmente é muito mais rápido do que escrevê-lo novamente.
• --inplace para evitar a cópia do arquivo (mas apenas se nada estiver lendo o destino até que toda a transferência seja concluída)