Hyper-V exposes a different-location target with Server/Datastore/new VM name; actual host and boot/network acceptance still require validation.
Screenshots were captured from the actual lab interface on 16 October 2026. The interface is in English; explanations follow your selected language. Resource names, dates and settings are examples; use values for your own environment.
Lab note: no registered Hyper-V host was available in Server. Source VM selection and restore target screens could not be captured; the form and catalog state are shown. No new policy or backup/restore was executed.
Hyper-V release, host/node and master components
Source access, account scope and repository data path
VM identity, boot/firmware and all disks
Capacity, consistency and isolated restore acceptance plan
01
1. Verify the source record and disk scope
Find the Hyper-V job in Home → Backups → Backup List. Compare VM identity, host/node, disk and Last Backup time. Not Yet Backup is not a usable point. Active job status does not prove a completed backup.
The hyperv search in Backup List returned No matching records found. No usable point or target form was opened from this search; no other platform screen was substituted. Enlarge ↗
Expected result
The correct platform and source record are selected.
02
2. Select a usable point in RESTORE
Open Step One through Action → Restore. Inspect the VM/item and Full/dependent points where available. All required disk components and the backup chain must be accessible in the repository. Do not initiate target writes from missing or invalid catalog records.
Expected result
The point and disk chain are accessible.
03
3. Choose a separate target with Different Location
The inspected Hyper-V template offers Original Location and Different Location. Assess Different Location for initial acceptance. Verify target host and storage capacity in advance; a new VM on the same host also requires network isolation.
Expected result
Target behavior and collision risk are explicit.
04
4. Check host, datastore and the new VM name
Hyper-V Different Location includes Select Server, Select Datastore and New VM Name. Use a unique new name. Separately validate VM generation/firmware, disk attachment and virtual switch prerequisites; do not assume the form exposes every network mapping.
Expected result
Target and data effects are documented before execution.
05
5. Review Summary and the final action
Review source point, method, VM/disks and target summary. Use Restore only for the approved test target once the new VM name, Server and Datastore are correct and isolated. A preview screen is not evidence of successful recovery.
Expected result
The approved target and scope are recorded.
06
6. Compare task and hypervisor state
Compare EraBackup task results with VM and disk state on Hyper-V. Avoid repeatedly restoring to the same target after errors or partial disk output. Check power/network state and keep the target separate from production traffic.
Expected result
Task, disk and VM state agree.
07
7. Document guest and application acceptance
In an isolated test validate boot, filesystems, all required disks, a test file/hash and critical application queries. Record backup ID, releases, target, duration and result. One VM acceptance does not establish cluster failover, instant recovery or cross-platform conversion.
Expected result
Usable data and guest results are documented.
COMMON QUESTIONS
Does this guide cover instant recovery or cross-hypervisor conversion?
No. These require separate source/target and release acceptance and are not established here.