A mirrored historian only lives up to its promise if the two copies actually match, and they stop matching the moment one member goes offline while the other keeps recording. Bringing the two back into agreement is the job of a mirror resync: the pair figures out which stretch of time one member missed and copies the missing samples across so both archives are complete again. It is a specific operational procedure, distinct from deciding which node serves queries, and getting it right is what lets an operator trust either copy afterward. This page walks through how divergence happens, how the resync detects and fills the gap, and how to confirm the two members truly agree.
Historian mirror resync in one line: A historian mirror resync is the process of reconciling two mirrored archives after one of them was offline, by identifying the time window during which they diverged and copying the missing samples from the healthy member into the one that fell behind. The pair detects the divergence, transfers the missing archive data for the affected tags and time range, and then verifies that both members now hold the same coverage. It is how a mirror recovers a complete, consistent second copy after an outage rather than living with a permanent gap.
Divergence starts whenever the collector can write to one archive but not the other. A server crash, a network partition, planned maintenance, or a full disk on one member all produce the same outcome: for some window of time, one archive received samples and the other did not. Store-and-forward buffering on the collector hides short interruptions by holding samples for the unreachable member and delivering them when the link returns, but if the outage outlasts the buffer, or if the member was down rather than just unreachable, the two archives are left with a genuine gap between them that must be repaired directly.
Detecting exactly what is missing is the heart of the procedure. The system compares the two members over time to find where their coverage differs, which member has the samples the other lacks, and for which tags. Rather than comparing every raw sample one by one, a resync typically works from coverage information such as the earliest and latest data present per period, or per-partition markers, to bound the divergence window quickly, then examines that window in detail. The result is a clear picture of the gap: the healthy member is the source of truth for the affected range, and the recovered member is the destination that needs filling.
It is important to recognize that the gap can be one-sided or overlapping. Usually one member simply missed a stretch while the other stayed current, so the direction of copy is obvious. But if both members were down at different times, or if a collector delivered buffered data to one but not yet the other, each could hold samples the other lacks, and the reconciliation has to copy in both directions to make them equal. A good resync handles that by treating the union of both members' data as the target coverage that each must end up holding.
Once the divergence window and direction are known, the resync copies the missing samples from the source member into the destination for the affected tags and time range, preserving their original timestamps, values, and quality rather than restamping them with the copy time. Because it is writing history into a past window, the destination treats the incoming data as backfill, inserting it into the correct archive partitions and updating its indexes so the recovered range becomes queryable. Depending on volume, this can be an I/O-heavy operation, so it is often paced or scheduled to avoid competing with live collection, and it can run while both members continue recording current data.
Verification is what turns a copy into a trustworthy resync. After the transfer, the pair rechecks the previously divergent window to confirm both members now report the same coverage, ideally down to matching sample counts or per-period markers for the affected tags. A resync that copies data but never confirms equality can leave a silent shortfall, for example if some tags were missed or a partition boundary was mishandled, so the consistency check is not optional. Many operators run a query on both members over the recovered window and compare the results as a final sanity check before declaring the mirror whole again.
A resync is deliberately different from a failback decision. Failback is about which node resumes serving after a switchover, a question of role and traffic direction. A resync is about the data itself, ensuring that whichever member serves, its archive is complete. It is also narrower than a full disaster recovery, which rebuilds a lost server from backups; a resync assumes both members exist and are mostly current, and it only needs to reconcile the delta from a bounded outage. Keeping these three ideas separate avoids the trap of assuming that a successful failover also means the data has been reconciled, when in fact the resync still has to run.
In distributed setups where one mirror sits on-site and the other in a central or cloud location, resyncs are a routine consequence of the intermittent links those sites tend to have. A remote plant may lose its uplink for hours, during which the local archive stays current and the central copy falls behind, and the resync that follows simply copies the interval the central member missed once connectivity returns. Because these events are expected, it helps to treat resync as a monitored, mostly automatic activity, with alerting when a divergence window grows large or when a resync fails to complete, rather than as a rare emergency.
Bandwidth and timing deserve planning in these topologies. A long outage can leave a substantial window to copy, and pushing all of it across a modest link at once can saturate the connection that the site also needs for live data. Pacing the resync, prioritizing the most important tags, or scheduling the bulk of the catch-up for off-peak hours keeps recovery from interfering with normal operations. The store-and-forward buffer on the collector shortens what the resync has to do for brief interruptions, so sizing that buffer generously reduces how often a full reconciliation is even needed.
For a monitoring team that relies on a central mirror to see across many sites, the resync is what lets them trust the consolidated copy even when individual sites drop off. As long as each divergence is detected and repaired, the central archive converges back to a complete picture after every site outage, and reports run against it will not quietly under-report the periods a site was disconnected. The discipline that makes this work is the same one a mirror always demands: never assume the copies match, always verify that the recovered window is truly equal before relying on either member as complete.
It compares the two members over time to find where their coverage differs, using per-period or per-partition markers such as the earliest and latest samples present rather than checking every raw point. That comparison bounds the divergence window and shows which member holds the samples the other lacks. The healthy member becomes the source and the recovered member the destination for the copy.
No. Failback decides which node resumes serving queries and receiving load after a switchover, which is a question of role and traffic. A resync is about the data, copying the samples one member missed so both archives are complete. A failover can succeed without the data being reconciled, so the resync still has to run and be verified afterward.
It can, because copying a divergence window is I/O-heavy, but it is designed to run while both members keep recording current data. To limit impact, resyncs are often paced, prioritized by tag importance, or scheduled for off-peak hours, especially over constrained links to remote sites. Sizing the collector store-and-forward buffer generously also reduces how much a resync ever has to copy.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.