agent's restore verification failed by reading cached data instead of the restored copy

TL;DR

Verification that reads a cache proves the cache works, not the restore. This happens when the agent mounts the backup, reads through an OS or application cache, or checks a path that still points at production data. Point the check at the restored volume by its unique identifier, read with cache-bypassing options where available, and plant or select check content that only the restored copy can contain.

agent's restore verification failed by reading cached data instead of the restored copy

Use this when

• Verification passes instantly for data that should take time to read.
• A deliberately corrupted restore still verifies as healthy.
• File timestamps or identifiers in the check output belong to the production copy.

Not for this skill when

• The restored copy itself is corrupt and reads prove it. Then verification is working correctly.
• Checksum cache was poisoned by a partial download earlier. Related caching layer, different mechanism.

Steps

1. Trace the exact paths and volume identifiers the agent reads during verification. Verify: whether reads hit restored or cached or production locations is established
2. Change the check to open the restored volume by its unique id or mount point created for the test, not by a reusable friendly path. Verify: reads target the test mount in logs
3. Disable or bypass read caching for the verification pass, or read enough unique data to defeat cache residency. Verify: read timings and I/O counters show real storage reads
4. Include a sentinel check: a file version or record state that differs between production and the restore point. Verify: the check reports the restore-point version, proving provenance
5. Run verification against a restore with a known intentional difference from production. Verify: the agent reports the restored state, not the live state

Variant phrasings

verification read wrong copy cache provenance

The provenance phrasing.

agent checked production instead of restored data

The wrong-target variant.

restore test sentinel file cache bypass

The sentinel wording.

Compatibility: Restore verification agents on Windows and Linux with OS page caches, backup mount caches and application-level caching.

Why it happens

Caches exist at every layer and all of them are invisible to a checker that only asks for content by name: the name resolves to the fastest copy, which is rarely the restored one. Provenance-aware verification, unique mounts, direct reads and sentinel content, is the difference between testing a restore and testing that a path exists.

Edge cases / pitfalls

• Instant verification of large data is always suspicious. Add duration sanity checks to reports.
• Sentinel content must be created before backup, inside the data, to prove restore provenance end to end.
• A verification that cannot distinguish copies should be reported as inconclusive, never as passed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1ERiu2gHbSKM-fSoaqgitg