export const meta = {
title: "How to Deliver Multi-Terabyte Projects Over the Internet",
description: "Learn how to move multi-terabyte media projects online with chunking, resumable transfers, checksum verification, time estimates, and drive shipping decisions.",
tldr: "Multi-terabyte internet delivery works when you calculate real sustained upload time, split the project into meaningful packages, use a resumable transfer tool, and verify each package with checksums before deleting sources. If the network can't beat the full copy, verification, courier, ingest, and re-verification time for a drive, ship a drive or use a hybrid plan with priority files online first.",
slug: "how-to-deliver-multi-terabyte-projects-over-the-internet",
publishedAt: "2026-08-20",
readingTime: 10,
thumbnail: "https://cdn.aspectlabs.dev/blog/how-to-deliver-multi-terabyte-projects-over-the-internet/cover-6b115f1ff6e0.png",
authors: ["bright"],
primaryTopic: "technical-solutions",
topics: ["technical-solutions"],
tags: ["file-transfer"],
faq: [
{
"question": "How do I estimate how long a multi-terabyte upload will take?",
"answer": "Convert the data size to bits, then divide by the sustained upload speed in bits per second. For example, 1 TB is roughly 8 terabits, so at a sustained 100 Mbps it takes about 22 hours before overhead. In real workflows, add margin for protocol overhead, throttling, packet loss, disk speed, encryption, and destination limits. For shared or uncertain networks, doubling the clean math estimate is often safer than assuming perfect throughput."
},
{
"question": "Is it better to upload one huge archive or split the delivery into smaller packages?",
"answer": "For most post workflows, splitting is safer. Package media by shooting day, card, reel, episode, department, priority, or destination. Smaller packages are easier to retry, verify, and ingest. A failed 500 GB package is manageable, while a failed 8 TB archive can put the whole delivery at risk. Large archives can help when there are hundreds of thousands of small files, but they should still be kept to a size that can be reasonably retried."
},
{
"question": "Why are browser uploads risky for multi-terabyte deliveries?",
"answer": "Browser uploads aren't designed for long, failure-prone media transfers. They may time out, restart poorly after interruption, hide useful logs, or fail when handling very large files or deep folder trees. Multi-terabyte deliveries should use a resumable transfer client, managed transfer platform, cloud agent, or other tool that supports retries, large files, parallel transfers, logging, permissions, and integrity validation."
},
{
"question": "How should transferred media be verified after upload?",
"answer": "Use checksums or a transfer system that provides equivalent integrity validation. The sender generates a checksum manifest at the source, transfers it with the files, and the receiver recalculates checksums after arrival. The results are compared and saved with the delivery record. A transfer shouldn't be considered complete until the expected files exist, byte counts match, checksums pass, and the package is readable by the next workflow system."
},
{
"question": "When is shipping a physical drive faster than uploading?",
"answer": "Shipping a drive can be faster when the dataset is very large, upload bandwidth is poor, the connection is capped or unstable, or the recipient can't ingest from a cloud or managed transfer platform. Compare time to usable files, not just transit time. Drive delivery includes copying to the drive, verifying it, courier transit, receiving, copying to destination storage, and verifying again. If a 10 TB upload will take six days and a verified courier drive can be usable tomorrow, the drive likely wins."
},
{
"question": "How can editorial start working before a multi-terabyte upload is completely finished?",
"answer": "Stage the delivery so project files, proxies, selects, or priority reels arrive first. In Aspect, editors can open media from a shared cloud filespace, which reduces the need to wait for every full-resolution file to land on a local drive before work begins."
}
],
}
The first question is: “will the upload finish, verify, and be available somewhere useful before the delivery window closes?”
For multi-terabyte projects, internet delivery is completely viable, but only if you treat it like a transfer workflow instead of a giant drag-and-drop. The difference is planning around [real upload bandwidth](https://movielabs.com/cloud-work-flows/), splitting the delivery into sane units, using a transfer method that [can resume after failure](https://www.ibm.com/downloads/documents/us-en/107a02e949c8f534), and verifying the result before your team deletes source media or tells editorial they're clear to proceed.
A 4 TB turnover can be painless on a prepared connection with the right transfer client, but the same 4 TB can become a three-day mess on hotel Wi-Fi, a throttled cloud drive, or a remote office where the receiving storage fills up halfway through.
## The decision starts with time
Terabytes sound abstract until you convert them into hours. The rough transfer-time formula is:
`total bits / usable bits per second = transfer seconds`
Since storage is usually measured in bytes and bandwidth in bits, multiply terabytes by 8 before doing the math. Then account for overhead, throttling, packet loss, encryption, local disk speed, and the fact that “1 Gbps internet” rarely means 1 Gbps sustained upload to your destination.
Here are useful ballpark estimates for a 1 TB upload at sustained throughput:
| Sustained upload speed | Approximate time for 1 TB | Approximate time for 5 TB |
| --- | ---: | ---: |
| 25 Mbps | 3 days, 17 hours | 18 days, 12 hours |
| 50 Mbps | 1 day, 20 hours | 9 days, 6 hours |
| 100 Mbps | 22 hours | 4 days, 15 hours |
| 250 Mbps | 9 hours | 1 day, 20 hours |
| 500 Mbps | 4.5 hours | 22 hours |
| 1 Gbps | 2.2 hours | 11 hours |
| 2 Gbps | 1.1 hours | 5.5 hours |
| 10 Gbps | 13 minutes | 1.1 hours |
These are clean math estimates, so in production, add margin. For a one-time upload over a shared office connection, 30 percent margin is optimistic. For field networks, hotel internet, mobile routers, congested Wi-Fi, or an unknown client-side destination, double the estimate before promising a delivery time.
The most important numbers are the sustained upload speed from the source and the sustained ingest speed at the destination. A sender with 1 Gbps service, a NAS that reads at 120 MB/s, and a destination that throttles after 750 GB per day won't deliver like a true 1 Gbps path.
## Know what kind of delivery you're making
Not all multi-terabyte deliveries have the same risk profile. A camera-card backup from set, a locked master delivery, a VFX pull, and a full conform turnover all behave differently.
The constraints that usually change the recommendation are:
- Total volume matters because 800 GB, 4 TB, 20 TB, and 100 TB are different problems.
- Deadline shape matters because “as soon as possible” is different from “editorial needs the first reels tonight.”
- Network stability changes the tooling because a fast but flaky connection needs different handling than a slower but stable one.
- Security requirements may include encryption, expiring access, audit logs, and named users for unreleased media.
- Post workflow affects whether files need to be delivered into cloud storage, a MAM, shared storage, or a specific folder structure for automation.
The takeaway is simple: decide whether you're moving a finished package, a stream of incoming media, or a staged delivery that needs to become useful before the full transfer completes.
If the whole show must arrive before anyone can work, your only lever is total transfer time. If editorial can start with proxies, reels, stringouts, turnovers, or priority bins, split the delivery so the earliest usable material moves first.
## Break the project into delivery units
The fastest way to make a large transfer fragile is to treat it as one enormous folder with no internal structure. If the transfer tool has to scan millions of files, retry a half-failed tree, or rehash everything from scratch, you lose time before the upload even begins.
A better unit is a package that's large enough to transfer efficiently, small enough to retry, and meaningful enough for the recipient to ingest.
Common package boundaries in post workflows include:
- Shooting day or card, which is useful for original camera media and dailies.
- Reel, act, sequence, or episode, which is useful for editorial and finishing turnovers.
- Department, such as VFX plates, audio, color, graphics, project files, and references.
- Priority, such as proxies first, then audio, then high-resolution camera media.
- Storage target, with one package per destination bucket, workspace, or ingest folder.
For very large projects, avoid creating a package for every tiny folder unless the receiving system requires it. Too many small files can be a performance problem by itself. Cloud and enterprise transfer systems often handle large datasets better when the file tree is balanced and individual source folders don't contain absurd numbers of files.
There are two common ways to package media:
- Preserve the folder tree and transfer files directly.
- Archive groups into tar, zip, or similar container files before transfer.
Preserving the tree keeps the delivery transparent. The receiver can inspect partial arrivals, run folder-level ingest, and avoid a huge unpacking step. This is usually better for camera originals, editorial turnovers, and workflows where metadata sidecars matter.
Archiving can help when there are [hundreds of thousands of small files](https://cloud.google.com/blog/products/storage-data-transfer/best-practices-for-large-scale-migrations-to-google-cloud), when a destination performs poorly with deep folder trees, or when you need a single object per package. But archives introduce their own failure mode: one corrupted multi-terabyte archive can block access to everything inside it. If you archive, keep archives to a size you can reasonably retry and verify.
For example, instead of one 8 TB archive, create reel or day packages in the 250 GB to 1 TB range, depending on your connection and deadline. A failed 500 GB retry is annoying. A failed 8 TB retry can kill a delivery window.
## Use a resumable transfer method, not a browser hope-and-pray
Browser uploads are fine for small deliverables, but multi-terabyte transfers need a client, agent, or managed file transfer system that's designed for interruption.
At minimum, the transfer method should support:
- Resume after network loss without restarting completed files.
- Parallel or multi-part transfers where appropriate.
- Automatic retry with sane backoff.
- Transfer logs showing success, failure, and skipped files.
- Checksum or hash validation.
- Large file support above your biggest expected file.
- Authentication and permission control.
- A destination that can accept the full payload.
FTP is still around, but it's rarely the best default for modern media delivery. Basic FTP can be slow over long distances, painful through firewalls, weak on security unless you wrap it properly, and poor at giving non-technical recipients a clean experience. TCP-based tools are reliable, but raw single-stream TCP can underuse [high-bandwidth, high-latency paths](https://fasterdata.es.net/assets/fasterdata/Tierney-bulk-data-transfer-tutorial-Sept09.pdf) because acknowledgments and round-trip time limit how much data stays “in flight.”
That's why accelerated [transfer tools](https://www.youtube.com/watch?v=OCX3-n3QabE), managed file transfer platforms, and cloud-native agents exist. They try to fill the available pipe more effectively, resume failed chunks, run multiple streams, or optimize TCP behavior. Some also support watch folders, transfer while a file is still growing, channel bonding across multiple networks, and direct ingest into object storage.
The useful decision is whether the tool can sustain throughput on your actual path while preserving integrity and giving the receiver a clean handoff. For a one-off client delivery, ease of download and auditability may matter more than squeezing out every last megabit. For dailies from a remote set, auto-resume, background agents, and unstable-network behavior matter more.
| Transfer approach | Best fit | Strengths | Watch for |
| --- | --- | --- | --- |
| Browser upload | Small ad hoc files and noncritical deliverables | Simple, no install, easy for casual recipients | Weak resume behavior, session timeouts, file size limits, limited logs |
| Cloud sync or desktop drive client | Ongoing folders, modest turnovers, teams already using the platform | Familiar interface, background syncing, easy sharing | Conflicts, throttling, unclear verification, accidental renames or deletions |
| Command-line or cloud-native agent | Planned large transfers into object storage or technical destinations | Resume support, multipart transfer, scripting, logs, predictable automation | Requires setup, credentials, and someone comfortable reading transfer output |
| Managed or accelerated media transfer | Time-sensitive terabyte delivery, long-distance links, unstable networks, remote set workflows | Better path utilization, auto-retry, audit logs, watch folders, named users | Licensing cost, recipient onboarding, destination compatibility |
| Physical transfer appliance | Tens or hundreds of terabytes into cloud when bandwidth cannot meet the schedule | Avoids weak internet paths and can seed a large cloud library | Lead time, chain of custody, shipping risk, later ingest and verification still required |
## Stage the upload so people can work earlier
Multi-terabyte delivery often fails socially before it fails technically. Someone says “the upload is at 62 percent,” but nobody knows whether the missing 38 percent contains the shot the colorist needs tomorrow.
Treat priority as part of the transfer plan.
A staged delivery might look like this:
- Project manifest, delivery notes, and folder map.
- Low-resolution proxies or review exports.
- Editorial project files, bins, XML, AAF, EDL, and reference media.
- Audio turnover and mix references.
- VFX pulls or color-critical selects.
- Remaining camera originals or full-resolution plates.
- Supplemental assets, stills, graphics, fonts, LUTs, and reports.
This exact order won't fit every show, but “everything at once” is usually the least helpful queue. Put the files that unblock human work at the front, then let the heavier media follow.
Aspect streams bytes to your Finder or NLE, so editors can start working with full resolution clips before a giant transfer finishes. The file opens at quality from the shared cloud space instead of waiting for a full local download.
If your transfer tool supports priority queues, use them. If it doesn't, create separate packages and start them in order. Make sure the recipient understands which packages are ready to ingest and which are still in flight.
## Verification belongs inside the workflow
For original camera data and high-value media, simple copy methods aren't enough because Finder, Explorer, and basic drag-and-drop don't give you the confidence needed to wipe source media or release a drive. Professional camera workflows typically rely on [checksum-verified copies](https://www.arri.com/en/learn-help/learn-help-camera-system/pre-postproduction/data-transfer) for exactly this reason.
A checksum acts as a calculated fingerprint of a file. If the sender calculates a hash and the receiver calculates the same hash after transfer, you have strong evidence that the file arrived unchanged.
The usual verification pattern is:
- The sender generates checksums at the source.
- The sender transfers the files and checksum manifest together.
- The receiver recalculates checksums at the destination.
- The receiver compares the destination result against the source manifest.
- The receiver saves the report with the delivery.
MD5, xxHash, SHA-1, and SHA-256 all appear in real workflows. The “best” choice depends on tool compatibility and security policy. For media integrity, the most important thing is that the sender and receiver use the same algorithm consistently and record the result. For higher-security environments, use the stronger hash required by the production or studio.
Your team should verify at package boundaries. If you deliver by shooting day, verify each day. If you deliver by reel, verify each reel. That lets the receiver accept known-good packages while later packages continue to move.
A delivery isn't complete just because a transfer client says “done,” but when the receiver can confirm that the expected files exist, the byte counts match, the checksums pass, and the package is readable by the next system in the workflow.
## Plan for the destination, not just the upload
A lot of transfer plans only consider the sender’s side, and that's how you end up with a perfect upload into a destination that can't ingest the package.
The receiving side needs enough storage, write performance, permissions, and process. If the destination is cloud storage, you should check object limits, per-file limits, daily upload caps, lifecycle rules, and whether the recipient has egress concerns later. If the destination is on-prem shared storage, you should check available capacity, RAID or NAS write speed, network interface speed, and whether other work is using the ingest machine.
Common receiving-side failures include:
- The destination account has a daily upload or storage quota.
- The receiving drive uses a format with a file size limit.
- The cloud bucket path or permissions are wrong.
- The folder structure changes during download and breaks relinking.
- The recipient can't see logs or verify what arrived.
These are boring problems, which is why they hurt. They're easy to miss and expensive to debug during a deadline.
For major deliveries, run a real test before the actual transfer. Don't test with a 200 MB file and assume the 6 TB handoff will behave the same. Use at least a large enough sample to exercise the path, ideally [100 GB or more](https://cloud.google.com/storage-transfer/docs/on-prem-agent-best-practices), with a mix of file sizes similar to the real project. Measure sustained throughput, not the first minute of burst speed.
## Don't improvise security at delivery time
Media delivery is part of the security boundary of a production. The transfer may include unreleased episodes, talent footage, client assets, credentials embedded in project files, or copyrighted masters. Convenience links and shared passwords aren't enough for sensitive material.
Aspect gives teams granular permissions for people, folders, projects, and share links, with password protection and link expiry. A rough cut, VFX pull, or turnover can be shared without creating permanent forwardable access.
For multi-terabyte internet delivery, security requirements usually include:
- Named users rather than shared logins.
- Encrypted transfer in transit.
- Encryption at rest where the media is stored.
- Access expiration or removal after delivery.
- Audit logs for upload, download, and access.
Security also affects packaging. If one vendor only needs a VFX pull, don't send the whole turnover because it's easier. If a client only needs final masters, don't include project files, source media, or internal notes in the same package.
Your team should upload files to a production-controlled destination first, then grant recipient access from there. That avoids losing control when someone uploads a transfer to someone’s personal cloud account or forwards it as an open download link.
## When shipping a drive is faster
Sometimes the right answer is still to ship a drive because the internet isn't magic, and bandwidth isn't evenly distributed.
A drive can win when:
- The dataset is very large.
- The available upload speed is poor or capped.
- The distance is short or courier service is predictable.
- The recipient can't accept cloud or managed transfer delivery.
- The cost of cloud ingest, storage, or egress is higher than the courier workflow.
The comparison should include the full path, not just courier time, because [shipping a drive](https://cacm.acm.org/practice/should-you-upload-or-ship-big-data-to-the-cloud/) includes copying to the drive, checksum verification, packing, pickup, transit, possible customs delays, delivery, mounting, copying or ingesting at the destination, and verification again. During transit, nobody can use the media unless you also started an internet transfer or sent a duplicate.
A simple way to decide is to compare “time to usable files,” not “time to arrival.”
Internet delivery time includes:
- Preparing packages.
- Uploading.
- Verifying at destination.
- Ingesting into the next system.
That's the online path to compare against the physical one.
Drive delivery time includes:
- Copying to drive.
- Verifying the drive.
- Courier pickup and transit.
- Receiving and mounting.
- Copying from drive.
- Verifying destination storage.
If a 10 TB upload will take six days on the available connection, and a courier can get a verified drive to the facility by tomorrow morning, ship the drive. If a 4 TB upload will finish overnight and upload directly into shared cloud storage where editorial, color, and VFX can access it, uploading is probably better than creating a physical blind spot.
For extreme cases, cloud providers also offer physical transfer appliances. Those make sense when you need to move tens or hundreds of terabytes into cloud storage and the local internet path can't support the schedule. They're less relevant for everyday post handoffs, but useful for archive migrations, library moves, and large production ingest.
## Hybrid delivery is often the best answer
The drive-versus-internet debate is usually too binary. Many real workflows benefit from both.
For example, send proxies, project files, and priority selects over the internet immediately, then ship a verified drive with full camera originals. Editorial starts today, while the full-res safety copy follows. Or upload the day’s dailies every night, but rotate shuttle drives as a backup path. Or ship the first large baseline dataset, then send incremental changes over the internet after that.
Hybrid delivery works especially well when the first upload would be huge but later changes are manageable. Once the receiver has the initial media, new turnovers, revised shots, audio updates, and project files can move online without repeating the whole dataset.
The key is to avoid two unsynchronized truths. If files travel by both drive and internet, maintain a manifest that says which package is authoritative, which version is current, and which packages the receiver has verified. Otherwise the team may waste hours comparing folders called “final,” “final_from_drive,” and “final_upload_retry.”
## A sane multi-terabyte delivery plan
A reliable internet delivery usually looks like this in practice.
Start by measuring the source size, file count, largest file, and deadline. Then measure sustained upload speed from the actual network you'll use. Ask the receiver where you should upload files, how much space exists, what limits apply, and who will verify arrival.
Package the project into meaningful units. Put the units that unblock work first. Generate checksums for each package or use a transfer tool that does this in a way both sides can audit. Use a resumable client, agent, or managed transfer system rather than a browser tab. Keep logs.
During transfer, watch sustained throughput, failed files, and destination capacity. If the connection drops, resume instead of restarting. If a package fails repeatedly, isolate it rather than rerunning the whole project. When each package completes, verify it at the destination and tell the team exactly what is ready.
After delivery, keep the source copy intact until the receiver confirms verification and ingest. For camera originals or irreplaceable project assets, don't erase original media based only on “upload complete.” Wait for verified acceptance.
Multi-terabyte delivery over the internet is risky when the workflow is vague. Once you know the real bandwidth, divide the work into useful packages, use resumable transfer, verify integrity, and compare the internet path against courier time honestly, the decision becomes straightforward.