HI @DB_10158214
I noticed the article you were provided is outdated. For learning more regarding High Availability, please refer to the ThingWorx Help Center.
In regard to disaster recovery, this is something you will need to plan out and test given your current environmental needs. To start, you will need to have an adequate backup plan. Refer to this article for guidance. You may want to consider storing your backups in the cloud for immediate access, if needed. Also, you will need to consider what an acceptable amount of loss would be in a true disaster, though this can be minimized by mirroring at the db level, as long as the db's are not co-located together. Be sure to include your certificates in your backups and document specifics around your current environment, such as hostnames, IP addresses, db names, versions of third party products (java, Tomcat, database). etc., as this information may be needed for DR.
If I were setting up a DR site, I would have the ThingWorx and database servers staged. These servers would need to be kept in sync with the current Prod instance. For example, if you install a patch level upgrade of ThingWorx in Prod, you would need to do the same on the DR instance. If you upgrade java in the Prod instance, you would need to do so on the DR instance. If you upgrade the database in Prod, be sure to do so on the DR instance. I'm sure you get the idea.
The db backup can be pulled from the Prod database and restored in the DR environment for testing. Keep in mind that the keystore files located in \ThingworxStorage and \ThingworxPlatform would need to be restored on the new server to ensure the appKeys are not lost.
The most difficult part around testing is the fact that the server names and IP addresses would be different, resulting in your endpoints being unable to connect. In case of a true disaster, to quickly restore connectivity from your endpoints to ThingWorx, you may want to consider updating the DR servers with the current Prod server hostnames and IP addresses. If you don't have that many endpoints, you could easily update the configs for those endpoints to talk to the new ThingWorx hostname/IP address once the database has been refreshed with your last prod backup. In your testing, however, you will need to be careful that production data does not flow into your DR site.
As previously stated, DR requires planning and testing. Hopefully, this is enough to get you started and provide some food for thought. If you have additional questions, please let us know.
Regards.
--Sharon
