Delete Hosting Copies After Verified QCBM Receiver Downloads

QCBM Receiver can ask QC Backup Manager to delete the hosting copy of a Recovery Package after Receiver has independently verified the local download. This is optional and should be used only when your backup-retention plan intentionally relies on the verified Receiver copy.

The safety boundary is important: Receiver does not request deletion when a transfer merely starts or reaches 100%. QCBM first requires an acknowledgement whose file size and SHA-256 exactly match the canonical Recovery Package.

Enable Delete-After on the Receiver Connection

Edit the Joomla site connection in QCBM Receiver and enable Delete hosting copy after Receiver verifies the download. This setting is stored with that Receiver connection and is sent to QCBM only when Receiver acknowledges a verified package.

Leave the option off if you want normal QCBM hosting retention to keep server-side copies independently of Receiver.

What Must Happen Before Deletion Is Requested

  1. QCBM must have a completed Backup Set with one canonical verified Recovery Package.
  2. Receiver downloads that package to its configured Windows destination.
  3. Receiver verifies the exact expected file size.
  4. Receiver computes SHA-256 and matches it to QCBM's authoritative checksum.
  5. Receiver acknowledges the backup UID, verified size, and SHA-256 to QCBM with the delete-after choice.

An incomplete .partial file, an unverified final file, or a mismatched checksum cannot satisfy this acknowledgement.

QCBM Verifies the Receipt Again

QCBM looks up the same Recovery Package and compares the Receiver-reported size and SHA-256 with its own persisted verified metadata. If either value differs, acknowledgement is rejected with a verification mismatch and the hosting copy is not deleted.

When the values match, QCBM records a verified Receiver receipt for that paired device before it attempts the optional delete.

Deletion Can Still Be Deferred or Fail

A verified receipt does not mean deletion is guaranteed. QCBM acquires its normal operation lock and uses the managed Backup Set deletion path. If another QCBM operation currently locks that backup, or the managed deletion itself fails, the server copy is kept and the receipt records the deletion result.

This is safer than treating delete-after as an unconditional remote file removal. Review the Receiver/QCBM status if hosting storage did not decrease as expected.

Plan Local Retention Before Removing Hosting Copies

Receiver local retention is independent of QCBM hosting retention. If delete-after is enabled, make sure the Receiver destination is reliable and that its age/count/storage limits retain the number of local copies you actually need.

Receiver's managed retention preserves the newest successfully verified local backup, but a sound recovery plan should still consider disk failure, accidental manual deletion, ransomware, and whether another independent copy is appropriate.

Verify the Result

After a known-good Receiver download, confirm the package exists at the expected Windows destination and that Receiver reports successful verification. Then check QCBM Backup History/status to confirm whether the delete request was completed or the hosting copy was kept.

If deletion failed, do not delete the server file manually just to make the status look clean. Correct the reported lock/storage issue and keep at least one verified recovery copy under deliberate 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.