How to Verify Industrial IoT Data Recovery After a Network Outage

An industrial IoT connection is only fully recovered when the destination has received the records collected during the outage. To verify this, compare a known source sequence with the records stored downstream, then check missing IDs, duplicates, timestamps and backlog clearance. For a project using a Robustel EG5120 industrial edge gateway, run this test against the actual collection application and storage configuration. The checklist below is a proposed acceptance method, not a claim that every gateway configuration automatically preserves every reading.

Key Takeaways

• Measure recovery at the destination database or application, not just the gateway connection indicator.
• Use a stable record ID and preserve the original observation timestamp through replay.
• Test network loss, application restart and storage limits as separate failure cases.
• Agree on acceptable gaps, duplicate handling and recovery time before running the test.

In This Guide

• Define what successful recovery means
• Estimate the backlog and recovery time
• Run a repeatable outage test
• Capture an acceptance record

What should count as successful data recovery?

A dashboard can show a current reading while historical records are still missing. Define the evidence you need before disconnecting anything: which records should exist, where they should be stored, and how long the application may take to catch up.

For a bench test, use a controlled data source that produces one uniquely identified record at a known interval. Record a test-run ID, sequence number, observation timestamp, value and quality status. Combining the test-run ID with the sequence number prevents a restarted generator from accidentally reusing an earlier record identity.

Keep a reference log independent of the gateway. Reconcile its IDs with the final destination after recovery. Counts alone are insufficient: one missing record and one duplicate can produce the expected total.

Also define how the destination presents late data. A reading observed at 10:05 and received at 10:20 should retain both times where the data model permits. Historical replay should not silently masquerade as a fresh measurement.

How much data must the application retain?

Start with the record production rate and the outage duration you intend to tolerate:

Payload storage estimate = records per second × bytes per record × outage seconds.

For example, a test stream producing 10 records per second at 500 bytes per record generates 18,000 records, or 9 MB of payload, during a 30-minute outage. This is an illustrative calculation, not an EG5120 capacity benchmark. Database indexes, metadata, logs and the storage engine's overhead require additional space.

Recovery needs spare processing capacity too. If the destination can accept a sustained total of 50 records per second while 10 new records per second continue arriving, the net backlog reduction is 40 records per second. Under those assumptions, replaying 18,000 queued records takes about 450 seconds, or 7.5 minutes. Measure the actual rate with your payload, connection and destination limits.

Set a queue limit and an explicit overflow policy. Decide whether the application stops collection, rejects new records or removes older records when it reaches that limit. Make the event visible to the operator and include it in the acceptance report.

How do you run a repeatable outage test?

1. Capture a baseline. Record the gateway model, firmware, application version, queue settings and destination configuration. Run the reference stream with the connection available and verify matching record IDs downstream.
2. Interrupt only the test uplink. Keep the test source and gateway powered. Record the outage start time and confirm that the local collector continues receiving records. If a backup uplink is enabled, document whether this exercise tests failover or complete upstream loss.
3. Observe the queue. Record its depth, storage consumption and error state during the interruption. Distinguish a collector that has stopped receiving measurements from a publisher that is retaining measurements for later delivery.
4. Restore connectivity. Continue producing new records while the backlog is replayed. Measure the recovery interval, observe whether the queue shrinks, and check whether new data remains within the project's latency target.
5. Reconcile at the destination. Compare exact record IDs against the independent source log. List missing IDs, duplicate IDs, unexpected records and timestamp changes. Confirm that each exception has an explanation.
6. Repeat with a separate restart case. On a bench system, restart the collection application while records are queued. If power-loss retention is required, plan a separate controlled power-interruption test. A successful network-only test does not establish restart durability.

If the implementation uses Node-RED, check the actual context store. Node-RED's context documentation states that its default context is held in memory and cleared on restart. Its built-in filesystem store caches values and writes them periodically, every 30 seconds by default. A file-backed context setting therefore needs its own durability assessment; it does not by itself establish a complete transactional replay queue.

What should go in the acceptance record?

Use a table like this for every run. The example targets below are proposed starting points; the project owner should approve the actual limits.

Attach the configuration baseline and raw logs. Keep the first failed run as well as the successful retest: the difference explains what changed and helps another site reproduce the result.

Frequently asked questions about outage recovery

Does a restored network connection prove that all data arrived?

No. Verify the stored records in the destination application. The connection can be available while a queue is still draining or records have been rejected.

Does dual-SIM failover replace a local queue?

Treat them as separate design decisions. Test the configured failover path and decide what the application must do during any remaining period without a usable destination connection.

Should we accept duplicate records during replay?

Define the rule for each layer. You may allow repeated delivery attempts while requiring the final application to store or act on each record only once, using a stable identity and a tested deduplication rule.

Does this checklist guarantee zero data loss?

No. It establishes evidence for the specific configuration and failure cases tested. Longer interruptions, changed storage settings or a different application release can require a new validation run.

What should you do next?

Write a one-page test plan with the record rate, maximum outage, storage limit, restart requirement and recovery deadline. Use it to assess an EG5120-based deployment, and send configuration questions to Robustel Support. For the broader operational handover, read how to define an edge gateway recovery plan for remote sites.

About the Author

Mark, Technical Support Engineer at Robustel

Mark is a Technical Support Engineer at Robustel with hands-on experience in industrial networking and edge connectivity. He helps customers plan, deploy, configure, and troubleshoot industrial IoT solutions, including cellular routers, edge gateways, and LoRaWAN systems. His work spans technical support, product training, configuration review, and practical deployment guidance for reliable and repeatable field operations across global projects and long-term operational support.