A backup run failed: reading the verdict, finding the cause, and rerunning
A failed run is a run that could not seal a complete archive, and downpipes treats it as headline news rather than a footnote. The Runs view sorts newest-first by default, and one click on the Status column sorts it worst-first, so a failure comes to the top row. This page is the path from seeing that row to a clean rerun.
What a failure means for your data
A failed run recorded no archive: its history row carries no run id, so there is nothing to restore from it. Your previous backups are untouched and remain restorable; what you have lost is one scheduled capture, and the recovery point moves back to the last clean run until a rerun succeeds. The failed row stays in the run history until it ages out, because the history keeps the latest 50 runs per downpipe for up to 400 days.
Reading the verdict
Open the failed run’s row. The drawer shows the failure verdict: a coarse, recoverable reason in plain words, never a stack trace. Most reasons name which side failed, which is the first fork in any diagnosis:
- A destination reason (a refused write, a denied list, an unreachable endpoint) means your source is fine and the archive location is not. The primary copy of earlier runs is unaffected; the fix is on the bucket or its policy.
- A source reason (a rate limit, a read that vanished mid-crawl, a detached binding) means the destination is fine and the engine could not read what it came to back up.
The full vocabulary of run failure reasons, with the remedy for each, is in the troubleshooting reference. Binding drift, the source-side cause with its own machinery, has its own page.
Fix, then rerun
The way out of a failed run is on the drawer itself: Open the downpipe, because the commonest day-two action on a failure is to fix the cause and run it again, and Run now lives on the downpipe. Fix what the reason named first: a rerun into the same refusal produces the same red row.
The Runs view does not poll in the background by design, so refresh it to watch the fresh run move from in-flight to ok. A clean rerun settles over the failure and your recovery point catches up; the failed row remains below it in history.
When a rerun is not enough
A failure that repeats after its cause looks fixed, or a reason you cannot action, is what the support bundle exists for: Settings, then Download support bundle attaches the redaction-safe diagnostic trail to your ticket. The bundle never contains a key, a secret value or your data. The run drawer also shows a Support reference. Quote it in the ticket, because it joins the failed run to the engine’s log line. If the failure arrived with an alert, the notifications rules decide who hears about the next one; if it did not, that is worth fixing while the incident is fresh.
Last updated .