Read QCBM Backup Failure Details and Diagnostics

When a QCBM Backup Set fails, the useful question is not just whether the status says failed. QCBM records the phase, human-readable failure message, and—when available—structured failure context so you can identify whether the problem came from preflight, database/archive work, verification, storage, a lock, remote cleanup, or another stage.

Capture that evidence before retrying. A blind retry can replace the visible context with a new result without fixing the underlying dependency.

Start with Backup History

  1. Open Components > QC Backup Manager > Backups.
  2. Locate the failed or warning Backup Set.
  3. Read the Needs attention or Review finding area.
  4. Record the failure message and the displayed failed phase.
  5. If View Failure Details is available, open it and preserve the structured context before making changes.

Understand the Failure Phase

The failure phase identifies where QCBM was working when the problem became final. Current backup flows can record phases such as preflight, database dump, archive/package work, verification, cancellation, scheduler preflight, or remote deletion/cleanup contexts.

The exact phase narrows the troubleshooting scope. A preflight disk-space failure should not be investigated like a package checksum mismatch, and neither should be treated like an SFTP or OAuth export failure.

Read the Human-Readable Message First

QCBM stores a failure message on the Backup Set and surfaces it in Backup History. This message often contains the immediately actionable condition: missing archive support, insufficient storage, an active operation lock, unreadable files, verification mismatch, or another specific dependency.

Do not reduce that message to a generic “backup failed” support note. Preserve the actual wording and phase.

Use View Failure Details for Structured Context

When QCBM stored failure_context_json, Backup History can expose it under View Failure Details. That context is intended to preserve relevant diagnostics from the failed operation rather than forcing the administrator to reconstruct conditions from memory.

Copy only the information needed for troubleshooting and handle paths/server details according to your site's support/security policy.

Check Active Jobs and Locks Before Retrying

A browser timeout does not prove the persistent server-side job failed. QCBM can continue large manual/scheduled Backup Sets through bounded background checkpoints.

Before starting another Backup Set, confirm whether an existing job is still queued/running, paused, postponed, cancelling, or waiting for continuation. If the failure mentions another QCBM operation or lock, identify the owning operation rather than repeatedly clicking Create/Run Now.

Check Storage and Verification Evidence

If the failure involves package integrity, inspect the Backup Set's stored files and run QCBM verification when the set is complete enough to permit it. QCBM verification checks the expected package/parts, manifest, recorded sizes, and SHA-256 checksums.

For storage failures, also review Status for Managed Private Storage health, direct-URL protection when compatibility storage is used, and available-space/preflight results.

Scheduled Failure Diagnostics

For scheduled runs, compare the failed Backup History/Backup Log record with the Profile's schedule, scheduled occurrence, retry wait, and the Scheduled Backups task's last result. QCBM deliberately prevents rapid repeat attempts for the same failed occurrence within the configured retry window.

If the scheduler task itself is not running, correcting the Profile will not fix the underlying automation problem.

Use the Permanent Backup Log for Historical Failures

Download Backup Log retains the run's status, verification state, failure phase/message, schedule context, and timestamps in the permanent run ledger. This is especially valuable after age-limited operational logs/jobs have been cleaned.

Retry One Controlled Time

After correcting the identified cause, run one controlled retry. Compare its new phase/result with the original evidence. If the same failure repeats, preserve both records and troubleshoot the dependency directly rather than creating many duplicate Backup Sets.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCBM feature? Visit the QC Backup Manager Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.