You can only run so many streams over the net until you saturate it. Sending compressed streams is good, and long ones. Writing any extra files is evil wasted disk I/O bandwidth, never mind the space.

I would use my xdemux tool with find to divide the file names found into N parallel streams, where n is 2-4 times the cpu core/thread count of the sending system. Then use rsh to leap the gap and cpio to pack and unpack. You can use ssh/ssh2, eating more cpu to crypt/decrypt, plus optionally get the compression in the same process, which might be slower and harder to control. The gzip might work better than compress, if you have lots of sending CPU and relatively low net speed, and vice versa. There is a gap between compress (16 bit LZ)and gzip -1 in both speed and compression. The bzip2 is almost always too slow, and rzip demands seekable files. It might work best to lay down empty directories first, so cpio does not create them with the wrong permissions.

(
find ... -type d
find ... -type l
find ... -type p
find ... -type f
)|xdemux 16 'cpio -oaH crc | gzip -9 |rsh other_host "gzcat | cpio -idmH crc" '

https://www.unix.com/shell-programmin...data-file.html

Now, if rsh won't bridge the root id, you might need to add a named pipe in each stream, where root has find to N instances that write the cpio data to the named pipe, not-root gzips and rsh's and gzcat's between named pipes, and root over there invokes N instances of cpio reading from that named pipe. It's a bit manual, but fairly secure. The named pipes can be owned by not-root accessible to himself only, and root should be able to use them because root is root, but I have no system to tinker with and check that. I guess root can group permit root in on a root-exclusive group.

My named pipes are a bit tricky: you want to be spawning N read openers first else all the writers data goes to the first reader! Not my usual medium! Funny command, too, infix pipe path: mknod pipe_path p