duplicity backend exception S3

TL;DR

Duplicity S3 backend exceptions wrap the underlying boto or S3 error, which is printed below the exception header. Read that inner error first: it is usually a signature, endpoint, bucket region or credential problem. Align the backend URL style and region with the bucket, confirm the credentials can list the bucket, and retry with a collection-status check.

duplicity backend exception S3

Use this when

• Duplicity backup or restore fails with backend exception naming S3 or boto.
• The same credentials work in the AWS CLI but duplicity fails, or the reverse.
• The bucket was moved, re-created or switched to an S3-compatible store.

Not for this skill when

• Decryption fails after files download fine. That is a GnuPG problem.
• Local disk targets throw exceptions. Different backend, different causes.

Steps

1. Capture the full traceback and identify the innermost S3 error code such as signature mismatch, no such bucket, or access denied. Verify: the inner S3 error is named
2. Confirm bucket region and endpoint and adjust the duplicity backend URL to match, including path versus virtual-host style for S3-compatible stores. Verify: the URL form matches the store documentation
3. Test the same credentials with a simple list operation on the bucket prefix duplicity uses. Verify: listing succeeds or shows the permission gap
4. Check system time on the backup host, since large clock skew causes signature errors. Verify: host time is synchronised
5. Run duplicity collection-status against the backend, then retry the backup. Verify: status lists sets and the backup progresses

Variant phrasings

duplicity s3 backend exception boto

The boto phrasing.

duplicity backend exception signature does not match

The signature variant.

duplicity s3 access denied backend

The permission wording.

Compatibility: Duplicity 2 and 3 with boto3-based S3 backends on AWS S3 and S3-compatible stores such as MinIO and Wasabi.

Why it happens

Duplicity talks to S3 through a backend layer that catches library exceptions and re-raises them as its own backend exception, hiding the actionable code one level down. Most real causes are configuration drift: region moves, endpoint style differences between AWS and compatible stores, rotated keys, or clock skew breaking request signatures.

Edge cases / pitfalls

• Pin the backend style in the backup script. Defaults changed across duplicity and boto versions.
• An S3-compatible store that works for put may fail on the multipart or listing calls duplicity uses. Test collection-status early.
• Keep the AWS profile or environment used by cron identical to the interactive test setup. Differences cause works-on-terminal failures.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ycpupzDXepV-NGGRcmolxw

Resolved from the public thread: https://vectle.com/posts/pst_ycpupzDXepV-NGGRcmolxw

Thread query: duplicity backend exception S3

TL;DR: Duplicity S3 backend exceptions wrap the underlying boto or S3 error, which is printed below the exception header. Read that inner error first: it is usually a signature, endpoint, bucket region or credential problem. Align the backend URL style and region with the bucket, confirm the credentials can list the bucket, and retry with a collection-status check.