I'm wondering what kind of data is the OP talking about? If the company isn't careful, they could run afoul of laws that are in place to protect certain kinds of data---for example, anything the would be covered by HIPAA. I would ask that workplace naysayer to reconsider not allowing the physical transfer via FedEx or the like (the modern equivalent of a station wagon full of 9-track tapes). The company's internal auditor and data security team may have some things to say about the preferred way to transmit data between the company and outside entities. The places where I've worked, when data had to be sent to or from "business partners" it had to be across a VPN or, at the very least, encrypted before being sent across the 'net.

3 members found this post helpful.

There may be security considerations, as above.

Sticking to the original qn, as it is in 7 dirs, I'd probably just produce one tar.gz file for each of the 7 dirs and then rsync them one at a time.
You can play with the compression settings - many tools eg gzip, bzip, xz have a parameter of value 1-9 which means higher the num, higher the compression, but more processing time reqd (to compress at least)

Reasons:
1 split into 7 logical separate sets is easier for knowing what data is where (for sender & receiver people).
Eg you could start processing the data (if reqd) as each set arrives, without waiting (if that makes sense)

2 rsync will cope (recover) if the cxn drops out, which, even with 7 smaller sets, may happen, depending on what the sender & receiver have as cxns.

Maybe not useful, but why not using zstd to compress a file? It is VERY fast! Many many times more than xz or gzip.
Then you can split the file, doing something like:
By this command you compress the file and create compressed pieces of it (in this case 200MB each).
When done, you find files named xaa, xab, xac, etc.
You can send the files, so in case of error, you must transfer again only 200MB.

At the other site, the command could be:
and then

Of course, everything said about the network speed is valid. But, zstd is VERY fast so you don't have to wait for hours, when compressing. The same for uncompressing.
You could check how big the compressed file is and, based on your network speed, you can understand how long it takes.

Using public repositories (like git, gdrive, etc.) could be anyway against the company police. Be careful!

PS zstd can be installed in Fedora by dnf. For other distro it should be available. Maybe, someone here can help about that.

I feel OP should consider taking this up with his management again. Getting 1.5 TB over the internet in this way is possible but prone to errors. I've just been migrating 4 TB of data between servers on the same LAN and even then it is not a one-off affair. Rsync was my friend.

You might consider putting the data in an encrypted Veracrypt container for safety and then ship it to its destination on a drive (preferably a SSD) after talking to your management and explain that online transfer of 1.5 TB of data is just not feasable - you can't put an ocean liner on a truck.

What part of the data are they "browsing"?

That amount of data over a network is a bad day. Recalling my dialup days of 10MB-15MB an HOUR. Sure I could do 10GB of downloads a month, with a persistent 24/7 connection. Even on my almost broadband connection now, it still takes about 4 hours to get a 4GB ISO for a distro. Might it just be easier to make that data available over a shell on a dedicated machine that only has ssh and that data, since they're "browsing". Otherwise physical media via snail mail will probably trump most "network" options. At least for MOST places in the USA.

Corporate entities would probably prefer that they come in person and sit down at a terminal so said data, that's probably sensitive, never leaves the campus. Sell them that first with transport and accommodations, and the disk drive plus postage becomes an easier sell. Or just abandoning the project entirely and taking a new less time consuming route.

Depending on the contents of that data, there are compression options better than .zip. Like rar or bz2. But high compression takes a while on modest hardware. And you need enough storage for the source data and the destination file(s). Plus the ability of the receiver of the data to uncompress it. Easy if they're well versed linux users. Perhaps a squashfs option so they can mount the compressed data and browse without having to uncompress it directly. Depends on how tech savvy (and *nix) they are.