Understand QCBM Compatibility Storage and Storage Warnings
QC Backup Manager prefers Managed Private Storage outside the public Joomla document root. Some hosting environments prevent QCBM from creating or using that account-level location, so QCBM can fall back to a protected folder inside the Joomla installation.
QCBM calls that fallback Compatibility storage. Backups can continue there when the folder passes QCBM's filesystem and direct-access protection checks, but it is not equivalent to an outside-webroot location and some operations remain intentionally restricted.
When Compatibility Storage Is Used
QCBM can activate Compatibility storage when the configured private-storage path cannot be used because of conditions such as an invalid path, open_basedir restrictions, an inaccessible parent directory, insufficient filesystem permissions, or failed create/read/rename/delete checks.
The compatibility folder is QCBM's protected component storage under the Joomla administrator tree. QCBM records why the fallback occurred and changes its split-archive staging location so that backup work remains inside the managed compatibility area.
How QCBM Protects It
Compatibility storage receives QCBM-managed .htaccess, web.config, and index.html protection files plus an ownership marker. QCBM also runs or records a Direct URL protection check.
A healthy Compatibility result means the filesystem operations succeeded and the public probe was denied or at least not exposed. If QCBM proves that a private probe file can be downloaded through the website, it treats the storage as unsafe and will not continue storing new Backup Sets there.
What the Status Warnings Mean
On Status > Storage Health, an outside-webroot path is reported as outside the public document root. Compatibility storage is identified separately so you know that the active path lives under Joomla and depends on web-server protection.
Pay attention to these conditions:
- Writable/access warnings: QCBM cannot reliably create, read, rename, or remove its test files.
- Direct URL failed: the active web server exposed QCBM's random probe file.
- Direct URL configured/inconclusive: protection files exist and the probe was not exposed, but QCBM could not confirm a normal denial response.
- Low available space: the storage may be writable but still lack enough room for the selected backup, Recovery Package, and temporary work.
Why File Valet Can Refuse to Run
File Valet requires its working package folder to be outside the public Joomla document root. QCBM therefore refuses to start File Valet while Managed Private Storage is inside the webroot, even when Compatibility storage is otherwise protected well enough for backups.
If File Valet reports this restriction, open Settings > Advanced Storage Tools and use Move Backup Storage to move the existing managed storage to a dedicated outside-webroot path. Do not manually move only the File Valet files.
Compatibility Storage Is Not a Backup Strategy by Itself
Compatibility storage can keep QCBM operational on restrictive hosting, but it still resides inside the same hosting account as the Joomla site. A server failure, account suspension, compromise, or destructive hosting event can affect both the website and its local backups.
Configure and test an off-site Export Destination when the site depends on Compatibility storage. Keep at least one verified Recovery Package in an independent location.
When to Move Back Outside the Webroot
If the hosting environment later permits a private account-level folder, use Move Backup Storage rather than editing paths or moving folders manually. QCBM will copy and SHA-256 verify the managed data, update its recorded paths transactionally, and clear Compatibility storage state after the move succeeds.
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.