[Collapse]Collaborator 10
 [Expand]General Information/viewarticle/80040/
 [Expand]Getting Started/viewarticle/80359/
 [Collapse]Collaborator Server/viewarticle/80060/
  [Expand]Installation/viewarticle/80365/
  [Collapse]Server Administration/viewarticle/80108/
    Network Configuration/viewarticle/80122/
    Licensing/viewarticle/80099/
    Content Storage/viewarticle/80446/
    Backup / Migration/viewarticle/80105/
    Security Considerations/viewarticle/80447/
    LDAP Authentication/viewarticle/80075/
    Configuring HTTPS/viewarticle/80425/
    Configuring Single Sign-On/viewarticle/80345/
    JMX Monitoring/viewarticle/80445/
    Technical Specifications/viewarticle/80449/
    High Availability Best Practices/viewarticle/80109/
    Variable Substitution/viewarticle/80101/
    Archiving Reviews/viewarticle/80084/
    Branding Your Server/viewarticle/91140/
    Diagnostics/viewarticle/80106/
    Logging/viewarticle/80448/
    Troubleshooting/viewarticle/80335/
  [Expand]Collaborator Settings/viewarticle/80061/
 [Expand]Web Client/viewarticle/80107/
 [Expand]Desktop Clients/viewarticle/80151/
 [Expand]Version Control Integration/viewarticle/80048/
 [Expand]External Integrations/viewarticle/80340/
 [Expand]Techniques & Best Practices/viewarticle/80403/
 [Expand]Appendices/viewarticle/80117/
Updated: 12/23/2016 Applies To: Collaborator 10 Rating: No votes Click to rate: PoorNot badAverageGoodExcellent

Collaborator Server > Server Administration

Top |Previous |Next

Server Backup / Restore / Migrate

Collaborator can be backed up while it is running. Also, there is a system for migrating data from one database to another.

Collaborator stores almost all data in the database initially set up for it. It also uses file content storage - a local directory that keeps copies of uploaded files. These are the two systems that need to participate in the backup/restore process.

Backing up the Database

NOTE: Each license key is linked to the node ID, and it gets carried over during server migration. Therefore, a new license key is not needed when migrating the server.

The mechanism for backing up the database depends on the database. See the documentation for your database for details.

You can easily create a backup dump of your database into a zip file using the command line (and scripts):

ccollab admin wget “/data/server?dump=1" > backup.zip

The backup.zip file will be created within your home or user profile directory depending on your OS.

You may specify the following parameters when creating a database dump:

&obfuscate - Specifies whether to copy the data as is (&obfuscate=0) (default), or to obfuscate all sensitive information, like file contents, user names and so on (&obfuscate=1).
&withserverlogs - Specifies whether to include server logs (&withserverlogs=1) or not (&withserverlogs=0) (default).
&withfiles - Specifies whether to include content of all files (&withfiles=1) or not (&withfiles=0) (default).
&configonly - Specifies wether to create a whole system dump (&configonly=0)(default) or to save the system settings (&configonly=1).

A subset of the four parameters listed above can be appended to the "/data/server?dump=1" URL. For example, the command below will perform a complete backup of your entire environment, which will include both the server logs and content cache.

ccollab admin wget "/data/server?dump=1&withserverlogs=1&withfiles=1" > backup.zip

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 Content Cache

The default location of file content storage - a local directory that keeps copies of uploaded files - is listed below (however, the default location 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 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 Collaborator Backup

To restore a Collaborator installation, first restore the database as directed in your database documentation. Then, install the 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 Collaborator is running.

If you have 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

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 Collaborator installation.

1. Creating the Migration Dump File

To create the migration data dump file, log into the Collaborator web server, and click the System link at the bottom of the screen:

ws-system

Near the top of the screen is a form and a button which will allow you to download a whole system dump:

ws-system-dumpall

It contains the following settings:

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 is important to include the server logs.

do not 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 have 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 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 Collaborator Server install.
Make sure the 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 do not 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.
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 Collaborator Server install location is not changing, you will still need to rerun the installer to point Collaborator to the correct database.
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 will assume the location is:

c:\temp\ccollab-dump.zip

3. Make sure the 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 does not 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 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 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.



© 2019 SmartBear Software. All rights reserved.
Email Send feedback on this document