In this section:

Introduction

You should back up your DTP database and data files periodically to prevent loss of data. This is especially important before upgrading or making significant changes to your system.

Below, we outline steps to back up data associated with the following components:

• DTP database
• DTP data dir, including Data Collector files
• DTP server configuration files

We recommend completing the following steps to ensure that the complete system is backed up properly:

1. Stop DTP Server, Data Collector, and DTP Enterprise Pack services.
2. Back up the DTP database. 
3. Back up DTP data dir.
4. Back up DTP server configuration files.

Backing Up the Database

Contact your database administrator about backing up the database being used by DTP. Note that certain database configuration (for example, MySQL replication) will not require stopping DTP Server or Data Collector.

Backing Up the Data Directory

Make sure all DTP applications (DTP Server, Data Collector, Enterprise Pack) are shut down, then make a backup of the <DTP_DATA_DIR> folder.

Backing Up the Server Configuration Files 

Make sure DTP Server is shut down, then make a copy of any Tomcat configuration files you may have changed in <DTP_INSTALL>/tomcat/conf directory.

Recovering Data After Unexpected Issues

In the event of a disruption, such as a hardware failure, that causes the database to be out of sync with DTP, all data should be recoverable if the database was synced with the production server.

Reports of analysis, published sources, and detailed coverage information are stored in file. If the database is in sync, but the complete file system was not copied over, the following scenarios are possible:

• If the production server did not process a report of analysis (that is, the XML file was received and placed into the database without parsing the data), and the report was not copied to the recovery server, then that data would be lost. You would have to manually recover the report from the machine that performed the analysis.
• If sources were published to production server but not copied to the recovery server, then the published sources would be lost. However, the sources should be available elsewhere in your environment.
• A summary of coverage is saved in the database, but detailed coverage information is stored on file. If these files are lost, you would have to recover the coverage/unit test analysis report from the machine that performed the analysis.

Ensuring that the database is in sync is critical for disaster recovery. Consider the following scenario as an example:

• A disaster occurred at 5 p.m. on May 14.
• The DTP folder was in sync as of 10:00 p.m. on May 13.
• The last snapshot in the disaster recovery database is from March 30 (six weeks old).

You would have files up to 10 p.m. on 5/13 that can be processed by Data Collector. As for the analysis results, the database would be synced to the state of the production database at 10 p.m. on 5/13. Any other changes in the production database (like prioritization actions and so on) that were performed through the UI or REST API between 3/30 and 5/13 would be lost.