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 worst-first, so a failure is the first row an operator sees, never buried under a page of green. This page is the path from seeing that row to a clean rerun.
What a failure means for your data
A failed run wrote no partial archive. 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 history permanently: it is an honest record, and the audit trail of an estate that handles its failures well.
Reading the verdict
Open the failed run’s row and the drawer shows the failure verdict: a coarse, recoverable reason in plain words, never a stack trace. The reason names 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 Running to done. A clean rerun settles over the failure and your recovery point catches up; the failed row remains below it in history, which is exactly how it should read.
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. 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 .