User guide: Backup, restore and migration
Back up data, project files, published releases, scripts and runtime configuration. Settings exports only its own fields.
Select backup contents
Identify backup locations from the installation tree or persistent container volumes.
- Back up PostgreSQL/TimescaleDB and record the matching application and database versions.
- Back up the actual user-page directory shown in Screen Files, all referenced assets, and the upload history under SCREEN_FILE_HISTORY_DIR. If the project also uses published releases, back up SCREEN_PUBLISH_ROOT_DIR.
- Preserve script sources, dependency manifests and offline packages, plus the config / configs locations actually used, popup templates, media channels, certificates, node identities and project credentials.
- Document the roles of data, logs and backups in the deployment. Store keys and licensing material in a controlled backup location.
Perform backup and restore
Use a database-supported consistent backup method. Copying a live database directory does not ensure recoverability.
- For an installation-wide file backup, schedule maintenance and stop the relevant runtime and data services using the package procedure.
- Prepare matching versions at the restore destination, then restore the database, assets and upload history, any published releases in use, scripts and configuration.
- After startup, inspect database, Redis, the five services and license, followed by screens, device quality, alarms, trends, scripts and permissions.
Move to new hardware or addresses
Migration affects access endpoints, device identity and collection responsibility.
- Update Portal and Screen endpoints and certificates, and verify both from clients.
- Activate replacement hardware as required by the License page. Recheck site connection identities and capabilities.
- Confirm the old node has relinquished collection responsibility for the target PLC before enabling the new node. Verify quality, timestamps and source in Tag Diagnostics.
