10K-100K의 파일을 가진 폴더를 원격 컴퓨터 (캠퍼스 내 동일한 네트워크 내)로 보내는 경우가 종종 있습니다.

믿을만한 이유가 있는지 궁금해서

 tar + rsync + untar

아니면 간단히

 tar (from src to dest) + untar

실제로보다 빠를 수 있습니다

rsync 

처음으로 파일 을 전송할 때 .

압축을 사용하고 사용하지 않는 두 가지 시나리오에서 위의 문제를 해결하는 답변에 관심이 있습니다.

최신 정보

방금 10,000 개의 작은 파일 (전체 크기 = 50MB)을 이동하는 실험을 수행했으며 직접 tar+rsync+untar실행 rsync하는 것 (압축하지 않은 것)보다 일관되게 빠릅니다 .

동일한 파일 세트를 rsync보내면 차이 만 보내므로 더 적합합니다. tar항상 모든 것을 전송하며 많은 데이터가 이미있을 때 리소스 낭비입니다. 이 tar + rsync + untar경우이 장점을 잃어 버리고 폴더를와 동기화 상태로 유지하는 이점도 rsync --delete있습니다.

처음으로 파일을 복사 할 경우, 먼저 packeting 후 전송, 다음 (AFAIK 풀고 것은 rsync때문에 파이프로 연결된 입력을하지 않음), 성가신 그냥 rsyncing 항상보다 더 나쁘다 rsync이상의 모든 작업을 수행 할 필요가 없습니다 tar어쨌든.

팁 : rsync 버전 3 이상은 증분 재귀를 수행하므로 모든 파일을 계산하기 직전에 거의 복사를 시작합니다.

Tip2 : rsyncover 를 사용하면 다음 ssh중 하나를 사용할 수도 있습니다tar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

아니면 그냥 scp

scp -Cr srcdir user@server:destdir

일반적으로 간단하게 유지하십시오.

최신 정보:

59M 데모 데이터를 만들었습니다

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

두 가지 방법을 사용하여 파일을 원격 서버 (동일한 LAN이 아닌)로 여러 번 테스트했습니다.

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

전송 된 ssh 트래픽 패킷과 별도의 로그를 유지하면서

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

이 경우 기본 mtu가 1500이고 파일 크기가 10k 인 경우 rsync + tar를 사용하면 네트워크 트래픽이 적을 때 이점이 없습니다. rsync + tar는 더 많은 트래픽을 생성하고 2-3 초 동안 느려졌으며 두 개의 가비지 파일을 정리해야했습니다.

동일한 LAN에있는 두 대의 컴퓨터에서 동일한 테스트를 수행했으며 rsync + tar는 훨씬 더 나은 시간과 훨씬 적은 네트워크 트래픽을 수행했습니다. 점보 프레임의 원인을 가정합니다.

아마도 rsync + tar는 훨씬 더 큰 데이터 세트에서 rsync보다 낫습니다. 그러나 솔직히 말해서 문제가 될만한 가치가 없다고 생각합니다. 포장 및 포장 풀기 위해 양쪽에 이중 공간이 필요하며 위에서 언급 한 다른 옵션이 몇 가지 있습니다.

rsync압축도합니다. -z깃발을 사용하십시오 . 를 초과하여 실행하는 경우 sshssh의 압축 모드를 사용할 수도 있습니다. 내 느낌은 반복되는 압축 수준이 유용하지 않다는 것입니다. 중요한 결과없이 사이클을 태울 것입니다. rsync압축 실험을 권합니다 . 꽤 효과적인 것 같습니다. 그리고 사용 tar또는 다른 사전 / 사후 압축 사용을 건너 뛰는 것이 좋습니다 .

나는 보통 rsync를로 사용합니다 rsync -abvz --partial....

오늘 홈 디렉토리를 NAS에 백업하고이 토론에 부딪 쳤습니다. 결과를 추가하겠다고 생각했습니다. 간단히 말해서, 네트워크를 통해 대상 파일 시스템으로 taring하는 것이 동일한 대상으로 rsyncing하는 것보다 내 환경에서 훨씬 빠릅니다.

환경 : SSD 하드 드라이브를 사용하는 소스 머신 i7 데스크탑. 대상 컴퓨터 Synology NAS DS413j (소스 컴퓨터에 대한 기가비트 LAN 연결).

관련된 키트의 정확한 사양은 당연히 성능에 영향을 미치며 각 끝의 네트워크 하드웨어 품질과 관련하여 정확한 설정에 대한 세부 정보를 모릅니다.

소스 파일은 1.2Gb의 매우 작은 파일을 포함하는 내 ~ / .cache 폴더입니다.

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

나는 작업을 설명하기 위해 1a와 1b를 완전히 별도의 단계로 유지했습니다. 실제 응용 분야에서는 Gilles가 ssh를 통해 수신기의 untarring 프로세스에 파이프 타르 출력을 파이프하는 것과 관련하여 위에서 게시 한 것을 권장합니다.

타이밍 :

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

rsync가 tar 작업과 비교했을 때 놀랍게도 성능이 저하되었음을 분명히 알 수 있습니다. 이는 아마도 위에서 언급 한 네트워크 성능 모두에 기인 할 수 있습니다.

홈 디렉토리 백업과 같은 대부분의 작은 파일을 백업하려는 사람은 tar 방식을 사용하는 것이 좋습니다. rsync는 매우 좋지 않은 선택입니다. 절차에 부정확 한 것으로 보이면이 게시물로 돌아갑니다.

새긴 ​​금

