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.


(warning) The information on this page does not apply to Confluence Cloud.

Upgrading 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.

  1. Shut down your test instance.
  2. Restore the production database to the test database server.
  3. Create a backup of the confluence.cfg.xml file found in the home directory of the test instance.
  4. Copy the production confluence-home directory to the test application server.
  5. Open the confluence.cfg.xml which 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.

  1. Disable global outbound mail by running the following database query:

  2. Disable space-level mail archiving by running the following database query:

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.

See also

Upgrading Confluence
Migrating Confluence Between Servers
Restoring to a Test Instance of Confluence from Production

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

8 Archived comments

  1. User avatar

    Peter R.

    Is this the process to follow if we want to disable all existing mail notification setups but allow new ones to go in? In other words, if we copy PROD to QA we don't want QA to send emails to users that signed up for notifications in PROD but we do want our QA testers to be able to use the email notification features as part of their testing.

    Right now I've just removed the mail server by hand...

    12 Nov 2008
    1. User avatar

      Azwandi Aris [Atlassian]

      Hi Peter,

      The instructions above will remove the mail accounts set for both inbound and outbound emails. That will ensure Confluence not to send out notifications to any users, regardless they are PROD users or QA testers. If you would like to maintain the mail accounts (for QA testers usage), you may want to perform this instead:

      1. Do not delete the mail account settings
      2. Remove the PROD users notifications/daily report: SELECT * FROM notifications

      Hope that helps.


      14 Nov 2008
      1. User avatar

        Peter R.

        Perfect, that's exactly what I needed. Thanks!

        14 Nov 2008
  2. User avatar


    How to shut down crowd:

    1. open command prompt
    2. type:

    net stop confluence

    13 Sep 2011
  3. User avatar

    Vidal Abad

    How can I delete all application links to production systems?

    07 Aug 2013
  4. User avatar

    fred Bleuzet

    Hi everyone,

    Bumping up Vidal's last question as I do have the same problem. Doing a restore that way keeps all the application link live, so when changing then in TEST, the PROD app links are messed up.

    So how do we delete all those app links in the TEST DB before safely starting Confluence in TEST?

    27 Apr 2015
    1. User avatar

      Giles Brunning [Atlassian Technical Writer]

      Hi Fred,

      Sounds like someone might need to dig into this a bit more, so I'd suggest contacting support so that someone can work through it with you.

      28 Apr 2015
      1. User avatar

        fred Bleuzet

        Not really, I already spent quality time with support to figure out the right configurations of all links between JIRA, Confluence and Bamboo. The Atlassian products are so awesomely integrated that I couldn't figure out the right checkboxes to click. But now I think I'm good, at least last time I restored a Confluence test instance I was able to fix the broken PROD application links.

        No, same as Vidal is asking, this page needs to be edited to provide instruction on how to handle the application links so that my TEST instance never connects to the PROD instances.

        I tried messing around with the BANDANA table but that was not enjoyable and still not sure if it's enough.

        28 Apr 2015
Powered by Confluence and Scroll Viewport