Verify a QCBM Backup Set

A backup job can finish successfully and still need an integrity check before you trust it as a recovery point. QC Backup Manager therefore separates completion from verification.

Verification rechecks the stored Backup Set and Recovery Package information so you know the files QCBM expects are still present and still match the recorded metadata.

Completed Does Not Mean Verified

A completed job means the backup workflow reached its final processing stage. Verification adds another question: does the stored recovery material still match what QCBM recorded when the Backup Set was created?

That distinction matters because files can be deleted, truncated, moved, changed outside QCBM, or damaged after a job originally completed.

What QCBM Verification Checks

The exact checks depend on the Backup Set, but verification can include:

  • the expected archive or package files are present;
  • the manifest exists;
  • recorded file sizes match the stored files;
  • SHA-256 checksums match the recorded values;
  • all required split archive parts are present when split archives are used;
  • the canonical Recovery Package is complete and associated with the correct Backup Set.

QCBM uses verification information for more than display. Off-site export and recovery readiness depend on having a complete, trusted Backup Set.

Verify a Backup Set from Backup History

  1. Open Components > QC Backup Manager > Backups.
  2. Locate the Backup Set under Backup History.
  3. Open its available actions.
  4. Click Verify.
  5. Allow QCBM to complete the integrity checks.
  6. Confirm the Backup Set returns to a verified state without missing-file, size, manifest, or checksum errors.

Verification is designed to test the stored recovery material, not simply trust a status flag from the original run.

When to Verify Again

Re-verification is especially useful:

  • before using an older Backup Set for recovery;
  • after moving Managed Private Storage;
  • after copying or handling backup files outside the normal QCBM workflow;
  • when Backup History reports a package or integrity warning;
  • before deleting the only other known copy of an important recovery point;
  • before relying on a package that has been retained for a long time.

Understand Split-Archive Verification

Large QCBM backups can use split archive parts. A Backup Set is not complete merely because one part exists. Verification checks the required parts and their recorded information so a missing or altered segment is detected before recovery.

Do not rename or selectively remove split parts outside QCBM because they appear old or redundant. The Recovery Package and manifest define which pieces belong to that Backup Set.

What a Checksum Mismatch Means

A checksum is a fingerprint of file content. If the current SHA-256 value no longer matches the recorded value, the file is not byte-for-byte identical to what QCBM expected.

A mismatch can result from corruption, incomplete transfer, manual modification, or another storage problem. The safe response is not to ignore the warning. Treat the affected recovery material as unverified until you understand the cause or replace it with a fresh verified Backup Set.

What to Do If Verification Fails

  1. Do not start recovery from the failed package.
  2. Read the exact verification message.
  3. Confirm the expected package, manifest, and archive parts still exist.
  4. Check whether files were moved, renamed, or changed outside QCBM.
  5. Review storage health and available disk space.
  6. If the live site is healthy, create a fresh Backup Set and verify it.
  7. If another independently verified copy exists, protect that copy while you investigate the failed one.

Verification and Off-Site Export

QCBM's off-site workflow is designed around verified Backup Sets. The local backup completes and verifies first; remote export occurs afterward.

Remote destinations can also perform their own transfer verification depending on the provider. That remote check does not make an unverified local source trustworthy. Start with a verified source Backup Set.

Verification and QCBM Receiver

QCBM Receiver is designed to pull canonical verified Recovery Packages. Receiver then performs independent size/checksum verification of the downloaded copy. This gives you two separate checkpoints: the server-side package was verified before delivery, and the Receiver confirms what it actually stored.

Verification Does Not Replace Recovery Testing

Integrity verification answers whether the files match their recorded backup information. It does not prove that every application-level dependency, hosting difference, credential, or server rule will behave exactly as expected during a real restore.

For important Joomla sites, periodically test a Recovery Package on a disposable or staging destination. A verified package plus a proven recovery process provides stronger evidence than either one alone.

Before You Rely on a Backup Set

  • Status is complete.
  • Verification passes.
  • The Recovery Package is available.
  • The Recovery PIN is recorded.
  • An independent copy exists for critical production sites.
  • Your team knows how to start the Recovery Runner.

Community Discussion

Want to discuss verification practices or recovery testing with other administrators? Visit the QC Backup Manager Community. For private support, bug reports, or feature requests, use the QuantaCade support system.