Troubleshoot QCBM Archive Creation Failures

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

This guide focuses on Free space, PHP limits, archive support, split size, exclusions, unreadable files, logs. The feature context for this article is All plans. 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.

Free space, PHP limits, archive support, split size, exclusions, unreadable f...

Archive and split settings control how QCBM packages site data for storage and recovery. The Auto choice is the safest starting point unless you have measured hosting or transfer constraints that require a custom strategy.

Split ZIP parts are useful when a large archive would be awkward to create or transfer as one file. Every required part belongs to the Backup Set and must remain available for verification and recovery.

Use a Narrow Diagnostic Loop

For Troubleshoot QCBM Archive Creation Failures, 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.

Practical Troubleshooting Sequence for This Problem

Start with the symptom named in Troubleshoot QCBM Archive Creation Failures and work outward. First decide whether the failure occurs before QCBM starts the operation, while QCBM is processing it, or after QCBM hands work to another subsystem such as Joomla Scheduled Tasks, mail, a cloud provider, the Recovery Runner, or Receiver.

  1. Reproduce the smallest safe version of the problem once and capture the exact message.
  2. Check the owning QCBM Status card or history record.
  3. Verify entitlement and Joomla ACL only if the control itself is unavailable.
  4. Verify environment dependencies such as storage, PHP support, network access, mail, provider permissions, or Windows/NAS permissions according to the feature.
  5. Correct one dependency and repeat the same test.
  6. If the failure remains, keep the original and new evidence so support can see what changed.

A controlled diagnostic sequence is safer than deleting QCBM data, reinstalling the extension, or rotating several credentials at once.

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.