Why your gateway backup keeps growing

Two things about a .gwbk catch people out. It contains more than they expect in one direction, and far less than they expect in the other.

What is actually in the file

A gateway backup captures the gateway’s configuration: every project, tag configuration, authentication and security profiles, database connections, OPC and device connections, alarm pipelines, scripts, reports — and the image management library.

Most configuration is text and stays small. Almost everything that grows is binary, and it arrives by more than one route: the image library, images embedded directly into a Perspective view, and Perspective custom assets such as fonts, icons and themes, all of which the backup includes.

Where the image library physically lives changed between versions, though the backup consequence did not. On 8.1 an uploaded image is stored in the gateway’s internal database; on 8.3 images are stored as resources on the file system. Either way they are in the backup.

The rule is configuration, not location

It is tempting to reduce this to “anything in the data directory ends up in the backup”. That is not the rule, and believing it will mislead you in both directions.

What determines inclusion is whether the gateway owns the thing as a configuration resource. The image library is a configuration resource, so it is in. Runtime data the gateway also owns is not, even though it sits inside the data directory — on 8.1.9 and later, internal tag history, the alarm journal and the audit log were moved to a data/local tree specifically so they would stop riding along in backups.

That last point is worth knowing if you are on an older gateway. Before 8.1.9 internal historian data lived under data/modules, which is included. If you are running an early 8.1 and the backup file is inexplicably large, that is the first place to look.

The direction that surprises people more

A gateway backup is a configuration backup. It is excellent at that, and it was never the other thing.

If your tag history is in an external database, the backup stores the connection — address, driver, credentials — and none of its contents. If you are on 8.3 using the built-in Core Historian, there is no database connection to store at all: it is an embedded time-series store writing to the gateway’s own disk, and Inductive Automation documents that module data directory as not added to the .gwbk. An integrated backup for it is planned, but as of Ignition 8.3.8 the guidance is still a manual filesystem copy with the gateway stopped.

The failure mode this creates is specific and bad. A site takes nightly gateway backups, considers itself protected, loses the history store, and discovers that years of trend data were never inside the file they were dutifully copying. The gateway configuration comes back quickly. The history does not come back at all.

Two other things are worth separating, because they are easy to conflate. Data held in other programs, files you added manually to the install directory, are not in the backup. Separately, restoring onto an existing gateway does not replace modules, license grants or redundancy settings. The Tag Reference Store sits in one list or the other depending on version: on 8.1 it is documented as not included in backups from 8.1.34, and on 8.3 it appears in the not-replaced-on-restore list. Those are different lists, and a rebuild from bare metal still means reinstalling modules and re-licensing.

Size costs more than disk

Inductive Automation puts a typical backup and a typical restore at under a minute each, and for most gateways that is accurate. The costs of a large file show up around the edges instead.

Retention multiplies it. Scheduled backups keep a configured retention count, deleting older files to make room. Whatever the file weighs, it weighs that much once per retained copy.
Transfer. Backups get copied between sites, sent to integrators, and pulled down over plant links that were not built for it.
Habit. A backup that takes long enough to be annoying is a backup people start skipping, and that is a process failure rather than a technical one.

Nothing prunes the image library for you. An image stays in the library, and therefore in every backup, whether or not any project still references it. There is no cleanup prompt and no unreferenced-image report, so the library grows until somebody deliberately curates it — and nothing in Ignition ever suggests that anybody should.

Where this bites hardest

Any workflow where non-technical users add images to the gateway on a regular basis will grow the backup steadily, because the upload rate is set by people rather than by engineering. Digital signage is the clearest case: a plant putting up a dozen photos a month is adding to every future backup, and nobody involved in uploading a photo is thinking about backup size.

This is why Company News (Ignition 8.3+) writes media to its own location on the gateway filesystem, outside the Ignition data directory, so it is never held as a gateway configuration resource. The trade is explicit and worth stating plainly: because the images are not gateway configuration resources, a gateway backup does not contain your signage, so the module ships its own export — a single ZIP holding the slide library and every image it references, downloadable from the Gateway configuration page and restorable through the matching import.

Neither arrangement is free. Media held as gateway configuration resources means one backup covers everything and that backup keeps growing. Media held outside means the backup stays flat and you have a second thing to remember. What matters is knowing which arrangement you have, because the failure mode of assuming wrongly only reveals itself during a restore.

Worth checking today

Two questions, and you can answer both this afternoon. How big is your most recent gateway backup, and how big was it a year ago? And if the history store were gone tomorrow, what would you restore tag history from? The first tells you whether anything is accumulating. The second tells you whether you have a backup strategy or half of one.

Common questions

Does an Ignition gateway backup include historian data?

No. If tag history is in an external database, the backup captures the connection rather than the contents. On 8.3 the built-in Core Historian writes to the gateway disk and is also not in the backup, and as of Ignition 8.3.8 an integrated backup for it is not yet available. One exception applies to older gateways: before 8.1.9, internal historian data lived under data/modules and was included.

What is actually inside a .gwbk file?

Gateway configuration: projects, tag configuration, authentication and security profiles, database connections, OPC and device connections, alarm pipelines, scripts and reports, along with the image management library and Perspective custom assets such as fonts, icons and themes.

What is not included?

Data held in other programs, and files added manually to the install directory. The Tag Reference Store sits in one list or the other depending on version: on 8.1 it is documented as not included in backups from 8.1.34, and on 8.3 it appears in the not-replaced-on-restore list. Separately, restoring onto an existing gateway does not replace modules, license grants or redundancy settings, so a rebuild still means reinstalling modules and re-licensing.

Why does the backup file keep getting bigger?

Most configuration is text and stays small. Binary content is what grows: the image library, images embedded into Perspective views, and Perspective fonts, icons and themes. Nothing prunes the image library automatically, so it grows until somebody deliberately curates it.

Do uploaded signage images bloat the backup?

They do if the images are held as gateway configuration resources. Company News writes media to its own location on the gateway filesystem instead, so a gateway backup does not grow with the slide library. The trade is that the backup also does not contain the signage, so the module provides a separate export and import for it.