Backup and Recovery
One database holds everything — plus the licence surprise that catches every restore to a new server.
Infohub's backup story is refreshingly simple: back up the SQL database and you have backed up Infohub. The model, configuration, calculated values, charts, dashboards, deployment layout, and log all live there.
Recovery is where the surprises are, and this article is mostly about those.
What to back up#
The SQL database. This is the system of record and the essential item.
%ProgramData%\Flow Software\Flow. Not strictly required — it is recreated by installation — but it contains the plugin packages under Config\Packages. Having the exact plugin versions the instance was running is genuinely useful during recovery, because a mismatch can cause connection properties to be misread. Back it up if it is convenient.
Nothing else. The binaries come from the installer. There is no separate content store to remember.
Backup schedule#
Standard SQL Server practice. What is specific to Infohub is the loss tolerance.
| Backup | Frequency |
|---|---|
| Full | Daily |
| Differential | Depending on size and window |
| Transaction log | Every 15–60 minutes, per your recovery point objective |
The question that sets the log frequency: how much manually entered data can you afford to lose?
Retrieved, aggregated, and calculated values can be rebuilt — the sources still have the raw data and Infohub will recompute. Manually entered values cannot. Targets, lab results, downtime reasons, sign-offs: the only copy was the one a person typed. That is what determines how often you need log backups, and it is usually a stricter requirement than people first assume.
Retention must outlive purge#
An easily missed interaction.
If event schemes purge after two years but backups are kept for one, then a two-year-old manually entered downtime reason is gone from the live database and from every backup. Nobody notices until an audit asks for it.
Check that backup retention exceeds your longest purge age, and that both satisfy any regulatory retention obligation. See Database Maintenance.
Test the restore#
A backup that has never been restored is a hypothesis.
Test it at least annually, and after any change to the backup process:
- Restore to a separate server — never over a working instance.
- Confirm Flow Config connects to it.
- Confirm the model is complete: measures, charts, dashboards.
- Spot-check values.
Doing this also rehearses the recovery procedure, which is worth more than the reassurance.
Restoring to a new server: the two things that catch everyone#
A restored database will not simply run somewhere else. Two pieces of identity are tied to where it was.
The Platform host name#
Flow Bootstrap claims the Platform whose host name matches the machine it is running on. A restored database still names the original server, so on the new machine nothing starts — no errors, no data, everything looking correctly configured.
Fix: correct the Platform's host name, or create a Platform for the new machine and place the service objects on it.
This is the single most common cause of a restored Infohub instance doing nothing.
The licence#
An Infohub licence is bound to an Instance ID. A restored copy on a different instance is not licensed, and unlicensed components do not run.
Arrange non-production licences before you need them. The classic failure is discovering during a disaster-recovery test — or during an actual disaster — that the restored instance will not run because it has no licence.
Request licences for your DR, test, and training instances as part of setting them up, not after they fail to start. Discuss the whole estate with Flow Software in one conversation. See Licensing Infohub.
Restore checklist#
For a restore to a different server:
- Install Infohub, matching the version the backup came from.
- Restore the database.
- Correct the Platform host name to the new machine.
- Apply a licence valid for this instance.
- Set the
Flow Bootstrapservice account, if integrated security is used anywhere. - Restore or reinstall the plugin packages, matching versions.
- Connect with Flow Config and verify the model.
- Review the connections. Credentials may need re-entering, and the new server may have different network access.
- Decide about consumers before deploying. See below.
- Deploy, and confirm values arrive.
Consumers: think before you deploy a restored copy#
Step 9 matters more than its position suggests.
A restored instance carries the original's consumers. Deploy it as-is and it will start publishing — to the production SQL warehouse, the production MQTT broker, the central Infohub instance — in parallel with the real instance.
For a test or DR restore, undeploy the consumers before deploying anything else, or the test instance corrupts production data.
The same caution applies to notification servers: a restored copy will happily email real recipients about a test instance's alarms.
A restored instance can write to production systems. Consumers and notification servers point at whatever the original pointed at. Undeploy or repoint them before deploying a restored copy for testing. This is the most damaging mistake available during a restore, and it is entirely avoidable.
What a restore does not recover#
Data since the backup. Retrieved values can be rebuilt by backfilling from the sources, which is one of Infohub's better properties — the historian still has the raw data.
Manually entered values since the backup. These cannot be recovered from anywhere. Whoever entered them will have to again, if they can remember.
Anything outside the database. Plugin packages, service account configuration, licences.
Disaster recovery planning#
Beyond backups, decide and write down:
Recovery time objective. How long can Infohub be unavailable? That determines whether you need a standby server ready or can build one when needed.
Recovery point objective. How much data loss is acceptable? That sets log backup frequency, and manual data is the binding constraint.
Who does it. A documented procedure someone other than its author can follow.
Where the licence comes from. Pre-arranged for the DR instance, or a defined route to obtain one urgently.
How sources are reached. A DR server in another location may not have network access to the plant historians. That needs establishing before it is needed.
That last point is frequently overlooked and can make a technically successful recovery useless.
Recovering from a bad change rather than a disaster#
Most real recoveries are not disasters — someone made a change that broke something.
Options, cheapest first:
Undeploy the affected object. Configuration is preserved and the damage stops immediately.
Fix forward. Usually correct for a configuration error, and quicker than a restore.
Restore a subtree from an export. If you exported before the change, importing it back is far less disruptive than a database restore. This is a good argument for exporting before any substantial restructuring.
Restore the database. The last resort, because it discards everything since the backup — including manual entries and any other work done in the interim.
Export before restructuring. An export of the area you are about to change takes a minute and gives you something concrete to compare against and to restore from. It is the cheapest insurance available for a large model change. See Importing and Exporting Models.
Diagnosing#
| Symptom | Cause |
|---|---|
| Restored instance does nothing | Platform host name still names the old server |
| Components will not start | No licence for this Instance ID |
| Test instance wrote to production | Consumers deployed on a restored copy |
| Test instance emailed real users | Notification servers deployed on a restored copy |
| Connection properties look wrong after restore | Plugin version mismatch |
| Connections fail on the new server | Credentials, or network access differs |
| Old manual data missing | Purged before the oldest retained backup |
| Restore succeeds, sources unreachable | DR location has no path to the plant network |