How QCSB Handles Name Conflicts During Recovery

This article explains the recovery-safe Preserve both behavior so an existing object at the restore target is not silently overwritten.

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.

Restore conflict behavior

Recovery restore does not silently overwrite a current item with the same requested name. When a conflict exists, QCSB uses preserve-both behavior and chooses a safe unique name so the current destination and restored historical copy can coexist.

After restore

• Confirm the restored item’s actual final name and content.
• Keep the protected Recovery record until its retention/purge lifecycle says otherwise; a successful restore does not require immediately deleting the safety copy.
• If you need a different destination/name, use Restore To… and explicitly choose the target connection, folder, and restored name.

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.