Backing Up ThingWorx
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.
The only exception to this rule is the H2 database since it runs in the embedded mode. In this case, ThingWorx provides built-in capability to schedule automatic backups to a directory specified by the “ThingworxBackupStorage” configuration parameter in the platform-settings.json file. However, due to its embedded nature it is not a highly available solution and therefore, does not have any failover capability.
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:
H2 - Making archives of the data folder in ThingworxStorage
ThingWorx Model
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 standard export REST API.
The Export Source Control Entities REST API. This uses a version control system such as Git or Subversion.
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.
PTC does not guarantee that the export formats will conform to any particular standard and may change without notice between ThingWorx versions. Therefore, creating external applications that consume these exported files is not recommended.
Runtime Data
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.
File Repository
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.
Other File-Based Artifacts
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:
Configuration files in the ThingworxPlatform directory
Log files in ThingworxStorage/logs directory
Reports that may have been generated in the ThingworxStorage/reports directory
Was this helpful?