A recovery drill for an Ignition gateway
Almost every site we visit has gateway backups. Very few have ever restored one anywhere other than in an emergency, which makes the backup a belief rather than a fact.
What the drill is for
A recovery drill is not a test of whether the backup file is corrupt. It tests whether the set of things you hold is sufficient to produce a working gateway, and whether the people involved know the order to do it in.
Those are different questions from “do we have a backup”, and they tend to have less comfortable answers. The value is entirely in finding that out on a Tuesday.
Two settings to get right before you restore
This section is first because getting it wrong is worse than not doing the drill at all.
A restored gateway comes up with the configuration it was given, which means production database connections, production Gateway Network settings, and the same system name. Left alone, it will start writing into your production tag history, alarm journal and audit log, because as far as the database is concerned it is the same gateway.
Ignition provides for this on the restore screen. Restore Disabled brings the backup’s contents in disabled — projects, database connections, tag providers, historians, alarm journals, Gateway Network settings and more — so you can re-enable them one at a time after repointing them. Override Gateway Name lets the drill gateway carry a different system name, which matters because a great deal in Ignition is keyed on that name rather than on the hostname. Use it on the drill gateway only — Inductive Automation advises against renaming an established production gateway, because a rename can break dependencies that were built on the old name.
One honest caveat: Restore Disabled does not cover every driver. Inductive Automation scopes the disabled device connections to a specific short list, so a modern Logix or Modbus connection can still come up live — the short list covers only legacy CompactLogix, BACnet/IP and the device simulator. Put the drill machine on an isolated network rather than relying on the checkbox alone.
What the backup file does not carry
Two separate lists, and they are easy to merge by accident.
Not in the file: your tag history. On an external SQL historian that data is in the database. On 8.3’s Core Historian it is on the gateway’s own disk under the module data directory, which Inductive Automation documents as not added to the backup. Also excluded are data held in other programs and files you added manually to the install directory. We went through what does and does not accumulate in that file in why your gateway backup keeps growing.
Not replaced when restoring onto an existing gateway: modules, licence information and grants, redundancy settings, and the Tag Reference Store.
For a bare-metal rebuild the relevant facts are simpler and come from elsewhere: the installer decides which modules are installed, and licensing lives outside the backup file. Since 8.3.8 the installer also offers a Restore from Backup step, applied on first startup — so a rebuild is install-with-modules-and-restore in one pass, then licence separately.
That gives you the pre-drill checklist. Confirm you can lay hands on the gateway backup, the Ignition installer at a compatible version, the module files at the right versions, the licence information, the database backup, and the credentials the gateway needs for its device and database connections. Version matters: a gateway backup from before 8.1 cannot go straight onto 8.3, and has to be taken to 8.1 first.
Then look at whether it actually works
Restore onto a spare machine or virtual machine, with the two settings above applied. Then check the things a successful restore message does not tell you.
- Do the modules load and run — in trial mode, which is the correct expectation here?
- Does a project open, and do screens render once you point them at test data?
- Do database connections come up once you have repointed them at a test database?
- Do device connections come up after you repoint them, or were they relying on something about the original host?
- Is tag history queryable — and from where?
On licensing, be deliberate. A licence key allows a limited number of simultaneous activations, so activating your production licence on the drill machine means unactivating production first. Do not do that to prove a checklist item. Modules run in trial mode for two hours at a time and the timer can be reset as often as you like, which is more than enough for a drill.
The history question is the one the drill exists to surface. On a restored gateway with no database attached, the trends are empty and the configuration is perfect — which is exactly the shape of the real outage people are unprepared for.
Time it, and write down what you needed
Two artefacts come out of a good drill, and neither is the restored gateway.
The first is a duration: from the moment you decided to rebuild to the moment somebody could use a screen. That is the number you can honestly give a plant manager, and it is usually longer than the file-restore estimate because the file restore was never the slow part.
The second is a list of everything you had to go and find. A password nobody had written down. A module version that was not on the shelf. A firewall rule. Each is a delay you have now paid for once, at a time of your choosing.
Licensing deserves its own line on that list, because the real-outage case has a documented answer worth knowing in advance. If the old machine is gone you cannot unactivate it, and Ignition provides an Emergency Activation mode that licenses temporarily for seven days. Knowing that beforehand takes a phone call off the critical path.
Questions worth answering while you are there
- What is your actual recovery point — how much would you lose given how often backups run? And separately, how far back can you reach, given the retention count?
- Who can do this, and is that more than one person?
- Does anything reference this gateway by system name? Remote alarm journals, EAM agents, Edge sync, Gateway Network policies and history all key on it, which is why Override Gateway Name exists.
- Does anything need the original hostname or address — certificates, firewall rules, device configuration?
- If the historian is embedded on the gateway rather than in a separate database, what is the plan for that data specifically?
None of this requires new software or a project. It requires an afternoon, a spare machine and a willingness to find out. The sites we have seen come through an outage well are almost never the ones with the most elaborate backup arrangement — they are the ones where somebody has done this before and still has the notes.
Common questions
Does an Ignition gateway backup include tag history?
What else do I need besides the .gwbk to rebuild a gateway?
How do I restore a backup for testing without affecting production?
Can I activate my Ignition licence on a test machine for a drill?
What happens to licensing if the original machine is gone?
References
- Inductive Automation — Gateway Backup and Restore: Restore Disabled and Override Gateway Name
- Inductive Automation — Licensing and Activation: simultaneous activations, trial mode, Emergency Activation
- Inductive Automation — Gateway Folder Structure: what is added to a .gwbk
- Inductive Automation — System Name Usage Reference
- Inductive Automation — Installing and Upgrading
- Inductive Automation — Gateway Settings: backup schedule and retention count
Never restored a gateway outside an emergency? We work on Ignition systems across California’s Central Valley, and running the first drill alongside somebody who has done it before is a short piece of work with a long payback.
Contact us