Troubleshoot QCBM Recovery Runner Warnings and Failures
The Recovery Runner is designed to stop or warn before unsafe work continues. Treat the exact message as evidence: preserve the package and protected recovery state, then fix the failed dependency rather than bypassing the check.
Use the runner's built-in verify, test, retry, resume, and rollback controls. Manual deletion of journal/staging files can make a recoverable situation harder to diagnose.
This Connection Is Not Encrypted
If the runner says This connection is not encrypted, the browser session is using HTTP. Recovery can continue, but the Recovery PIN and database details could be exposed in transit.
Use HTTPS whenever it is available. On a new destination where TLS is not ready yet, minimize exposure and correct HTTPS as part of the destination setup.
Verify Backup Fails
A verification failure means a required backup part is missing, unreadable, the wrong size, has incomplete manifest metadata, or does not match the recorded SHA-256 value.
Do not recover from that package. Recopy a known-good complete Recovery Package from trusted storage and run Verify Backup again.
Test Locked Destination Fails
Common causes include the runner being in the wrong directory, PHP lacking write access, or insufficient estimated free space for staging/rollback/restored files.
Move the complete package to the intended Joomla root or correct permissions/storage. Do not try to type another target path because the root is physically locked to qcbm-recover.php.
Test Database Fails
Check host/port/socket, database name, username/password, TLS settings, privileges, table prefix, and the selected database strategy. The test deliberately rejects an existing empty strategy when objects exist and an unused prefix strategy when the prefix already collides.
If Create this database if permitted fails privilege checks, create the database in the hosting control panel and switch to an existing-database strategy.
Recovery Pauses or a Step Fails
Read the exact phase/message. Correct external conditions such as free space, permissions, database availability, or server limits, then use Retry Last Step when available.
If the browser/session was interrupted, reopen the same runner, unlock it, re-enter required secrets, and use Resume Recovery.
When to Roll Back
If continuing is unsafe and Roll Back Recovery is offered, use it. QCBM uses its protected file/database/configuration state and journal to reverse supported changes.
Do not confuse this with scheduled-backup retry timing; Recovery Runner retry/rollback is an interactive recovery workflow.
Recovery Completes but Joomla Does Not Load
Review the recovery summary/report and check configuration.php database settings/prefix, Force HTTPS, cookie domain/path, tmp/log paths, PHP version/extensions, and server-control files.
On a moved site, pay special attention to source .htaccess rules, RewriteBase, redirects, PHP handlers, and path-specific directives. Use the QCBM Needs Attention review rather than activating old rules blindly.
Administrator Will Not Open
Remember that the site's normal administrator protection still applies. An IP restriction, WAF, secret parameter, or external admin gate can make the standard /administrator/ URL appear unavailable even when Joomla itself recovered correctly.
Preserve Evidence Before Making Manual Changes
- Keep the original Recovery Package.
- Keep the protected recovery journal/workspace intact.
- Download the current/final Recovery Report when available.
- Record the exact error and recovery phase.
- Check hosting/PHP/Joomla logs for correlated errors.
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.