backup upload to S3 failed request timeout
Fixes S3 backup upload request timeouts: reduce part size or concurrency, fix clock and network path issues, and enable resumable multipart so timeouts stop killing backups. Use when uploads to S3 time out. Not for multipart abort errors after upload.
TL;DR
Request timeouts uploading to S3 usually mean parts are too large for a slow or lossy path, too many parallel parts saturate the uplink, or the client waits on a hung connection. Lower multipart size and concurrency to match the uplink, confirm host time sync for signed requests, and use tooling that resumes parts instead of restarting whole objects.
backup upload to S3 failed request timeoutUse this when
- Backup uploads to S3 fail with request timeout or socket timeout.
- Failures cluster on large files or busy uplink hours.
- Local repository backups on the same job succeed.
Not for this skill when
- S3 returns access denied or no such bucket. Configuration, not timeouts.
- A multipart upload completes parts but the final completion call fails. Different stage.
Steps
- Check the backup host uplink utilisation and error rates during a failing upload. Verify: path quality during failure is measured
- Reduce multipart part size and parallel upload threads in the backup tool S3 settings. Verify: new settings are applied to the job
- Confirm the host clock is synchronised, since skewed clocks also break signed S3 requests. Verify: time offset is near zero
- Run a test upload of a large file with the same tool and settings and watch it complete with retries visible but succeeding. Verify: the test object lands and verifies
- Run the full backup and confirm objects upload without request timeout failures. Verify: the job completes to S3
Variant phrasings
s3 upload timeout backup multipart settings
The settings phrasing.
aws s3 request timeout backup job failed
The job variant.
s3 socket timeout large file backup
The large-file wording.
Compatibility: AWS S3 and S3-compatible endpoints used by Veeam, restic, rclone, duplicacy and similar tools, with multipart uploads over WAN links.
Why it happens
S3 itself rarely times out healthy requests; the path and the client settings do. Signed requests expire, home and branch uplinks drop packets under saturation, and very large parts mean each retry re-sends hundreds of megabytes. Right-sizing parts to the link turns timeouts from fatal to merely retried.
Edge cases / pitfalls
- Endpoint choice matters: an S3 endpoint in the wrong region adds latency that compounds timeouts. Verify bucket region.
- Antivirus or TLS inspection proxies on the path can reset long uploads. Test from a clean path if timeouts persist.
- Tools differ in default part sizes by an order of magnitude. Record the values that work for your link.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_0pjJZw-D-fYg0BSLMC8PTw