요청에 따라 rsync를 사용하여 tar 아카이브를 보내면 검증 계층을 프로세스에 추가하기 때문에 실제로 낭비 또는 자원이 될 수 있습니다. Rsync는 개별 파일을 확인하려는 경우 tar 파일의 정확성을 검사합니다. (송신 측에서 결함이있을 수있는 tar 파일은 수신 측에서 이미 동일한 효과를 나타냄을 아는 것은 도움이되지 않습니다). 아카이브를 보내는 경우 ssh / scp 만 있으면됩니다.

아카이브 전송을 선택해야하는 한 가지 이유는 선택한 tar가 액세스 제어 목록 또는 확장 속성 (Solaris) 또는 리소스 포크 (MacOS)에 자주 저장되는 기타 메타 데이터와 같은 파일 시스템 스페셜을 더 많이 보존 할 수 있기 때문입니다. ). 이러한 문제를 처리 할 때 대상 파일 시스템에 정보를 추적 할 수있는 기능을 제공하면 소스 파일 시스템의 파일과 관련된 모든 정보를 유지할 수있는 도구에 대한 주요 관심사가 있습니다.

속도가 주요 관심사 인 경우 파일 크기에 따라 크게 달라집니다. 일반적으로 다수의 작은 파일은 각각 개별 네트워크 패킷을 낭비하므로 tar 파일은 단일 네트워크 패킷의 데이터로드 내에 여러 파일을 포함하기 때문에 rsync 또는 scp에 비해 크게 확장되지 않습니다. 작은 파일은 개별적으로보다 전체적으로 더 잘 압축되기 때문에 tar 파일을 압축하면 더 좋습니다. 내가 아는 한, rsync와 scp는 초기 전송에서와 같이 전체 단일 파일을 보낼 때 각 파일이 전체 프로토콜 오버 헤드로 전체 데이터 프레임을 차지하고 체크 아웃에 더 많은 시간을 낭비하면서 최적화하지 못합니다. 그러나 Janecekrsync가 네트워크 트래픽을 최적화하지만 메모리에 거대한 데이터 구조를 구축하는 비용을 상세하게 설명한다는 것은 scp에만 해당됩니다. 효율적인 파일 전송, Janecek 2006 기사를 참조하십시오 . 따라서 그에 따르면 scp와 rsync가 작은 파일에서는 크기가 크게 조정되지 않지만 완전히 다른 이유는 여전히 사실입니다. 이번 주말에 소스를 파헤쳐 봐야 할 것 같아요.

실제적으로 관련성을 높이기 위해 대부분 큰 파일을 전송한다는 것을 알고 있다면 속도에 큰 차이가 없으며 rsync를 사용하면 중단되었을 때 남은 위치를 차지할 수 있다는 이점이 있습니다.

Postscriptum : 요즘 rdist 는 망각에 빠지는 것처럼 보이지만 rsync가 있기 전에는 매우 유능한 도구였으며 널리 사용되었습니다 (ssh를 통해 안전하게 사용하면 안전하지 않음). 변경된 내용 만 전송하도록 최적화하지 않았기 때문에 rsync만큼 성능이 좋지 않습니다. rsync와의 주요 차이점은 구성 방식과 파일 업데이트 규칙의 철자 방법에 있습니다.

작은 디렉토리 (사용 된 디스크 공간과 같이 작은 디렉토리)의 경우 동기화되는 파일의 파일 정보를 확인하는 오버 헤드에 따라 다릅니다. 한편으로, rsync수정되지 않은 파일을 전송하는 시간을 절약하는 한편, 실제로는 각 파일에 대한 정보를 전송해야합니다.

의 내부를 정확히 알지 못합니다 rsync. 파일 통계가 지연을 일으키는 지 여부는 rsync데이터 전송 방식에 따라 다릅니다. 파일 통계가 하나씩 전송되면 RTT가 tar + rsync + untar를 더 빠르게 만들 수 있습니다.

그러나 1 GiB의 데이터가 있다면 연결 속도가 빠르지 않으면 rsync가 훨씬 빠릅니다.

나는 전국에서 몇 테라 바이트의 데이터를 정확히 한 번 이동해야했습니다. 실험으로, 나는 이전의 두 사용하여 실행 rsync하고 ssh/tar그들이 비교 방식을 볼 수 있습니다.

결과 :

• rsync 초당 평균 2.76MB의 속도로 파일을 전송했습니다.
• ssh/tar 초당 평균 4.18MB의 속도로 파일을 전송했습니다.

세부 정보 : 내 데이터는 수백만 개의 .gz 압축 파일로 구성되며 평균 크기는 10MB이지만 일부는 기가 바이트 이상입니다. 디렉토리 구조가 있지만 파일 내부의 데이터 크기로 인해 드워프됩니다. 내가 할 일이 거의 없다면, 나는 단지 사용 rsync했을 것입니다.이 경우 ssh/tar에는 기능적인 해결책입니다.

내 직업은 rsync다음 으로 구성됩니다.

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

여기서 fileList.txt는 다른쪽에있는 파일의 상대 경로 이름 목록입니다. ( --compress시작한 후에는 압축 파일에 대해 생산적이지 않지만 다시 시작하지는 않습니다.)

나는 ssh와 tar로 다른 것을 시작했다.

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

당신은 이것이 모든 것을 복사하는 것을 관찰 할 것입니다. 죄송합니다. 이것은 사과와 사과의 100 % 비교가 아닙니다.

내부 회사 네트워크를 사용하는 동안 데이터 소스 컴퓨터에 접속하려면 중개자를 거쳐야한다고 덧붙여 야합니다. 대상 컴퓨터에서 중개자까지의 핑 시간은 21ms이고 중개자에서 데이터 소스까지의 핑 시간은 26ms입니다. 두 전송 모두 동일했습니다.

중개자를 통한 SSL 연결은 다음 ~/.ssh/config항목을 통해 수행됩니다 .

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

이것을 시간 :

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"