|
Code Collaborator can be backed up while it is running. Also, there is a system for migrating data from one database to another.
Code Collaborator stores almost all data in the database initially set up for it. It also uses a local directory to store copies of uploaded files. These are the two systems that need to participate in the backup/restore process.
Backing up the Database
The mechanism for backing up the database depends on the database. Other than the embedded database that's used for trials only, all supported databases have some mechanism for live backup. See the documentation for your database for details.
There is an alternate method for backing up the database which is to perform the first half of a database migration and save the migration data file. Backing up the File Cache
The local directory you need to back up is located here (by default -- it can be changed by the system administrator):
installation-directory/tomcat/collaborator-content-cache
Typically, a backup mechanism will either copy this directory elsewhere or will keep a zip or other compressed archive file updated with the contents. You can do this while Code Collaborator is running, although most backup mechanisms will run at off-peak hours.
Files in this cache are stored in such a way that a file is written only once and thereafter is never changed. This means incremental backups of the directory are particularly easy -- only new files must be copied. Most file-copy utilities have a mode that means "only copy new files."
Restoring a Code Collaborator Backup
To restore a Code Collaborator installation, first restore the database as directed in your database documentation. Then, install the Code Collaborator server software. Finally, restore the contents of the collaborator-content-cache directory in the new installation directory. You can do this last step while Code Collaborator is running.
If you've used the database migration technique to back up the database, refer to steps 3-11 of Restoring the Data Dump File for instructions on migrating the database data.
Migrating Data Between Databases
Code Collaborator has a generic mechanism for migrating data between databases -- even if the databases are completely different types.
Applications of this migration technique include:
| • |
migrating between the embedded database and one of the other databases when a trial moves to a production environment |
| • |
backing up a database in a database-independent and easily-inspected manner |
| • |
when we add support for a new database and you want to switch over to it |
| • |
we need to debug your database and you need to send a "dump" of your data to SmartBear Technical Support |
There are two halves to the migration process: Creating the migration data dump file, and"restoring" the data dump file into a Code Collaborator installation.
1. Creating the Migration Dump File
To create the migration data dump file, log into the Code Collaborator web server, and click the System link at the bottom of the screen:
Near the top of the screen is a form and a button which will allow you to download a whole system dump:
Making the appropriate selection:
1. Data Format: Normal - Selecting "Normal" will leave the data as is.
Obfuscated - Selecting "Obfuscated" will change the data to conceal sensitive information.
2. Server Logs: Include server logs - Selecting this will include server logs in dump. Note: If you are creating a dump file to send to technical support, it's important to include the server logs.
Don't include server logs - Selecting this will not include server logs in the dump file.
3. File Contents: No file content - Selecting "No file content" will not include file content.
Include all file content - Selecting this will include all file content, but this will also cause a longer download.
4. Which Data: Complete database dump - This must be selected for a whole system dump.
System configuration only - no review data - Selecting this will only save the system settings.
Once you've filled out the form, click the "Download Dump File" button to download the database dump file. This is a ZIP file containing all your database data in a platform- and database-independent XML format, plus additional files that describes your server environment.
2. Restoring the data dump file
Loading this data into another Code Collaborator installation requires some effort. This process is intentionally complex to prevent accidental destruction of real data.
Below are the steps to restoring a database migration data dump file:
| 1. |
Verify your Code Collaborator Server install. |
| 1.1. |
Make sure the Code Collaborator server version and build number are identical between the server that created the data dump file and the server that is loading it. If the versions don't match exactly, the restore might not succeed. SmartBear maintains installers for previous versions of the server if you need one. You can always upgrade to another version after the migration. |
| 1.2. |
Be sure when running the installer, you give the correct connection parameters to point the server to the database to which you plan to migrate. Note: Even if the Code Collaborator Server install location is not changing, you will still need to rerun the installer to point Code Collaborator to the correct database. |
| 1.3. |
Once the install is complete, a browser window should open. Do NOT initialize the database as prompted in the browser. |
| 2. |
Move the dump file into a known location. In this example we'll assume the location is:
c:\temp\ccollab-dump.zip. |
| 3. |
Make sure the Code Collaborator server where you will load the dump is not running. This will not work on a running server. |
| 4. |
Open the Tomcat session configuration file located here:
installation-directory/tomcat/conf/Catalina/localhost/ROOT.xml |
| 5. |
Find the parameter called database-migration-data-path, or create one if it doesn't already exist. It should look something like this:
<Parameter name="database-migration-data-path" value="c:\temp\ccollab-dump.zip" override="false" /> |
| 6. |
Make sure the value string matches the location of the dump file, as in the example above. Use an absolute file path. |
| 7. |
Save the configuration file. |
| 8. |
Use a database administration tool to make sure the database configured for use with Code Collaborator has no tables in it. If there are any tables in the database the restore will not work. This prevents accidental restoring over an existing database. |
| 9. |
Start the Code Collaborator server. |
| 10. |
The server will automatically load the data from the database migration data dump file. If there were any problems with migration, you will see a helpful error message in the server log. The server will also log progress reports as data is loaded up, so if you have a large database and you wish to monitor migration progress you can "tail" the log file to see what's happening. Loading migration data can take a long time, so be patient! |
| 11. |
Upon starting after restoring a migrated database, email notifications will be disabled. This is to prevent users from receiving spurious duplicate email notifications when administrators restore into test configurations. You may re-enable email notifications from the email administration page. |
|