An OPC UA connection can recover after an outage while the historian still has a hole. Reconnection restores communication. It does not prove that every value generated during the interruption survived.
Preventing OPC UA data gaps starts with identifying which link failed. A typical path has three responsibilities: the source creates or exposes measurements, the collector receives them, and the historian stores them. Buffering at one layer cannot repair a loss that occurred earlier in the path.
Locate the interruption before choosing a recovery method
Consider a common architecture:
Device or PLC -> OPC UA server -> collector -> historian
If the device or OPC UA server stops producing values, the collector has nothing to recover unless the source keeps its own history. If the link between the OPC UA server and collector fails, recovery depends on server-side subscription queues, the subscription lifetime, client reconnect behavior, and any historical-access capability. If the collector continues reading but cannot reach the historian, a durable local buffer at the collector can protect those already collected messages.
These are different failures. Calling all of them a network outage leads to the wrong fix.
| Failure location | What may still exist | Recovery requirement |
|---|---|---|
| Device to OPC UA server | Values stored by the device or server, if any | Source history or a separate edge record |
| OPC UA server to collector | Notifications retained in subscription queues | Reconnect and republish before lifetime or queue limits are exceeded |
| Collector to historian | Messages already accepted by the collector | Persistent local buffering and confirmed forwarding |
Subscription queues cover short interruptions, not unlimited history
An OPC UA subscription can bridge a temporary communication break. Monitored items queue notifications, messages carry sequence numbers, and a client can request retransmission after reconnecting. This only works while the subscription remains alive and the necessary notifications remain in the server’s queues.
Queue depth matters. If a point changes faster than its monitored-item queue can hold, old or new values are discarded according to the queue policy. The overflow status tells a capable client that loss occurred. The subscription lifetime also matters because the server deletes the subscription and its monitored items when that lifetime expires.
Normal subscription queues are generally kept in memory. A server restart can remove them. OPC UA also defines durable subscriptions for longer interruptions and server restarts, but server and client support must be confirmed. Durable subscriptions are an optional capability, not something a historian engineer should assume is active.
Set the queue and lifetime from the fastest credible change rate and the longest interruption the design is expected to tolerate. Then check the revised values accepted by the server. Requested values are not proof of actual capacity.
Store and forward protects a different part of the path
Store and forward usually means that a collector writes accepted messages to local persistent storage before sending them upstream. If the historian or wide-area link is unavailable, collection can continue and the backlog can be forwarded later.
This protects data only when the collector can still reach the source. It does not reconstruct OPC UA notifications that the collector never received. Placing the collector or agent on the OT side of an unreliable WAN can therefore change the failure boundary: the local source link stays available while the buffered historian link is allowed to fail.
Size persistent storage for the worst expected outage, including peak update rates and the time needed to drain the backlog while new data continues to arrive. Monitor free disk space and backlog age. A full disk turns a recoverable interruption into permanent loss.
Why reconnecting is not the same as recovering
After reconnecting, an OPC UA 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 outage window empty.
A read of the latest value also does not fill the gap. It proves the current state only. If a temperature changed five times during the outage and the client reads one value afterward, the intermediate history is still missing.
To recover a longer window, you need one of these sources:
- Retained notifications that the client can republish.
- A durable subscription supported and configured on both sides.
- Historical data exposed by the OPC UA server and an explicit backfill process.
- A persistent edge or collector buffer that received the values during the outage.
Without one of those records, the missing values cannot be recreated reliably. Interpolation may help a report, but it must remain distinguishable from observed data.
Build a recovery test around evidence
Test the complete path before relying on it in production. Use a safe point with a known update pattern, then interrupt each network segment separately.
Record the last source timestamp and subscription sequence before the outage. Confirm whether the source keeps changing and the persistent backlog grows. After recovery, check for sequence gaps, overflow, duplicates, late arrivals, and backlog drain time.
Compare the historian with the expected source record for the outage window. For periodic signals, compare expected and actual sample counts. For change-based signals, compare source events or server history with stored transitions. Keep source and receipt time where practical so late recovery can be separated from real-time ingestion.
Applying this design to TDengine
TDengine TSDB-Enterprise can ingest OPC UA data through taosX, with taosX-Agent available when the OPC UA server is reachable from an OT-side host but not directly from taosX. That placement can keep the agent-to-source link local while data travels from the agent to taosX across the less reliable network.
For OPC UA real-time collection tasks using taosX-Agent, TDengine documents a Store and Forward option called Cache Real-time Data. It is disabled by default. When enabled, the agent writes collected messages to a disk-based persistent queue, resumes from its last confirmed breakpoint after a network recovery or agent restart, and removes cache files after confirmed delivery. The feature covers interruptions between taosX-Agent and taosX while the agent continues to collect from the source.
That boundary is important. TDengine’s local cache does not by itself recover values missed when the agent cannot reach the OPC UA server. For that failure, recovery still depends on OPC UA subscription retention, server history, or another source-side record.
Use the cache directory on a monitored disk with enough capacity for the planned outage window. TDengine notes that persistence adds write and read work, so include recovery latency and backlog drain time in the acceptance test.
Once the data reaches an industrial time-series database, verify completeness by timestamp range and point rather than by task state alone. The operating target should be explicit: maximum recoverable outage, permitted loss, maximum backlog age, and the evidence used to declare recovery complete.
For more on how subscriptions compare with periodic reads, see our guide to OPC UA polling versus subscription.
