Restoring a Test Instance from Production
See Migrating Confluence Between Servers for a more comprehensive explanation.
Many Confluence administrators will have a production instance running the "live" version of Confluence, as well as a test instance for testing upgrades and so on. In this situation, it's quite common that the two instances are running different versions of Confluence. This document describes how to copy the data from a production instance to a test instance, where the production version may be different to the test version.
Before proceeding with this guide, ensure you have read and understood the normal procedure for upgrading Confluence.
Updating a test Confluence instance with production data
Essentially, we are copying both the production home directory and database to the test instance. We then update the database details on the test instance to point to the test database, leaving all other instance metadata (most importantly the Confluence build number) the same as production.
- Shut down your test instance.
- Restore the production database to the test database server.
- Create a backup of the
confluence.cfg.xmlfile found in the home directory of the test instance. - Copy the production confluence-home directory to the test application server.
- Open the
confluence.cfg.xmlwhich has been copied in a text editor. Change the database settings to match the test database server. Ensure you do not point to your production database. (You can compare with the backup you made in Step 3 if you need to get the database settings. Don't just copy this file – you need the build number unchanged from production to indicate the database is from an older version of Confluence.)
Before starting your test instance, you need to do the following steps to ensure no contact with production systems.
Ensuring no contact with production systems
To ensure no contact with external systems, you will need to disable both inbound and outbound mail services.
Disable global outbound mail by running the following database query:
SELECT * FROM BANDANA WHERE BANDANAKEY = 'atlassian.confluence.smtp.mail.accounts';Disable space-level mail archiving by running the following database query:
SELECT * FROM BANDANA WHERE BANDANAKEY = 'atlassian.confluence.space.mailaccounts';
Change the 'SELECT *' to a 'DELETE' in the above queries once you are sure you want to remove the specified accounts.
Once this is done, you can start your test instance without any mails being sent or retrieved. Think carefully about other plugins which may access production systems (SQL macro, etc.). These should be disabled promptly after starting the test instance.
You can create a developer license for this server and update the License Details after starting up.