Why QCSB Blocks Destructive Actions When Recovery Protection Fails

This article explains the fail-safe design: inability to create or verify the protected copy is a reason to stop delete/replace/destructive move rather than continue without recoverability.

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.

The safety rule

Delete, replace/overwrite, and destructive Move change or remove provider content. QCSB treats a verified protected copy as a prerequisite for those destructive transitions. A storage-capacity, permissions, private-recovery-path, or write/verification failure is therefore a reason to stop the destructive action—not a warning to ignore.

What to fix

  • Confirm the configured private recovery path exists, is writable by PHP, and is outside the public web root where possible.
  • Confirm sufficient free capacity for the item being protected and the configured retention period.
  • Review the sanitized Recovery/operation error and correct filesystem/provider prerequisites.
  • Retry the original destructive action only after protection can succeed.

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.