When you send the same set of files, rsync is better suited because it will only send differences. tar will always send everything and this is a waste of resources when a lot of the data are already there. The tar + rsync + untar loses this advantage in this case, as well as the advantage of keeping the folders in-sync with rsync --delete.
If you copy the files for the first time, first packeting, then sending, then unpacking (AFAIK rsync doesn't take piped input) is cumbersome and always worse than just rsyncing, because rsync won't have to do any task more than tar anyway.
Tip: rsync version 3 or later does incremental recursion, meaning it starts copying almost immediately before it counts all files.
Tip2: If you use rsync over ssh, you may also use either tar+ssh
tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'
or just scp
scp -Cr srcdir user@server:destdir
General rule, keep it simple.
UPDATE:
I've created 59M demo data
mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done
and tested several times the file transfer to a remote server (not in the same lan), using both methods
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
while keeping separate logs from the ssh traffic packets sent
wc -l rsync.log rsync+tar.log
36730 rsync.log
37962 rsync+tar.log
74692 total
In this case, I can't see any advantage in less network traffic by using rsync+tar, which is expected when the default mtu is 1500 and while the files are 10k size. rsync+tar had more traffic generated, was slower for 2-3 seconds and left two garbage files that had to be cleaned up.
I did the same tests on two machines on the same lan, and there the rsync+tar did much better times and much much less network traffic. I assume cause of jumbo frames.
Maybe rsync+tar would be better than just rsync on a much larger data set. But frankly I don't think it's worth the trouble, you need double space in each side for packing and unpacking, and there are a couple of other options as I've already mentioned above.
Similar to what jw013 suggested in the comments with separate compression/decompression steps, i.e. combine two ssh commands with a pipe:
compress=gzip
decompress=gunzip
ssh remote1 "cd srcdir; tar cf - dir | $compress" |
ssh remote2 "cd destdir; $decompress | tar xvf -"
Note that the compression/decompression is configurable without depending on the version of tar.
Update
You could also add checksum verification into the pipe:
compress=gzip
decompress=gunzip
ckprg=md5sum
cksum=/tmp/cksum
ssh remote1 "cd srcdir; tar cf - dir | $compress | tee <($ckprg > $cksum)" |
ssh remote2 "cd destdir; tee <($ckprg > $cksum) | $decompress | tar xvf -"
ssh remote1 cat $cksum
ssh remote2 cat $cksum
Best Answer
As @Kusalananda says in the comments, tar is disk-bound. One of the best things you can do is put the output on a separate disk so the writing doesn't slow down the reading.
If your next step is to move the file across the network, I'd suggest that you create the tar file over the network in the first place:
This way the local host only has to read the files, and doesn't have to also accommodate the write bandwidth consumed by tar. The disk output from tar is absorbed by the network connection and the disk system on
otherhost.