Choose a representative test window before opening the recovered data. Include a quiet operating period, a known load transition, and a period containing an already documented interruption if available. The purpose is coverage of known conditions, not creating a new event on live equipment. Agree who may see the data and how long the isolated test copy may remain available.<\/p>\n
Preserve the recovery set and its provenance<\/h2>\n
Keep the original backup read-only where the platform supports that workflow. Make a working copy for the exercise and record its filename, creation time, source system, size, and approved storage location. If a trusted checksum is supplied, compare it before restoration. A matching checksum supports byte-level identity; it does not prove the records are correct, the software is safe, or the restore will succeed.<\/p>\n
A backup timestamp can mean job start, job finish, snapshot creation, or export creation. Record the meaning used by the software. Also record the last measurement timestamp known to be included. Otherwise, a team may believe a backup protects the final hour of operation when that hour had not yet reached the archive. Keep estimated coverage clearly separate from observed coverage.<\/p>\n
NIST’s OT Backup Quick Start Guide<\/a> connects backup management with change management, testing, and recovery exercises. Its advice supports a documented restoration exercise; it does not provide a universal acceptance threshold for your metering project. Define those thresholds with the system owner, reporting users, and any contractual requirements before assessing the results.<\/p>\n Use an environment approved by the application owner that cannot inadvertently poll production meters or send commands into the operating network. Isolation must cover outbound connections and background jobs, not just the browser used to view a chart. Disable or redirect scheduled exports, notifications, external integrations, and automatic discovery according to the platform’s supported procedure. Never improvise firewall or service changes on a running industrial system.<\/p>\n Record the restore procedure, software versions, operator, start time, finish time, warnings, and any manual intervention. If the application requests a database conversion, preserve that fact and the conversion log. A successful conversion is a changed recovery path and should not silently replace the procedure being tested. Keep credentials out of screenshots and the general acceptance report.<\/p>\n The NIST Guide to OT Security<\/a> emphasizes OT reliability and safety alongside security. Apply that principle by keeping the exercise independent of normal acquisition. If isolation cannot be demonstrated, stop the restore activity and correct the test arrangement; do not use the live plant as an experimental recovery target.<\/p>\n Start with a small, explicitly identified set of points. Include different physical boundaries and measurement types only where the installed system actually records them. For each selected point, compare raw values, stored timestamps, units, scaling, quality flags, and identity. Check both an early and a late part of the chosen window so that a partial restoration cannot pass through a convenient sample.<\/p>\n Where a value differs, determine whether the comparison is between equivalent representations. A displayed decimal can be rounded while the underlying stored value retains more precision. A chart can aggregate readings into buckets. A cumulative energy register is not interchangeable with interval energy. Compare like with like, and record any approved transformation instead of calling every visible difference a corruption.<\/p>\n Use the existing historian retention review<\/a> to establish what was supposed to remain available. Retention determines the intended coverage; restoration acceptance checks whether a particular recovery set actually delivers that coverage. This article does not replace a retention policy or authorize keeping operational records indefinitely.<\/p>\n The following matrix is a project checklist, not a numerical standard. Add limits only when the system documentation or an approved project requirement supports them. A row should identify its reference evidence and the person responsible for judging the result.<\/p>\n Record pass, fail, or not tested for every row. Avoid an overall pass that hides an untested dependency. A limited test can still produce useful evidence, but its scope must be visible to the person deciding whether the recovery arrangement is adequate.<\/p>\n A recovered database may correctly contain a known outage. Acceptance should preserve that gap rather than fill it to make a graph look continuous. Compare the recovered gap with the maintenance data-gap record<\/a> and identify whether it predates the backup, occurred during backup creation, or results from the restore. These explanations have different corrective actions.<\/p>\n Configuration requires the same care. If a feeder was renamed, a transformer ratio changed, or a meter was replaced after the backup, the recovered historical configuration may differ from the current plant. Preserve effective dates and review how the historian associates old readings with old configuration. Do not apply current scaling retrospectively unless the platform’s design and the project decision explicitly require it.<\/p>\nRestore into an isolated, controlled environment<\/h2>\n
![\"CNBYG](\"https:\/\/cnbygele.com\/wp-content\/uploads\/2026\/11\/meter-historian-restore-acceptance-inspection-20261106.png\")
Compare records rather than the appearance of a chart<\/h2>\n
Build a practical acceptance matrix<\/h2>\n
\n\n
\n \nTest area<\/th>\n Evidence to compare<\/th>\n Reason to withhold acceptance<\/th>\n<\/tr>\n<\/thead>\n \n Archive coverage<\/td>\n First and last included timestamps for selected points<\/td>\n Coverage ends earlier than the declared recovery boundary<\/td>\n<\/tr>\n \n Point identity<\/td>\n Feeder name, asset reference, and documented source mapping<\/td>\n Recovered point refers to another measurement boundary<\/td>\n<\/tr>\n \n Raw readings<\/td>\n Selected stored records from the approved reference window<\/td>\n Unexplained value changes or missing records<\/td>\n<\/tr>\n \n Units and scaling<\/td>\n Stored unit, multiplier, and point configuration<\/td>\n A chart is plausible but engineering meaning changed<\/td>\n<\/tr>\n \n Quality information<\/td>\n Original quality codes and their interpretation<\/td>\n Invalid or substituted readings appear as normal<\/td>\n<\/tr>\n \n Application dependencies<\/td>\n Required services, templates, and supported versions<\/td>\n Data exists but the reporting workflow cannot use it<\/td>\n<\/tr>\n \n Access and isolation<\/td>\n Test access list and disabled production connections<\/td>\n Restore exercise can affect the operating collection path<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Account for gaps and configuration changes<\/h2>\n