Summary:
Currently, the Atlassian Backup/Restore tool requires the target site (including sandboxes) to be completely emptied before a backup can be restored. This creates a significant operational burden for customers who want to validate backups or test migrations using sandboxes, as the built-in "Copy production data" function is architecturally different from restoring a backup file.

Problem Statement:
Customers using the Backup/Restore tool face three related constraints that limit its practical usefulness:

1. Restore requires an empty target site — Before restoring a backup, all existing data must be deleted from the destination. This makes it impractical for routine backup validation or testing.

1. Sandbox "Copy production data" is not equivalent to a backup restore — The Full Data Copy mechanism mirrors production into the sandbox but does not test or validate the actual backup/restore workflow. Customers cannot use sandboxes to verify that their backups are restorable.

1. No self-serve immediate sandbox deletion — Deactivating a sandbox triggers a 30-day deletion wait. Customers who need to quickly reset a sandbox to test a backup restore must file a support request for immediate deletion, adding friction and delays.

Expected Behavior:

• Allow restoring a backup to a sandbox or temporary site that already contains data (with an overwrite confirmation), OR

• Provide a self-serve option to immediately reset/delete a sandbox so it can be used as a restore target without a 30-day wait.

Use Case:
A customer wants to periodically validate that their Atlassian Cloud backup is restorable. Today, there is no practical self-serve path to do this without provisioning a new temporary site or waiting 30+ days to clear a sandbox.