Global – October 29, 2026 -- A restored OPC UA connection does not guarantee that the historian holds every value generated during an outage, because the three links in the data path (source, collector and historian) each lose data in different ways. Buffering at one layer cannot repair a loss that occurred earlier in the chain.
In the common architecture of device or PLC, OPC UA server, collector and historian, the first step is to find which link failed. If the device or server stops producing values, the collector has nothing to recover unless the source keeps its own history. If the collector cannot reach the historian, a durable local buffer can protect messages it has already collected. Treating all three as a generic network outage leads to the wrong fix.
Subscription queues bridge short breaks but are usually lost on server restart
An OPC UA subscription can survive a temporary break through monitored-item queues, sequence-numbered messages and client-requested retransmission. This works only while the subscription is alive and the notifications are still queued. If a point changes faster than its queue can hold, values are discarded according to the queue policy, and an overflow status tells a capable client that loss occurred. When the subscription lifetime expires, the server deletes the subscription and its monitored items.
Normal queues are generally kept in memory, so a server restart can remove them. OPC UA defines durable subscriptions for longer interruptions and restarts, but they are optional and both server and client support must be confirmed. Queue size and lifetime should be set from the fastest credible change rate and the longest tolerated interruption. The values the server actually accepts should then be checked, since requested values do not prove actual capacity.
Store and forward protects only the collector-to-historian link
Store and forward writes accepted messages to local persistent storage before sending them upstream, so collection continues while the historian or wide-area link is down. It does not reconstruct notifications the collector never received. Placing the collector or agent on the OT side of an unreliable WAN keeps the source link local and lets the buffered historian link fail.
Storage must be sized for the worst expected outage at peak update rates, plus the time to drain the backlog while new data keeps arriving. Free disk space and backlog age need monitoring, because a full disk turns a recoverable interruption into permanent loss.
Reconnecting can leave the outage window empty
After reconnecting, a client may reactivate its session, transfer a subscription, republish missed messages or create a new subscription. The last option restores current collection but may leave the gap unfilled. A read of the latest value does not help either: if a temperature changed five times during the outage and the client reads once afterward, the intermediate history is still missing.
Longer windows can be recovered only from retained notifications, a durable subscription configured on both sides, server-exposed history with an explicit backfill process, or a persistent edge or collector buffer. Interpolated values must remain distinguishable from observed data.
TDengine's Cache Real-time Data option is disabled by default
TDengine TSDB-Enterprise ingests OPC UA data through taosX, and taosX-Agent can run on an OT-side host when the server is not directly reachable from taosX. For real-time collection tasks, the agent's Cache Real-time Data option writes messages to a disk-based persistent queue. It resumes from its last confirmed breakpoint after a network recovery or agent restart and deletes cache files after confirmed delivery.
The cache covers only interruptions between taosX-Agent and taosX. Values missed when the agent cannot reach the OPC UA server still depend on subscription retention, server history or another source-side record. TDengine notes that persistence adds write and read work, so recovery latency and backlog drain time belong in acceptance testing.
Recovery tests must compare the historian against source evidence
The recommended test interrupts each network segment separately on a safe point with a known update pattern. Engineers record the last source timestamp and subscription sequence before the outage. After recovery they check for sequence gaps, overflow, duplicates, late arrivals and backlog drain time. Periodic signals are verified by comparing expected and actual sample counts, and change-based signals by comparing source events or server history with stored transitions.
Completeness should be verified by timestamp range and point rather than by task state alone. The operating target should state the maximum recoverable outage, permitted loss, maximum backlog age and the evidence used to declare recovery complete.