Recovery Vault Cleanup, Expiration, Missing Objects, and Failed Cleanup
This article explains the 60-minute cleanup task and the states it records when retention expires, protected content is already missing, or cleanup cannot complete.
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.
Cleanup outcomes
| Condition | Expected handling |
|---|---|
| Not yet expired | Protected object remains available under its retain-until policy. |
| Expired and present | The 60-minute Recovery Vault Cleanup task can purge the protected object according to retention policy while preserving historical/audit context. |
| Object already missing | QCSB records/handles the missing protected-object condition instead of inventing a successful downloadable object. |
| Cleanup fails | The task/error state remains diagnosable and can retry later; a failed cleanup should not be represented as a clean purge. |
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.