Download a QCBM Recovery Package

A QC Backup Manager Recovery Package is the portable recovery artifact produced for a completed, verified Backup Set. It is designed to contain the standalone Recovery Runner, recovery instructions, manifest, and the database and/or file backup data required by that Backup Set.

Keeping a Recovery Package somewhere separate from the Joomla server is one of the most important steps in turning a successful backup job into a usable disaster-recovery plan.

What Makes the Recovery Package Different from a Backup File

The Recovery Package is not just an archive of site data. QCBM prepares a package around the Backup Set so the recovery workflow travels with the recovery material.

A package can include:

  • the standalone qcbm-recover.php Recovery Runner;
  • plain-language recovery instructions;
  • the Backup Set manifest;
  • the required database and/or filesystem backup parts;
  • metadata the Recovery Runner uses to verify the package before recovery begins.

The package corresponds to one specific Backup Set and uses the Recovery PIN assigned when that Backup Set was created.

Download a Recovery Package

  1. Open Components > QC Backup Manager > Backups.
  2. Locate a complete, verified Backup Set in Backup History.
  3. If you are unsure about an older Backup Set, run Verify first.
  4. Click Download.
  5. Save the Recovery Package ZIP to a location separate from the Joomla server.
  6. Record the four-digit Recovery PIN associated with that Backup Set.

If the download is intended for long-term disaster recovery, do not leave the only copy in the browser's Downloads folder on a workstation that is not itself backed up.

Where to Store Recovery Packages

Good storage choices depend on the site's importance and your organization, but common examples include:

  • an encrypted workstation or local backup archive;
  • an external drive kept separately from the server;
  • a protected NAS repository;
  • a separate cloud account or storage provider;
  • a separate server or hosting account;
  • QCBM Receiver storage on a Windows system, external drive, or NAS for eligible Max/All Access workflows.

For critical production sites, keep more than one independent recovery path. A single remote location can fail, lose access, or be affected by the same account compromise as the production site.

Protect the Recovery Package as Sensitive Data

A Full Recovery Package can contain the Joomla database, configuration, extension files, templates, and private site data. Treat it like a privileged system backup.

  • Restrict who can read or copy the package.
  • Do not place it in a publicly accessible web directory.
  • Protect the Recovery PIN separately enough that unauthorized users cannot casually obtain both.
  • Use encryption or access-controlled storage where appropriate for your data.

Record the Correct Recovery PIN

The Recovery Package keeps the PIN assigned when its Backup Set was created. Changing the current QCBM Recovery PIN later does not change an older package.

If you rotate the site Recovery PIN, create a new Backup Set and Recovery Package if you need a current recovery artifact protected by the new value.

Read the Recovery Instructions Before an Emergency

Do not wait for a production outage to see the Recovery Runner for the first time. Extract a copy of a Recovery Package in a safe environment, read the included instructions, and understand what credentials and hosting access you will need.

A normal recovery can require:

  • the Recovery Package and its PIN;
  • access to the target Joomla root;
  • target database credentials and grants;
  • a supported PHP/server environment;
  • the ability to confirm frontend and administrator routing after recovery.

Test Recovery on a Disposable or Staging Destination

The strongest way to prove a Recovery Package is useful is to recover it in a non-production location. A test can reveal environment-specific issues such as database permissions, path differences, .htaccess behavior, PHP differences, or server-control rules while the original production site is still healthy.

For an other-location recovery, QCBM's Recovery Runner can guide the destination setup and update Joomla configuration values needed for the target environment.

Do Not Start Recovery from an Unverified Package

If the source Backup Set cannot be verified, do not treat its Recovery Package as the preferred recovery point. A missing part, size mismatch, or checksum mismatch means the package is not in the state QCBM expected.

If the live site is still available, create a fresh verified Backup Set. If the site is already down, protect every existing copy and use the Recovery Runner's validation information before making destructive decisions.

How QCBM Version Affects the Package

A Recovery Package embeds the Recovery Runner available when that Backup Set is prepared. Updating QCBM improves packages created afterward; it does not silently rewrite Recovery Packages you already downloaded.

For long-lived production sites, periodically create a fresh verified Recovery Package after meaningful QCBM updates rather than keeping one ancient package as the only recovery plan.

Recovery Package Checklist

  • The Backup Set completed successfully.
  • The Backup Set verifies without integrity errors.
  • The Recovery Package downloads successfully.
  • The associated Recovery PIN is recorded securely.
  • At least one copy is stored away from the Joomla server.
  • The recovery instructions have been reviewed.
  • A test recovery has been performed for important production sites.

Community Discussion

Want to compare Recovery Package storage or disaster-recovery practices? Visit the QC Backup Manager Community. Do not post Recovery Packages or Recovery PINs publicly. For private support, bug reports, or feature requests, use the QuantaCade support system.