Plan Private Recovery Storage Capacity and Location

This article explains the private recovery storage path, why protected copies should remain outside the public web root where possible, and how administrators should capacity-plan for retention and destructive activity.

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.
  • My Private Storage requires Max/All Access and supports user-owned FTP, SFTP, Google Drive, and OneDrive connections. Local storage remains administrator-created only.
  • Private connection ownership is enforced server-side. Private connections cannot be inserted into administrator shared Workspaces even if request/database values are manipulated.

Capacity planning inputs

  • Configured Recovery retention period: 1–3650 days, with 30 days as the current default.
  • Largest files/folders that users may delete, replace, or move destructively.
  • Expected number/frequency of destructive operations during the retention window.
  • Temporary staging/ZIP needs in addition to retained protected copies.
  • Filesystem free space, permissions, backup/monitoring practices, and keeping the private path outside the public web root where possible.

Practical rule

Do not size recovery storage from the Joomla database size or average document size alone. A single replacement of a very large provider object can require substantial protected capacity immediately, and multiple destructive versions can coexist until retention/cleanup removes them.

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 copy administrator or another user’s provider credentials into a private connection as a shortcut; private connections are intentionally isolated.
  • 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.