Troubleshoot Recovery Protection and Recovery Vault Actions

This article shows how to diagnose recovery-storage capacity/permissions, protection failures that block destructive actions, missing protected objects, ZipArchive folder-download issues, restore authorization and cleanup state.

What you need to know

  • Basic includes Local storage and the first active Workspace. Pro adds FTP/SFTP, multiple Workspaces, advanced permissions, and background continuation. Max/All Access adds Google Drive, OneDrive, Private Connections, Recovery Vault management, and bulk operations.
  • A plan gate decides whether a feature exists at the current Effective tier. Joomla access and QCSB permission rules separately decide whether a particular user may use that feature.
  • 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.

Troubleshooting procedure

  1. Verify the private storage path is writable, outside the public web root, and has sufficient free space.
  2. Check the Recovery retention setting and Recovery Vault Cleanup task health.
  3. Repeat the operation with one small test item; if preservation fails, treat the blocked destructive action as a safety success rather than bypassing it.
  4. For restore, confirm the target location still exists and the user still has current restore/copy-in permission.
  5. For folder download, confirm ZipArchive is available; for purge, confirm the item is still in an available state.

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.

If it still fails

  • Change one variable at a time and repeat the same small test after each correction.
  • Use QCSB sanitized errors/Status/Test Connection before changing unrelated provider or Joomla settings.
  • If the issue remains, collect version, provider type, Workspace/user role, task state where relevant, and sanitized messages for support. Never include secrets.

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.