We frequently dump databases from one server and load them on another & it works pretty well.

There are a couple of things to watch out for however.
1) Login. You will probably want to make sure you have a non-LDAP Site Admin login on the source server. LDAP might work on another server, but might not.

2) https/ports . If the original is set up on https or on a different port than yours that might present problems. You might need to configure this in the database by directly editing prop.properties table in the database before startup. You probably want to set sslRequired to false

Dumping and restoring the entire labkey database (i.e., all labkey schemas) will generally work best. Several production installations of LabKey use this method to snapshot their primary database and move it to their test and staging servers. Just be aware that ALL settings, users, and permissions will be copied with the database. In the case of moving a production database to a dev or test server, you'll probably want to make modifications, such as:

• De-activate most users (to prevent them from getting email notifications from the clone, e.g.)
• Change the color scheme and header name (to make it more obvious which server you're using)
• Change base server URL and exception reporting settings (on a dev machine)
• Look at the SSL and authentication settings

If you're going to do this regularly, I suggest writing a SQL script that automatically performs these changes.

Restoring individual tables will not work very well, since container ids, user ids, and other foreign keys will differ between servers.

mark - i thought you weren't going to be working this week.

do you guys have any existing SQL scripts I could take and modify for this purpose? it's probably a smart thing for us to have something like this.

Ben - We do have an existing script for handing most of the tasks outlined by Adam. I will send it to you via email.