## TL;DR
Mounting the wrong volume happens when the agent picks by order, such as the first disk or the second partition, and the environment presents volumes differently after restore. Select by durable identity: volume serial, filesystem UUID, label plus a content probe of a file only the target volume holds, and assert the identity again after mounting before any verification result is recorded.

```text
agent failed the restore test by mounting the wrong volume
```

## Use this when
- Verification results describe data from a different system or date than the restore point.
- The agent passes checks on the wrong data or fails checks the right data would pass.
- Volume order differs between the backup environment and the sandbox.

## Not for this skill when
- The correct volume is mounted but its data is corrupt. Integrity problem, honestly found.
- No volume mounts at all. Mount mechanism failure.

## Steps
1. Log how the agent currently chooses its target volume. Verify: the selection rule is identified, usually order or letter based
2. Record durable identifiers for target volumes in the backup metadata the agent can read: UUID, serial and label. Verify: identifiers are available per restore point
3. Change selection to match on identifier and confirm with a content probe file after mounting. Verify: a shuffled-volume test mounts the correct one
4. Abort the check loudly if the mounted identity does not match the intended restore point. Verify: a forced mismatch produces an abort, not a result
5. Run the restore test suite. Verify: each result names the volume identifier it verified

## Variant phrasings
### agent mounted wrong disk volume uuid selection
The identifier phrasing.
### restore verification wrong volume drive letter
The letter variant.
### mount target volume by serial not order
The method wording.

Compatibility: Agents mounting restored Windows and Linux volumes in sandboxes on VMware and Hyper-V, with multi-disk systems.

## Why it happens
Enumeration order is an accident of discovery timing, controller layout and sandbox hardware, none of which survive a restore to different virtual hardware. Drive letters and device names are conveniences for humans, not identities. Systems that carry many similar volumes, such as database servers with data and log disks, punish order-based mounting with confident wrong answers.

## Edge cases / pitfalls
- Content probes should use files guaranteed unique, such as a system identifier file, not generic paths every volume shares.
- Log the mounted identifier in every result. Wrong-volume incidents are otherwise impossible to audit later.
- If identifiers are unavailable from the backup product, create them: the harness can stamp a marker into the test mount record.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oflOX9dgBjb0c1C6AZ6DYA