In this section:

Introduction

Before upgrading or making significant changes to your system, you should back up your DTP data files and database to prevent loss of data.

Data associated with the following components and directories are backed up:

• DTP database
• Data Collector files
• 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. Contact your database administrator about backing up the database being used by DTP.
3. Back up DTP data files.
4. Back up the application files.

Backing Up the Data Files

Shut down all DTP applications (DTP Server, Data Collector, Enterprise Pack) and make a backup of the <DTP_DATA_DIR> folder. To recover the data, redeploy the <DTP_DATA_DIR> directory to its original location, e.g., C:\ProgramData\Parasoft for Windows.

Backing Up the Application Files 

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. So 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 (i.e., 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 (e.g., prioritization actions, etc.) that were performed through the UI or REST API between 3/30 and 5/13 would be lost.