Troubleshoot When QCBM Receiver Cannot See a Recent Recovery Package

This article uses QCBM's Status, history, and readiness information to isolate a specific failure instead of changing unrelated settings.

This guide focuses on Backup Set complete; canonical Recovery Package verified; paired device active; URL/host identity; one leading www normalization; unrelated subdomains separate. The feature context for this article is Max / All Access. Use the current QCBM 1.5.13 interface and the site’s actual Status information as the authority when a saved setting or entitlement differs from an older workflow.

Before You Begin

Record the exact error or warning first. Note the QCBM version, effective tier, domain/installation identity, recent job result, and any relevant Status card before attempting repairs.

How to Work Through This Task

  1. Capture the exact QCBM warning or failure before changing anything.
  2. Open the relevant Status/readiness card, Backup History record, destination test, or Recovery/Receiver record.
  3. Check the dependencies named in this guide one at a time.
  4. Make one corrective change.
  5. Rerun the smallest relevant test and confirm the original condition is resolved.

Backup Set complete

Backup Set complete is one of the diagnostic factors that can explain Troubleshoot When QCBM Receiver Cannot See a Recent Recovery Package. Check it directly rather than changing unrelated configuration, and record the result before moving to the next dependency.

Troubleshooting is most reliable when one variable is changed at a time and the same small test is repeated after each change.

Canonical Recovery Package verified

canonical Recovery Package verified is one of the diagnostic factors that can explain Troubleshoot When QCBM Receiver Cannot See a Recent Recovery Package. Check it directly rather than changing unrelated configuration, and record the result before moving to the next dependency.

Troubleshooting is most reliable when one variable is changed at a time and the same small test is repeated after each change.

Paired device active

paired device active is one of the diagnostic factors that can explain Troubleshoot When QCBM Receiver Cannot See a Recent Recovery Package. Check it directly rather than changing unrelated configuration, and record the result before moving to the next dependency.

Troubleshooting is most reliable when one variable is changed at a time and the same small test is repeated after each change.

URL/host identity

URL/host identity is one of the diagnostic factors that can explain Troubleshoot When QCBM Receiver Cannot See a Recent Recovery Package. Check it directly rather than changing unrelated configuration, and record the result before moving to the next dependency.

Troubleshooting is most reliable when one variable is changed at a time and the same small test is repeated after each change.

One leading www normalization

Receiver site matching allows the expected host identity, including limited normalization such as one leading www. An unrelated subdomain is still a different site identity and should not be assumed to match the pairing.

Unrelated subdomains separate

Receiver site matching allows the expected host identity, including limited normalization such as one leading www. An unrelated subdomain is still a different site identity and should not be assumed to match the pairing.

Use a Narrow Diagnostic Loop

For Troubleshoot When QCBM Receiver Cannot See a Recent Recovery Package, avoid the temptation to “reset everything.” QCBM exposes separate evidence for entitlement, storage, scheduler tasks, Backup Sets, exports, email, recovery, and Receiver so you can identify the owning subsystem first.

Capture the original message, test one dependency, change one thing, and rerun the same test. If the result changes, you know which correction mattered; if it does not, you still have the original evidence for the next step.

Information to Capture Before Escalating

  • Exact error/warning text and when it occurred.
  • QCBM, Joomla, and PHP versions.
  • Effective tier and relevant Status card state.
  • Backup/Profile/destination/Receiver record involved.
  • Last task result when scheduling is involved.
  • Whether the problem is reproducible with the smallest relevant test.
  • What changed immediately before the failure began.

Verify the Result

After each corrective action, rerun the smallest relevant test and confirm the original warning is gone. Avoid stacking multiple changes at once because that makes the successful fix impossible to identify.

Common Mistakes to Avoid

  • Reinstalling QCBM before reading the actual failure state.
  • Clearing or deleting working data before an active job is understood.
  • Changing credentials, paths, and task schedules all at once.
  • Assuming every disabled control is an extension bug rather than entitlement or Joomla ACL.

Operational Best Practice

Use a narrow troubleshooting loop: identify the failing subsystem, test one dependency, change one thing, retest, and keep a known-good Recovery Package before any repair that could affect production data.

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.