ThingWorx related backups can be executed at both the data store level and ThingWorx application level. The data-store-level backup should be carried out on a regular basis, even if the data stores are installed in a highly available configuration with data redundancy. This is applicable for all data stores that the model and data providers are using.

The information in this topic refers only to the capabilities provided by the ThingWorx platform for application-level backups, with the exception of the H2 database.

Refer to the ThingWorx Backup and Recovery Planning guide for general data store backup guidelines and refer to the original vendor documentation for further details, including the following:

The most flexible feature of a ThingWorx based application is the ability to change the ThingWorx model directly at run time either manually via the Composer or programmatically via REST API, scripts or extensions. It is recommended to keep track of the model changes to recover from an inadvertent change in the production. This can be achieved by exporting the point-in time snapshots of the model entities regularly.

These snapshot back-ups can also be accomplished by using a scheduler to automatically invoke the following:

The difference between the above two options is that the Export Source Control Entities option generates individual XML files in folders per entity type to make the export human readable, whereas the binary “.twx” format is compressed and comparatively efficient to import.

Similar to the Model exports, there is a standard REST API to export the run time data as well. Since the run time data could grow significantly large over time the export process is parallelized and the export files are split into multiple smaller files that are easier to manage. Due to the large size of the data, it is recommended to export the data in an incremental fashion at the application level rather than full backups. Further, to avoid long running exports, it is recommended to export per entity basis where possible. Consider the data store level backups to preserve the run time data as a best practice. The data exports are saved in the ThingworxStorage/exports directory. The exports are in binary files with the .twx extension, in folders per entity type, under the current date, and in the repository directory. The data is split into multiple files based on the export file size and processing thread pool sizes set in the Export Import Subsystem.

This feature is generally intended to be used to migrate the data from one system to another rather than doing regular backups. While periodic non overlapping (i.e. use start and end dates for the data exports) exports can be used to archive the data periodically, a more efficient option would be to use the data store-level backups to preserve the run time data.

The file repository in ThingWorx is a file system directory that would generally be on a local or a shared (in the case of a highly available ThingWorx installation) drive. This is a regular file system directory defined by the ThingworxFileStorage environment variable in a custom setting or in ThingworxStorage/repository by default. Any file backup solution provided by the operating system used can be used to backup this directory regularly. (that is, rsync in Linux)

Extensions, once imported to ThingWorx, are cached in the file system and also saved to the data store in highly available configurations. In this case it is recommended to preserve the original extension packages rather than backing up the cached versions as the best practice since the extensions in the PTC downloads are regularly upgraded, and you may not be able to re-download the version that was used for the development. The file system cache is in the ThingworxStorage/extensions directory.

The other file-based artifacts that can be backed up using any operating system-based file backup tools (that is, rsync in Linux) related to ThingWorx are: