Issue Summary

On a setup where the Production Bitbucket primary instance is connected with mirrors, when the Production Environments(DB and the FileSystem) are cloned to create a staging instance based on the production environment, the links to the production mirror are also copied over, since that information is stored in the Primary Database.

If this is not deleted from the staging instance database, as recommended in the KB How to establish staging server environments for Bitbucket Server, before starting it up or the plugin.mirroring.delete.on.startup=true on bitbucket.properties file is not used to remove them on startup on Staging, issues may arise.

On the staging primary instance, if an attempt is made to delete the prod mirror, it will disrupt the production mirror synchronization as well.

This is reproducible on Data Center: (yes)

Steps to Reproduce

1. Set up the Bitbucket primary with mirrors.
2. Clone the Bitbucket primary database and filesystem to create a new instance from it.
3. On the new cloned instance, delete the production mirror.
4. The status of the production mirror is set to REMOVED, which impacts the mirror sync on production.

Expected Results

The cloned Staging instance should not be able to connect to the production mirror nodes and run actions that shouldn't be allowed.

Actual Results

Since the production database is cloned to the staging instance and the entries were not deleted in the database or using the "plugin.mirroring.delete.on.startup=true" properties in the bitbucket.properties file, the staging instance can connect to the production mirror, which can cause issues.

Workaround

Follow the instructions in the KB How to establish staging server environments for Bitbucket Server and ensure the production mirrors are deleted before the instance is started up. Additionally, isolate the staging environment from the production instance completely so it cannot connect to any production mirror nodes.