Version 4

    From time to time you'll need to migrate your production database to a new instance. This is a common technique when you need to test with production data to troubleshoot a bug, work on custom code, or practice an upgrade. The process is simple:


    • Backup & restore the database to the new location
    • Install the RPM on the new server
    • Copy the home directory from the original instance to the same location on the new instance (e.g. /usr/local/jive/applications/sbs/)


    However, there are a few gotchas to keep in mind:



    Your production instance was likely hooked up to both send email notifications (SMTP) and access an email account (Email Monitor) or server (Advanced Incoming Email). You'll definitely want to change these settings once you have set up your test instance, otherwise you may find that the new instance generates email notifications that look like they're coming from the production instance. This can be very confusing to end users, and might end up unnecessarily burdening your email servers.  Here's a description of that common misconfiguration: Troubleshooting Duplicate Email Issues.


    To mitigate this problem:


    • Change all email addresses to a dummy value:
    UPDATE jiveuser SET email = 'dummy@localhost';
    • Turn off SMTP by changing the SMTP server name to "nomail"
    • Disconnect or reconfigure the Email Monitor to point to a different mailbox
    • Disconnect or reconfigure the Advanced Incoming Email feature



    You'll definitely want to change the jiveURL system property to match the URL at which you're hosting the test instance. The jiveURL is used throughout the app to render links. If you do not change this property, you will find that links to content in your test instance redirect you back to production! Additionally, this will help people recognize when they're using the test instance instead of production.



    This one is VERY IMPORTANT - make sure to disable the analytics module on the test server. Otherwise, you will have two instances, production and test, writing data to the same Analytics database. This can cause data corruption and ETL task failures. Additionally, if you leave the Analytics settings in place and run a major upgrade, you may break Analytics functionality on the production server by upgrading the Analytics database schema to the new version. You can, of course, set up a new database for Analytics for your test instance. Just make sure you do one or the other!



    Video keys are only meant to work with a single instance. Remove the video keys from the test instance to ensure that you do not "confuse" the video provider and thereby break video functionality on your production instance.