Understand QCBM Receiver Resumable Downloads, Verification, and Deduplication

QCBM Receiver is designed to move large Recovery Packages without treating an interrupted transfer as a successful backup. It keeps transfer state, resumes its managed partial file when possible, and independently verifies the finished package before acknowledging it to QCBM.

That verification and receipt process is also what prevents a paired Receiver from unnecessarily downloading the same completed Recovery Package again.

QCBM Supplies Authoritative Package Metadata

Receiver only accepts a Recovery Package inventory item with a valid backup identifier, filename, positive size, SHA-256 value, and the expected Recovery Package artifact type. The expected size and SHA-256 come from QCBM's verified package record.

Those values give Receiver something concrete to verify after transfer; the download is not trusted merely because the HTTP request finished.

Interrupted Downloads Use a Managed Partial File

Receiver downloads to the configured destination using the final filename plus a .partial suffix. If that Receiver-owned partial file already contains part of the expected package, Receiver can continue with an HTTP Range request instead of starting from byte zero.

If the partial file has already reached the expected total size, Receiver verifies it directly rather than making an invalid range request. An oversized or unsafe partial cannot simply be accepted as the package.

Pause, Resume, and Cancel Are Different

A paused transfer keeps its Receiver-managed state so it can be resumed. Cancel removes only the Receiver-owned partial file after validating that it is the expected transfer path.

Canceling a Windows transfer does not delete the canonical Recovery Package from the Joomla server. It stops that local attempt; the server copy remains available according to QCBM's own state and retention.

The Finished File Must Pass Two Checks

After all bytes arrive, Receiver first checks the exact file size, then computes SHA-256 and compares it with QCBM's authoritative hash. Only a match is promoted from the partial path to the final local package.

If size or SHA-256 does not match, the package is not acknowledged as verified. This protects against truncated, altered, or otherwise invalid transfers.

Receiver Does Not Overwrite an Unrelated Final File

If a file already exists at the intended final filename, Receiver checks whether it exactly matches the expected size and SHA-256. An exact match can be treated as the already-present canonical package and acknowledged without downloading it again.

If the existing file does not match, Receiver does not silently overwrite it as though it belonged to the current transfer. Resolve the filename/path conflict instead of assuming the local file is safe.

Verified Receipts Suppress Duplicate Collection

After local verification, Receiver acknowledges the backup UID, size, and SHA-256 to QCBM. QCBM verifies the acknowledgement and records the receipt for that paired device.

That receipt allows QCBM to omit a package the same device has already verified. The local exact-file check provides an additional path to avoid needless re-transfer when the correct package is already present.

Local Retention Runs After Verified Custody

Receiver catalogs a backup for its managed local-retention system only after the package has passed the custody/verification flow. Age, count, and storage-cap rules therefore operate on verified Receiver-managed backups rather than arbitrary files in the destination.

Delete-After Is Gated by Verification

If Delete hosting copy after Receiver verifies the download is enabled, the delete request is part of the verified acknowledgement. QCBM checks the receipt details before the server copy can be removed. A partial or unverified Windows file is not enough to authorize that deletion.

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.