Losing a historian is not like losing a live display that repaints in a moment; the data that was not written while the server was down may be gone for good. To protect against that, many plants run a historian mirror, where the same stream of samples is written to two independent archive servers at once, so the loss of one leaves a complete copy on the other. It is a data-level form of resilience that lives inside the historian's write path rather than in a generic server failover. This page explains how a mirror splits the collector's stream to two archives, how that differs from an ordinary redundant server pair, and what the write path looks like when both members are healthy.
Historian mirror in one line: A historian mirror is a configuration in which a collector sends the same data stream to two separate historian archive servers, each of which stores a full, independent copy of the samples. Because both archives are complete, either one can answer queries on its own and the system survives the loss of either server without a data gap. It is archive-level duplication of the write path, so the redundancy is in the stored data itself rather than only in a switchover between application servers.
In a mirrored historian the point of duplication is the collector, the component that gathers samples from controllers, OPC servers, or the SCADA system. Instead of forwarding each sample to a single archive, the collector sends it to two configured archive destinations, so both servers receive the same tag, timestamp, value, and quality. Each archive then independently applies its own compression, indexing, and storage, and the result is two archives that hold the same information even though their files are not byte-for-byte identical. The mirroring is logical, at the level of samples, not a block-level disk copy.
Keeping the two write paths independent is what gives the arrangement its value. The two archive servers usually run on separate machines, ideally on separate power and network, so a fault that takes one down, whether a disk failure, a crash, or planned maintenance, does not touch the other. Because the collector holds a store-and-forward buffer, a brief loss of connectivity to one archive does not immediately create a divergence; the collector keeps buffering for the unreachable member and continues writing to the reachable one, then delivers the buffered samples once the connection returns. That buffering is what makes short outages transparent rather than data-losing.
The write path is designed so that neither archive depends on the other to accept data. Each acknowledges the collector on its own, and the collector tracks confirmations per destination. This means one archive can be slow or briefly offline without stalling writes to the other, which is important during recovery when one member is catching up. The tradeoff is that the two archives can drift apart during an outage, which is why a mirror always pairs with a way to reconcile them once both are back.
General SCADA redundancy usually means a redundant server pair or a hot standby, where two application servers exist but one is active and the other waits to take over the same role, often sharing or replicating state so the switch is seamless. That model protects the service, the availability of a running server, and it is about which node is in charge at any moment. A historian mirror is a different kind of protection because its concern is the durability of the stored history, and both members are simultaneously and fully populated rather than one serving while the other stands by.
The practical consequence is that a mirror gives you two live copies of the data that are both queryable at the same time, not merely a spare that becomes useful only after a failover. You can point reporting at one mirror and interactive trending at the other to spread load, and if one server is lost, queries that were using it simply move to the surviving copy with no gap in history. In a standby-only model the standby's archive is only as current as the last replication, and its purpose is to resume the role, whereas a mirror's second archive is a first-class store in its own right.
These models are not mutually exclusive, and larger sites combine them, running each historian as a redundant pair and also mirroring the archive to a second location. But it helps to keep the concepts distinct: server redundancy answers what keeps running when a node fails, while mirroring answers where a complete second copy of the data physically lives. Understanding that the mirror duplicates the write path, not just the server role, is the key to reasoning about its recovery behavior and its consistency guarantees.
Mirroring fits naturally into distributed operations where the two archives can sit in different failure domains. A common pattern places one archive near the process, for fast local queries and short network paths from the collectors, and the second at a central data center or in a cloud region, so a site-level event such as a power loss or a fire does not take both copies at once. The collector writes to both, and each side serves the audience closest to it, with the remote copy doubling as an off-site safeguard.
For teams doing cloud-based monitoring across many sites, a mirror is one of the cleaner ways to get durable history without depending on a single link staying up. Because store-and-forward buffering covers brief disconnects to either destination, the mirror tolerates the intermittent connectivity that remote sites often have, and it fills the gaps once links recover. The central mirror then holds a consolidated copy that a monitoring team can query even if a particular site is temporarily unreachable, while the site retains its own local archive for on-premises use.
The main operational commitment a mirror asks for is discipline about reconciliation and verification. Because the two archives can diverge whenever one member is offline, a mirror is only as trustworthy as the process that catches those divergences and copies the missing data back so the members match again. Running a mirror therefore means owning both the healthy dual-write path described here and a reliable way to detect and repair divergence after an outage, so that either copy can be relied on to be complete.
No. A redundant server pair protects service availability by keeping a standby ready to take over the active role, while a historian mirror protects the data itself by keeping two full, independent archive copies that are both live and queryable. In a mirror the collector writes to both archives at once, so neither is merely a spare. Many sites use both together, mirroring the archive and also running each server as a redundant pair.
The collector keeps writing to the surviving archive and buffers samples destined for the offline member using store-and-forward. Queries that were served by the failed server move to the surviving copy with no gap in history, since both archives are complete. When the failed server returns, the buffered data is delivered and a resync reconciles any divergence that occurred while it was down.
Not usually. Mirroring duplicates the logical stream of samples, so both archives hold the same tags, timestamps, values, and quality, but each applies its own compression, indexing, and file layout independently. The copies are equivalent in the data they contain rather than identical at the disk level, which is why reconciliation compares sample coverage over time rather than comparing files directly.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.