If a multi-terabyte upload fails at 95%, the operational question is not merely “Did it fail?” It is how much acknowledged work the system can recover, how quickly the operator can prove that state, and whether the deadline still has enough margin. A resumable system may preserve substantial progress. A non-resumable workflow may require a complete restart. Neither outcome should be assumed until the service's recovery behavior is documented and tested.
For a 5 TB package on a sustained 1 Gbps upload, the current calculator's 12% planning-overhead model estimates 12 h 27 m for one complete attempt. Reaching 95% consumes roughly the first 11 h 49 m of that modeled effort. If recovery cannot reuse accepted data, another full attempt means another 12 h 27 m—before diagnosis, cleanup, or queue time.
Those durations are planning estimates, not a promise that the connection will sustain 1 Gbps. The model adds 12% to payload volume; actual protocol behavior, storage, shared traffic, and interruption handling can extend the result.
First, identify what “failed” means
A progress bar at 95% does not prove that 95% is safely committed at the destination. It may represent bytes read locally, bytes sent by the client, blocks accepted by storage, or files completed within a folder. Those states are different.
Ask four questions before restarting:
- Is the transfer session still valid? Session identifiers, temporary credentials, or upload URLs may expire.
- What did the destination acknowledge? Look for committed parts, an offset, completed files, or a server-side status—not only the local progress bar.
- Can the client reconcile local and remote state? A sound recovery flow checks what is already present before sending more.
- Was finalization reached? Multipart data can exist without the final object or package being complete and available to the recipient.
Do not delete local source data or declare delivery complete merely because most bytes moved. Completion and integrity verification are separate gates.
Model the deadline impact, not just lost bandwidth
The direct cost of a restart is retransmitted data and occupied upload capacity. The broader impact can include:
- a sender workstation that must remain online for another shift;
- a recipient whose download cannot start;
- storage-session or transfer-expiry windows that need renewal;
- operators who must inspect logs and determine whether retry is safe;
- downstream ingest, review, or client-delivery time displaced by the restart;
- contention with the next scheduled transfer.
This is why a nominally “five percent remaining” incident can become a full-day scheduling problem. At terabyte scale, recovery policy belongs in the delivery plan before the first byte moves.
Resumability reduces exposure; it does not eliminate it
The IETF's resumable-upload work describes a general HTTP approach in which a client can learn an upload offset and continue an incomplete upload. Other systems use multipart uploads, per-file completion, or service-specific sessions. The useful common property is that acknowledged progress can be discovered and reused.
But “resumable” is not one universal guarantee. A product may resume only while a session remains valid. It may retry a failed part but not survive a client restart. It may preserve completed files in a folder while restarting the current file. It may require the original local file to remain unchanged. Recovery can also fail if credentials expire, the destination discards incomplete parts, or metadata no longer matches.
For planning, record the exact recovery boundary the service documents and the behavior your team has observed. Do not infer an exact byte offset or algorithm from a marketing label.
Build a recovery runbook
Before a deadline-critical send:
- keep the source immutable and available until the recipient verifies delivery;
- save a manifest with names, sizes, and expected integrity values;
- prevent sleep, forced restarts, and avoidable network changes;
- define who checks the job and when;
- capture the transfer/session identifier and diagnostic logs;
- know session, credential, and package-expiry rules;
- test cancellation, app restart, and connectivity loss with disposable data;
- reserve enough time for the documented worst recovery path.
The runbook should distinguish retry, resume, and restart. Retry repeats an operation after an error. Resume continues from reusable acknowledged state. Restart creates a new attempt and may retransmit everything. Operators need to know which action the client is taking.
Decide whether to continue, restart, or switch methods
Continue the existing session when remote state can be authoritatively reconciled and the session remains usable. Start over when the service cannot establish trustworthy state, the source changed, or final integrity cannot be proven. Switching to another circuit, another transfer method, or physical media can be rational when the remaining calendar window is smaller than the credible recovery path.
That choice should use measured endpoint capacity and the real deadline, not frustration with the progress bar. A late incident is also a signal to preserve evidence: timestamps, error codes, local events, destination status, and any integrity result.
Where TeraAirlift fits
TeraAirlift is a Windows-first desktop operations console with queue, progress and ETA, cancellation, retry-friendly operations, history, diagnostics, recipient-controlled linkless delivery, and SHA-256 integrity verification. Those capabilities help an operator see and investigate a failed job. They do not promise an exact resume offset, recovery outcome, throughput, or delivery time. Schedule a demo to review the intended workflow and test recovery against your own package shape.
