How to Send a 1 TB File to a Client Without Restarting

Start with feasibility, not the upload button

To send a 1 TB file reliably, first calculate the transfer window, confirm that both sides have enough disk space, package the correct data, create an integrity checksum, and choose a resumable transfer. At 100 Mbps upstream, one decimal terabyte has an arithmetic minimum upload time of about 22 hours 13 minutes before overhead. At 20 Mbps, it is roughly 111 hours.

If the connection or deadline cannot support that window, shipping an encrypted drive may be the responsible choice. A transfer tool cannot repeal the available bandwidth.

1. Calculate the real transfer window

Use the upload-time calculator with a measured upstream speed. The result is a theoretical minimum. Add margin for packaging, encryption, protocol overhead, congestion, and retries.

2. Confirm every limit before packaging

A service can advertise terabyte storage while allowing a smaller individual file, or allow a large file while limiting recipient downloads. Check these independently:

• Largest single file: the packaged object must fit.
• Available storage: existing files may leave less room than the plan headline.
• Monthly recipient-download bandwidth: every successful full download consumes approximately the plaintext file size.
• Retention and expiry: the link must remain available long enough for the client.
• Recipient requirements: confirm whether an account or special client is needed.

VaultDrop Pro is labelled for files up to 1 TB, includes 1 TB storage, and provides 2 TB of monthly recipient-download bandwidth. A decimal 1 TB package uses most of the advertised storage. One full recipient download uses about half the monthly download allowance; two full downloads use about all of it if there are no other downloads that month. Limits are enforced rather than converted into an overage invoice.

3. Build one deliberate delivery package

Do not assume that a project folder is self-contained. For video, CAD, BIM, GIS, or scientific work, use the originating application's collect, archive, or transmit function where one exists. Then inspect the result.

A useful package normally includes:

• the final deliverables or project files;
• linked media and permitted dependencies;
• a manifest describing the folder structure and expected contents;
• software version and coordinate-system information where relevant;
• a checksum file;
• a short README with open, verify, and contact instructions.

Avoid an extra archive layer unless it solves a real problem. Compressing already-compressed video may consume hours without materially reducing size. An archive can still be useful to preserve a directory tree or deliver many small files as one object.

4. Create a checksum before upload

A SHA-256 checksum gives sender and recipient a compact value to compare. A match supports the conclusion that both sides have the same bytes. It does not, by itself, prove who created those bytes; exchange the expected digest through a trusted channel when authenticity matters.

Get-FileHash .\client-delivery.zip -Algorithm SHA256

# macOS
shasum -a 256 client-delivery.zip

# Linux
sha256sum client-delivery.zip

NASA's HECC guidance explains the sender-and-recipient checksum comparison workflow: Checking file integrity. Keep the digest in the manifest and, for sensitive work, send a trusted copy separately from the file link.

5. Use multipart recovery

A single-request upload has one failure domain: if that request fails, it starts again. A multipart upload divides the encrypted object into numbered parts. Completed parts can remain accepted while failed parts are retried.

Cloudflare documents multipart upload as the option for large files, parallelism, and resumability, with up to 10,000 parts: Cloudflare R2 upload methods. That describes the storage primitive; each application still decides how long to retain recovery state and how a browser reconnects it to the local file.

In VaultDrop, account files of 100 MiB or more use multipart upload. The browser retains recovery metadata locally for up to seven days. If the page reloads, select the same unchanged file and unlock the master key. Changing the name, size, or modification time can prevent the browser from safely matching it to the interrupted upload.

6. Prepare the recipient before sending

A successful upload is only half the delivery. Before the client starts:

• tell them the exact download size;
• confirm they have at least 1 TB free, plus working space for extraction or import;
• check that their filesystem supports the individual file size;
• ask them to use a stable connection and prevent sleep;
• provide the expected SHA-256 digest;
• agree on when the online copy can be deleted.

For confidential work, verify the recipient and exchange any password or secret through a separate channel. A password controls access; it does not replace correct recipient verification or device security.

7. Verify completion

Do not close the job when the link is sent. Ask the recipient to confirm the file opens and the checksum matches. Record which version was delivered, when it was downloaded, and when the online copy should be removed. If the checksum differs, do not try to repair the package by guessing which bytes changed—download again or create a new verified package.

Online transfer or encrypted drive?

Physical delivery introduces loss, delay, and key-exchange risks, so encrypt the drive and track custody. Online delivery introduces connection, account, and link-handling risks. Choose the risk you can control, not the method that sounds more modern.