Data does not always reach the historian in the order it was measured. A cellular link drops, a collector is restarted, or a field buffer holds hours of readings until connectivity returns. Backfill is the act of inserting that older data into the archive after newer data has already been stored. This guide explains what backfill is, why it is harder than a normal live insert, and the timestamp and recompression problems it creates.
Historian Backfill in one line: Historian backfill is the insertion of historical values into the archive after the fact - after the moment they were measured has already passed, and often after later data is already stored. It fills gaps left by outages or buffered telemetry, but forces the historian to reorder, revalidate, and sometimes recompress the affected time range.
During normal operation a historian receives values whose timestamps march steadily forward. Each new point is the latest one, so the archive can simply append it to the end of the current archive block and let the compression algorithm decide whether to keep it. Backfill breaks that assumption. A backfilled point carries a timestamp that falls before the last value already written, so the historian cannot just append - it must locate the correct position in an already-closed region of the archive and splice the value in.
This is why backfill is often called an out-of-order or historical insert. The transport that delivered the data is a separate concern: store-and-forward buffering on an RTU is how the old readings survived the outage, but backfill is what the archive does with them once they arrive. A device can forward a perfect timestamped backlog and the historian can still handle the insert poorly if it was not designed for it.
Some historians accept backfill freely into any past time range; others only allow it within a limited window before the archive is sealed and treated as read-only. Knowing which behavior your platform has matters, because a link that has been down for days may deliver data that falls outside the writable window and gets silently rejected.
The whole value of backfill depends on the buffered data carrying its original measurement timestamps rather than the time it happened to arrive. If a device stamps the backlog with the recovery time, every reading lands in one clump at the moment the link returned, which is worse than a gap because it fabricates a history that never happened. Correct backfill preserves the source timestamp so each value drops back into its true position on the timeline.
Deadband and swinging-door compression add a subtle complication. Compression decides whether to keep a point by comparing it to its neighbors, so inserting values in the middle of an already-compressed span can change which points should have been retained. A well-behaved historian recompresses the affected interval after a backfill so the reconstructed trend still honors the deviation bound. A naive one leaves the region inconsistent, with the backfilled samples stored raw next to compressed live data.
Order also matters for anything computed from the raw stream. Calculated tags, totalizers, and rolling aggregates that already ran across the gap produced results from incomplete data. After a backfill those derived values are stale and, if the historian supports it, need to be recalculated over the newly complete range. Ignoring that leaves a totalizer or daily total that never accounts for the recovered hours.
Remote oil and gas sites live on links that fail routinely - a congested cellular tower at a wellpad, a satellite path lost to weather, a solar site that browns out overnight. For a cloud SCADA platform, backfill is the difference between a clean continuous history and a record riddled with holes every time a site went dark. The edge device buffers timestamped readings, and when it reconnects the cloud archive backfills them so trends, allocation, and compliance reports reflect what actually happened.
In practice this means an operator can lose a connection to a tank battery for six hours, and after the link returns the daily production and tank levels reconstruct as if nothing was missed, because each buffered sample was inserted at its true time. That continuity is what makes custody and allocation figures defensible even when the network was not.
Merobix is built around this reality. Field gateways hold data through outages and the platform accepts the backfill into the correct time positions, recompressing and revalidating the affected span rather than dumping the backlog at the reconnect instant. For operators watching remote wells and pipelines, that turns an unreliable link into a reliable historical record.
Store-and-forward is the transport mechanism: a field device buffers timestamped readings while its link is down and sends the backlog when it returns. Backfill is what the historian does with that backlog - inserting the old values into the archive at their original timestamps, behind data that may already be stored. One is how the data survives the outage; the other is how the archive absorbs it afterward.
It can if the historian does not handle it correctly. Deadband and swinging-door compression choose which points to keep based on neighboring values, so inserting samples into an already-compressed span can leave the region inconsistent. A well-designed historian recompresses the affected interval after a backfill so the stored trend still respects its deviation bound; a naive one leaves raw backfilled points sitting next to compressed data.
The purpose of backfill is to reconstruct what actually happened during an outage. If the buffered readings are stamped with the recovery time instead of their measurement time, every value piles up at the reconnect instant and fabricates a false history. Preserving the source timestamp is what lets each recovered sample drop back into its true position, so trends and totals reflect reality.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.