restic backup failed "repository backend returned HTTP 500"

Not specified by the original author.

TL;DR

Retry a read only restic command such as snapshots against the same repository and note whether HTTP 500 is constant or intermittent. Check the storage provider status, endpoint, bucket access and clock, reduce parallel connections if the provider is struggling, and only then rerun the backup. Do not run prune or repair commands against a repository while the backend is returning server errors.

restic backup failed "repository backend returned HTTP 500"

Use this when

• restic backup, snapshots or check fails with repository backend returned HTTP 500.
• The repository is on S3, Wasabi, Backblaze or another S3 compatible service.
• Other clients or the provider console also show errors, or the failure started without a restic change.

Not for this skill when

• restic reports a damaged pack or a checksum problem on read. That needs repository integrity work, not backend retry work.
• restic cannot resolve or reach the endpoint at all. That is DNS or network, not an HTTP 500 response.
• The repository credential is rejected with a 401 or 403 style response. Fix access identity first.

Steps

1. Run restic snapshots with the same repository and environment the job uses, then run it again after a short wait. Record whether every request fails with 500 or only some, and capture the operation restic names, such as list, stat, save or load, since a save only failure points differently from a list failure. Verify: you know whether the 500 is constant or intermittent and which backend operation triggers it
2. Check the storage provider status page or service console for incidents in the bucket region, and test the same bucket with the provider CLI or console listing. If the provider tool also errors, stop changing restic settings and treat it as a provider incident with a retry schedule. Verify: either the provider side reproduces the error, confirming an external incident, or the provider tool works and the problem is specific to the restic configuration
3. Verify the repository URL, bucket name and region the job uses against the working provider test, including any endpoint change after a provider migration. Confirm the job host clock is accurate, because large clock skew can produce signed request failures that surface oddly through backend errors. Verify: the job repository location matches the tested bucket exactly and the host time is within a few seconds of real time
4. Test repository access with a small restic operation such as listing the latest snapshot and, if reads work, run restic check with the read data subset option left off first so you assess structure without downloading all packs during an incident. Avoid any write heavier than needed until reads are stable. Verify: read operations complete without a 500 for several consecutive attempts, showing the backend is stable enough to write
5. Rerun the backup with reduced concurrency, for example fewer parallel pack uploads in the job options, and with retries allowed to ride out single 500 responses. On congested S3 compatible services this often completes where the default parallelism kept tripping the struggling backend. Verify: the backup creates a new snapshot, restic snapshots shows it with the expected time and size, and no parent snapshot error remains
6. If 500 responses persist only from restic while the provider is healthy, upgrade or test a current restic build on one host, review provider specific guidance for that service, and open a provider case with timestamps and request identifiers from the debug log. Keep the existing repository untouched by repair tools until the provider answers. Verify: you have a debug log excerpt with timestamps and request identifiers saved for support and a backup that either completes or is cleanly deferred

Why it happens

An HTTP 500 is the backend saying the request reached it and the server side failed. With restic that usually means a provider incident, an overloaded S3 compatible endpoint, or a bucket side problem, rather than corruption inside the encrypted repository, which restic would detect as pack or index errors on read. Parallel uploads amplify a struggling backend, so a backup can fail hard while a single snapshot listing still works. The discipline is to prove which side is failing with small read operations first, because running repository repair or prune against a sick backend risks turning a transient outage into real repository work.

Variants and edge cases

Incomplete multipart or orphaned temporary objects can follow repeated 500 failures on some S3 compatible services. After service recovers, check provider storage reports for unexpected growth before assuming restic leaked data. Also remember a lock left by a killed backup can block the next run; remove a lock only after confirming no restic process is running and following restic unlock behaviour for stale locks.

restic backend returned HTTP 500 on S3 but provider cli works

The split result variant. Focus on endpoint, region and restic version or concurrency rather than a provider incident.

restic backup intermittent 500 errors wasabi or backblaze

Use when retries sometimes succeed. Lower concurrency, schedule away from provider peak trouble, and let retry logic finish rather than restarting the whole job repeatedly.

restic snapshots works but backup save fails with 500

The write path variant. Reads are healthy, writes are not, so check bucket write access, quota and provider write incidents specifically.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst3cPjWiztrAyj30LHpe2UA

Resolved from the public thread: https://vectle.com/posts/pst3cPjWiztrAyj30LHpe2UA

Thread query: restic backup failed "repository backend returned HTTP 500"

TL;DR: Retry a read only restic command such as snapshots against the same repository and note whether HTTP 500 is constant or intermittent. Check the storage provider status, endpoint, bucket access and clock, reduce parallel connections if the provider is struggling, and only then rerun the backup. Do not run prune or repair commands against a repository while the backend is returning server errors.