Troubleshoot QCBM Receiver Pairing and Downloads

Troubleshoot QCBM Receiver by separating the workflow into four stages: pairing, authenticated polling, destination/transfer, and final verification/acknowledgement. The message and state at the failed stage usually identify the correct fix.

Do not delete partial files, server Recovery Packages, or paired-device records at random. Receiver deliberately preserves state so interrupted transfers and trust failures can be diagnosed safely.

Pairing Code Is Rejected

Confirm the Joomla URL uses https:// and that QCBM currently has Max or All Access. A pairing code is valid for 15 minutes and can be used once. If it expired or was already consumed, generate a fresh code in Settings → QCBM Receiver.

Also confirm the Receiver destination is valid and writable. Receiver validates the destination before it completes the local connection setup.

Pairing Succeeds on Joomla but Receiver Cannot Save It

Receiver protects its device secret using Windows machine-level protection and must save the site connection locally. If that local save fails after QCBM consumed the one-time code, Receiver makes a best-effort remote revoke of the temporary device and asks you to generate a new code.

Correct the Windows permissions/configuration problem first, then pair again with a new code.

An Existing Connection Suddenly Cannot Poll

Open QCBM's Paired Receivers list and confirm the intended device is still active. A revoked or invalid device credential receives authentication failure and cannot poll or download.

Confirm the saved site URL still points to the intended HTTPS Joomla installation. If the site was migrated to a genuinely different host/location, use a fresh pairing rather than assuming the old trust should follow automatically.

A Recent Backup Does Not Appear in Receiver

Receiver is offered only completed QCBM Backup Sets whose canonical Recovery Package is still present, readable, managed, and marked verified. An in-progress, failed, unverified, missing, or already-receipted package will not be offered as a new download.

Current QCBM serves the newest currently available eligible Recovery Package to a device; it does not backfill every older retained package merely because a Receiver was newly paired or came back online. Check QCBM Backup History for the package you expect and its verification state.

Receiver Is Not Starting a Due Backup on a Quiet Site

Confirm the Backup Profile is published and actually due, scheduled backups are enabled in QCBM Settings, the current entitlement allows scheduling, and the paired Receiver is polling successfully. Receiver assistance is limited to QCBM's own scheduled backup engine.

If a manual persistent backup is already active, Receiver waits rather than taking it over or starting a competing scheduled Backup Set.

Download Stops or Repeats

Check that the destination is still available to the Windows service and has adequate free space. Receiver keeps its own .partial transfer file and normally resumes an interrupted download with HTTP Range requests.

If a resumed request is rejected by the web server or intermediary, review that HTTP/proxy behavior. Use Receiver's pause/resume/cancel controls rather than manually renaming or replacing the managed partial while the transfer is active.

Receiver Reports a Size or SHA-256 Mismatch

The local copy is not trusted. Receiver requires both the expected byte count and the authoritative SHA-256. A mismatch can indicate an interrupted/corrupted transfer or a file that does not correspond to QCBM's current canonical package.

Do not enable manual server-copy deletion as a workaround. Preserve the QCBM package, correct the transfer/storage problem, and obtain a clean verified copy.

The Final Filename Already Exists

If the existing final file exactly matches QCBM's expected size and SHA-256, Receiver can acknowledge that package without downloading it again. If it does not match, Receiver refuses to silently overwrite it; a newly verified partial can be preserved while the conflict is reported.

Determine what the existing file is and move it safely out of the way only when you are certain it is not a required backup.

The Local Copy Verified but the Hosting Copy Was Not Deleted

If delete-after is enabled, QCBM attempts managed Backup Set deletion only after it accepts the verified Receiver receipt. Another QCBM operation can temporarily lock the backup, or managed deletion can fail. In those cases the server copy is kept and QCBM records the deletion result.

The verified Windows copy remains valid; diagnose the server-side deletion message separately.

Confirm Recovery Readiness, Not Just Download Status

For ongoing operations, periodically confirm that a recent package is present in the intended destination, Receiver reports successful verification, and QCBM records current Receiver contact. A downloaded filename by itself is not the same as verified recovery custody.

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.