Skip to content

Backup & restore

Under Settings › Backup & restore you handle your tenant’s whole state: download it as a file, upload a saved one to replace it, and go back to one of the last ten restore points. All of it is reserved for administrators.

Loading here replaces everything. A template from the store, by contrast, only adds (see Templates and the store). That is why loading has an area of its own, apart from the store. A template can be taken down again with Updating and removing; for loading there is only the all-or-nothing way back through a restore point.

A configuration is a description, not a database dump. It contains names only — Press1.PartCount, ProductionReport, manager — never internal identifiers. That is why the same file works in another tenant, and why it survives a change of release: “a dashboard with a tile on Plant.OEE” stays meaningful even when the tables underneath change.

On load those names become identifiers again. If one of them cannot be resolved, the load aborts rather than applying half of it.

Scripts travel. A script is in the file with its path, its trigger and its inputs — and the tags it listens to are named by path as well. A tenant whose data arrives through a script is therefore fully described: load it, and the data flows.

Connector tags travel with their binding. A tag that listens to a machine is saved with the name of its connection (for example Line PLC), its direction and the connector’s own fields (for example the symbol to read). The connection itself — address, credentials — is not in the file: it belongs to the tenant and stays where it is. So the connection of that name must exist in the target tenant before you load. If it does not, the check names the tag and the missing connection and nothing is loaded. A connector tag saved without a binding loads as before: it exists and hears nothing until you bind it.

Icons you uploaded yourself travel too, the picture itself and not just its name. A navigation entry wearing your own logo comes back wearing it. Where your tenant holds two icons of the same name, loading makes one of them.

Saves the tenant as it stands, as a file to download. The Include demo data in the download switch decides whether the operational records come along; it is off by default, so production data does not accidentally end up in a file that gets passed on.

Master data always travels. Lines, stations, shifts and the closed value lists belong to the configuration, not to the moving data.

The saved file names every installed plugin at its current version as a requirement. Loading that same file back therefore never asks for an installation.

If a plugin cannot yet export its own part because it is too old for that, saving is refused — naming the plugin, instead of a generic failure. That is something you can fix yourself: update the plugin.

Takes a configuration file and immediately checks it against the same format the loader trusts. If it is unusable, you see the objections in plain words and nothing is replaced. If it is fine, the load dialog opens — plugin check and the list of what would be replaced included. Only when you confirm is the current state replaced, and a restore point of it is taken first.

Translations and uploaded icons are added to. A load replaces everything else; these two it adds to: what the file brings applies, and what your tenant has besides stays. A file from another tenant is not meant to take a language away from you.

Before every load and every restore, TrakState takes a restore point of the state about to be replaced — from the template store on, also before a template is added, updated or removed. Take a restore point now takes one by hand, for example before you start changing things yourself. The newest ten are kept; the eleventh pushes the oldest out.

Each row shows when the point was taken, why, by whom and how large it is.

  • Download fetches that point as an ordinary configuration file.
  • Restore… puts it back. It is the same load as above: the dialog shows what would be replaced, and a restore point of the current state is taken first — so a restore can be undone by restoring that one. Demo data in the point comes back with it.

A restore is exact — translations and icons included. Unlike loading a file, afterwards the translations are exactly those the point had: ones added later are gone, ones changed later are back to the old text. The same holds for icons you uploaded. A text a board still shows stays on the Translations list, just untranslated. How many texts the restore set and removed is a line in the diagnostics panel. Already before the restore, the dialog says how many translations it takes away.

A configuration is not signed, and where a signature would be there is a rule:

A configuration may do nothing the person loading it could not do by hand.

It runs under your sign-in, through the product’s normal routes. There is no privileged path that a signature would have to protect.

Plugins are different. When a load installs a missing plugin, that goes through the plugin catalogue and checks the manufacturer’s signature against your trust anchor. An unsigned configuration never means an unsigned plugin.

It cannot be loaded into a plugin version whose import no longer understands the description. And it holds neither accounts nor logins: a file you hand on carries your setup, not your staff.