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.