차이점만 전송하므로 동일한 파일 세트를 보낼 때 rsync더 적합합니다 . tar모든 것이 항상 전송되므로 이미 많은 데이터가 있으면 리소스가 낭비됩니다. 이 경우 tar + rsync + untar폴더를 rsync --delete.

파일을 처음 복사하는 경우 먼저 압축한 다음 보내고 압축을 풀면(AFAIK 는 파이프 입력을 허용하지 않음) 어쨌든 작업을 수행할 필요가 없기 rsync때문에 번거롭고 항상 rsync보다 나쁩니다 .rsynctar

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

rsync팁 2: over 를 사용하는 경우 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초 더 느리며, 정리해야 하는 정크 파일 2개를 남깁니다.

동일한 LAN에 있는 두 시스템에서 동일한 테스트를 수행했으며 rsync+tar는 훨씬 적은 네트워크 트래픽으로 훨씬 더 나은 성능을 발휘했습니다. 점보 프레임인 것 같아요.

더 큰 데이터 세트에서는 rsync+tar가 rsync보다 나을 수도 있습니다. 하지만 솔직히 저는 그것이 문제를 일으킬 가치가 없다고 생각합니다. 짐을 싸고 풀기 위해 양쪽에 두 배의 공간이 필요하며 위에서 이미 언급했듯이 몇 가지 다른 옵션이 있습니다.

rsync압축도 수행됩니다. 플래그를 사용하세요 -z. 을 초과하는 경우 sshSSH 압축을 사용할 수도 있습니다. 내 느낌으로는 반복적인 압축 수준은 쓸모가 없다는 것입니다. 이는 중요한 결과를 얻지 못한 채 사이클만 소비할 뿐입니다. 압축을 시도하는 것이 좋습니다 rsync. 꽤 효과적인 것 같습니다. 사용 tar또는 기타 사전/사후 압축을 건너뛰는 것이 좋습니다 .

나는 보통 rsync를 rsync -abvz --partial....

오늘 내 홈 디렉터리를 NAS에 백업해야 했는데 이 토론을 접하고 결과를 추가하고 싶었습니다. 간단히 말해서, 내 환경에서는 네트워크를 통해 대상 파일 시스템에 taring하는 것이 동일한 대상에 대한 rsync보다 훨씬 빠릅니다.

환경: SSD 하드 드라이브를 사용하는 Source i7 데스크탑 컴퓨터. 대상 컴퓨터 Synology NAS DS413j는 기가비트 LAN을 통해 원본 컴퓨터에 연결됩니다.

물론, 관련된 키트의 정확한 사양이 성능에 영향을 미치며, 양쪽 끝의 네트워크 하드웨어 품질과 관련하여 정확한 설정의 세부 사항을 알지 못합니다.

소스 파일은 내 ~/.cache 폴더이며, 여기에는 대부분 1.2GB의 매우 작은 파일이 포함되어 있습니다.

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를 완전히 별도의 단계로 두었습니다. 실제 적용을 위해, SSH를 통해 tar 출력을 수신기로 전송하는 압축 해제 프로세스와 관련하여 Gilles가 위에 게시한 내용을 제안하겠습니다.

시간:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

rsync의 성능이 tar 작업에 비해 놀라울 정도로 열악하다는 것은 명백합니다. 이는 아마도 위에서 언급한 네트워크 성능 때문일 수 있습니다.

많은 수의(대부분 작은) 파일(예: 홈 디렉터리 백업)을 백업하려는 사람에게는 tar 방법을 권장합니다. rsync는 매우 나쁜 선택인 것 같습니다. 내 절차 중 하나라도 정확하지 않은 경우 이 게시물로 다시 돌아오겠습니다.

갭

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

내부 내용이 잘 이해가 안 되네요 rsync. 파일 통계로 인해 대기 시간이 발생하는지 여부는 rsync데이터가 전송되는 방식 에 따라 다릅니다 . 파일 통계가 한 조각으로 전송되는 경우 RTT를 사용하면 tar+rsync+untar가 더 빨라질 수 있습니다.

그러나 1GiB의 데이터가 있는 경우 연결이 매우 빠르지 않으면 rsync가 더 빨라집니다!