Test QCBM Backup Storage for Direct Web Access

QC Backup Manager protects backup storage differently depending on where the managed folder lives. Storage outside the public Joomla document root has no normal website URL. Compatibility storage inside the Joomla installation must instead be protected by web-server denial rules.

The Run Direct URL Test control on QCBM's Status page checks that protection. Use it whenever Compatibility storage is active, after a hosting or web-server change, or when QCBM reports a storage-protection warning.

Where to Run the Test

Open Components > QC Backup Manager > Status and find the Storage Health card. The card shows the configured path, QCBM's storage-health message, the last Direct URL test status, and the time of the most recent test.

If your Joomla account has permission to manage QCBM settings, click Run Direct URL Test. QCBM first confirms that it can create, write, flush, read, rename, and delete a temporary file in Managed Private Storage. It also makes sure the storage-protection files are present.

What QCBM Tests

When the active storage folder is outside the Joomla document root, QCBM reports the test as passed because that folder has no direct website URL.

When the folder is inside the document root, QCBM creates a short-lived probe file containing a random token and requests that file through the site's public URL. The probe is deleted after the test.

QCBM installs both Apache and IIS protection files in managed storage. The live probe checks whether the active web server actually prevents the private file from being returned.

How to Read the Result

  • Passed: the storage is outside the public document root, or the active web server denied the probe with a protective response such as HTTP 401, 403, 404, or 410.
  • Configured: protection files are present and the probe contents were not exposed, but QCBM could not obtain a conclusive live denial. This can happen when PHP has neither cURL nor URL streams available, or when the web request ends in an inconclusive response.
  • Failed: QCBM could not perform the required filesystem checks, could not create the probe, or the public URL returned the probe token. A failed direct-access check means QCBM will not treat that web-accessible folder as safe for new Backup Sets.

A Configured result is not the same as a confirmed live denial. Review it again after changing the server configuration or enabling a supported PHP HTTP method.

If the Test Fails

  1. Read the exact Storage Health message. It identifies whether the failure is a filesystem problem or a direct-web-access problem.
  2. Do not solve the warning by manually moving QCBM folders with FTP, a hosting file manager, or SSH. That can separate QCBM's database paths from its managed files.
  3. If the server can support private account-level storage, use Settings > Advanced Storage Tools > Move Backup Storage to move the complete managed store to a dedicated outside-webroot folder.
  4. If Compatibility storage must remain in use, correct the web-server protection problem and run Run Direct URL Test again.
  5. After the result is healthy, create a controlled Backup Set and verify it before relying on the storage for important recovery points.

Why This Matters

A Backup Set can contain database data, configuration details, site files, and a Recovery Package. Obscure folder names do not make those files private. The direct-access test verifies that a browser cannot simply fetch a protected storage file through the Joomla site's URL.

For additional resilience, keep at least one verified Recovery Package away from the Joomla hosting account. Web-access protection reduces one class of exposure; it does not protect against total hosting-account or server loss.

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.