Use the Frontend Recovery Vault
This article explains when Recovery Vault controls appear to an entitled frontend user and how current restore/purge permissions limit which protected items they may manage.
What you need to know
- Recovery protection is a safety boundary for destructive operations and is separate from Max/All Access Recovery Vault management. QCSB may create protected copies even when the current user cannot open the management UI.
- Delete, replace/overwrite, and destructive move are blocked when the required protected copy cannot be created and verified.
How to do it
- Open the frontend Workspace as a user whose current plan/permission allows Recovery Vault management.
- Open the Recovery Vault area and locate the protected item.
- Choose Restore, Restore To…, Download, or Purge according to the intended recovery action.
- For Restore To…, use the screen-level destination dialog to choose another authorized connection/folder.
- Verify the restored item exists where expected. QCSB rechecks current permission at execution time rather than trusting a previously rendered button.
Verify the result
- The Recovery item/state matches the action you performed.
- A restored/downloaded item matches the expected content and destination.
- Purge/cleanup does not erase the historical audit trail.
Important limits and mistakes to avoid
- Do not bypass failed recovery protection to force a destructive action. The block is intentional safety behavior.
Troubleshooting
- If a destructive action is blocked because recovery protection failed, repair recovery storage/capacity first; do not bypass the protection boundary.
Community Discussion
For practical QCSB workflows and discussion with other Joomla site owners, visit the QC Storage Bridge Community. For private support, bug reports, account-specific entitlement issues, or feature requests, use the QuantaCade support system.