Roll Back a QCBM Recovery Safely

If QCBM recovery fails after it has begun changing files or database state, use the Recovery Runner's own Roll Back Recovery workflow when it is offered. The runner uses protected rollback data and its recovery journal to reverse supported changes in the correct order.

Do not try to perform a manual rollback by deleting staging folders or copying files at random while QCBM still has an active recovery operation.

When Rollback Is Available

Rollback is offered only when the current recovery operation has protected state that can be restored. The progress view exposes Roll Back Recovery when QCBM knows rollback is available for that operation.

If no rollback action is offered, preserve the current state and review the Recovery Report/current report before making manual changes.

What QCBM Protects During Recovery

Depending on the selected recovery strategy, QCBM can retain previous destination files, original configuration data, clean-destination content, and protected database rollback SQL. The protected workspace is outside the active site path where possible.

Those materials are tied to the operation journal. Keep them intact until you have either completed recovery successfully or completed rollback.

Start Rollback from the Runner

1. Read the recovery failure message and confirm you do not want to retry the failed step first.
2. Select Roll Back Recovery.
3. Allow QCBM to process the rollback stages without closing the operation or deleting recovery files.
4. If rollback itself pauses, reopen the same runner and resume the rollback workflow.

What File Rollback Does

QCBM records file changes as recovery proceeds. During rollback it works backward through those records, restoring protected previous files where they existed and removing files that recovery created when the destination did not previously contain them.

It also restores recorded directory metadata and the original configuration.php state when that information was protected by the operation.

What Database Rollback Does

For destructive database strategies, QCBM creates protected pre-recovery SQL before cleanup. Rollback can use that SQL to restore the original protected database scope.

Because database rollback may itself be staged, let the runner complete it rather than importing fragments manually while the operation is active.

Clean-Destination Rollback

If clean-destination file recovery moved existing destination content into protected rollback storage, QCBM can restore that content as part of rollback. Do not manually move those protected files back while the runner is still tracking the operation.

After Rollback

Confirm that the runner reports rollback completion, then inspect the Joomla frontend, administrator, filesystem, and database state. Download the available report so you have a record of the original recovery failure and rollback outcome.

Before trying recovery again, correct the cause of the failure—such as insufficient disk space, database permissions, bad credentials, a path/server-control problem, or incompatible destination conditions.

Rollback Is Not a Substitute for a Destination Backup

QCBM rollback is a recovery safety feature, not your only disaster plan. Preserve important destination data independently before using destructive file or database options.

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.