When a historian collector reconnects after an outage, it faces two jobs at once: it has a backlog of buffered history to deliver, and it is still collecting fresh values that need to arrive too. How it sequences those two streams, called recovery ordering, determines whether the archive ends up clean and chronological or scrambled with out-of-order and delayed writes. This page explains how a collector drains its buffer while still handling live data, whether it forwards the backlog oldest-first or newest-first, and how flushing the buffer is throttled so the recovery does not overwhelm the archive it is trying to catch up with.
Store-and-forward recovery ordering in one line: Store-and-forward recovery ordering is how a reconnecting collector sequences the delivery of its buffered backlog alongside the live values it is still collecting. Collectors generally forward buffered data oldest-first so the archive fills in chronologically, while continuing to accept live values, and they throttle the flush so the catch-up does not overwhelm the archive. The goal is a complete, correctly ordered archive without the recovery itself causing overload or scrambled timestamps.
The moment a collector's link to the archive is restored, it holds a backlog of buffered values spanning the outage, and it is simultaneously still gathering new values in real time. Recovery ordering is the policy that decides how these two streams are interleaved and delivered. It is a genuinely tricky problem because the two streams overlap in a way that can confuse the archive: the backlog carries old timestamps from during the outage, while the live stream carries current timestamps, and delivering them carelessly can produce writes that jump backward and forward in time in a way the archive was not designed to handle gracefully.
The reason this deserves its own attention, separate from the buffer itself and from how a client backs off before reconnecting, is that the recovery behaviour is what actually gets the outage data into the archive correctly. A collector could have a perfectly sized buffer that held every value through the outage, and still corrupt the recovery if it dumped that backlog in the wrong order or all at once. Recovery ordering is the discipline that turns a held backlog into a clean fill of history rather than a mess of delayed, out-of-order writes that complicate every later query and calculation.
The stakes are highest for anything that reads history in time order or aggregates over intervals. A daily total, a trend, or any calculation that walks the archive chronologically depends on the data arriving in a way the archive can index correctly by timestamp. If the recovery scatters the backlog without regard to order, the archive may store the values but present them awkwardly, and downstream consumers that assumed a tidy chronological record can produce wrong results. Getting recovery ordering right is therefore about protecting not just the presence of the data but its usability.
The natural and common approach is to forward the buffered backlog oldest-first, replaying the outage period in chronological order so the archive fills in from the start of the gap toward the present. Oldest-first draining means the archive's record grows forward in time as the backlog is delivered, which matches how the data was originally produced and how the archive expects to be written. It also means that at any point during recovery, the archive has a contiguous, correct history up to some point in the outage, with the remaining gap shrinking from the far end, rather than a patchwork of scattered points.
While the backlog drains, the collector still has to handle the live values it continues to collect, and how it reconciles the two matters. One approach is to give the live stream priority so current data is never delayed by the catch-up, while the backlog fills in behind it; another is to complete the chronological drain so history is rebuilt strictly in order. Either way, the collector has to avoid producing writes that the archive cannot order, which is why the timestamps carried with each value are essential: as long as every value, backlogged or live, carries its true collection time, the archive can place it correctly even if delivery is not perfectly sequential. The design aim is to deliver the backlog without ever losing or delaying the live present unacceptably.
The interaction with live data is exactly why recovery ordering is more than just replaying a buffer. If the collector simply blasted its entire backlog first and ignored live collection until done, current data would stall for the length of the recovery, which for a long outage could mean the site appears frozen well after the link is back. Conversely, if it only ever forwarded live data and never drained the backlog, the outage gap would never fill. A workable recovery ordering does both, delivering the backlog steadily while keeping the live stream flowing, so the archive ends up both current and complete.
A subtle danger at reconnect is that a collector with a large backlog can overwhelm the archive by trying to deliver everything as fast as possible. If many values arrive in a burst, or if many collectors across a fleet reconnect at once after a shared network event, the sudden flood of catch-up writes can overload the archive, slow it for everyone, or even trigger further failures. Flush throttling is the mechanism that paces the drain: the collector forwards its backlog at a controlled rate rather than as fast as the link allows, so recovery is steady and the archive keeps up with both the catch-up and the ongoing live load from every source.
Throttling is a balance, because draining too slowly means the outage gap lingers unfilled for longer than necessary, while draining too fast risks the overload it is meant to prevent. A sensible recovery paces the flush to make good progress on the backlog without pushing the archive past what it can absorb alongside normal operation, and it may adapt the rate to how the archive is coping. The point is that the recovery should be a controlled catch-up that converges on a complete, current archive, not a stampede that trades the outage problem for an overload problem.
This throttling discipline becomes essential at the scale of a SCADA fleet, where a single upstream event, such as a central network hiccup, can knock out the archive link for many field collectors at once and then, when the link returns, have all of them try to flush their backlogs simultaneously. Without throttling, the recovery of one outage can cascade into an overload that looks like a second outage. A platform such as Merobix manages recovery so that many collectors reconnecting together drain their buffers in an orderly, paced way that fills each gap chronologically without overwhelming the archive. The result is that after even a widespread outage the historian converges on a complete, correctly ordered record, which is precisely what operators need to trust the data from a large distributed system.
Collectors generally forward the buffered backlog oldest-first, replaying the outage period in chronological order so the archive fills in from the start of the gap toward the present. Oldest-first draining matches how the data was produced and how the archive expects to be written, and it means the archive holds a contiguous, correct history up to some point in the outage at every stage of recovery, with the remaining gap shrinking from the far end.
It handles the two streams together, either giving the live stream priority so current data is never held up while the backlog fills in behind it, or draining the backlog steadily alongside live collection. Because every value carries its true collection timestamp, the archive can place both backlogged and live data correctly even when delivery is not strictly sequential. The design aim is to fill the outage gap without freezing the live present.
Flush throttling paces how fast a collector forwards its buffered backlog at reconnect, delivering at a controlled rate rather than as fast as the link allows. It prevents a large backlog, or many collectors reconnecting at once after a shared outage, from flooding the archive with catch-up writes and overloading it. Throttling balances filling the gap promptly against overwhelming the archive, so recovery converges steadily on a complete, current record.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.