This guide describes restore to a new, isolated VM for initial acceptance testing. Overwriting a production VM, file/object recovery, database PITR and disaster activation are separate scenarios.
RESTORE, Step One, Step Two, Select Restore Location and Summary are present in the existing backup-list template. Target options vary by platform and version. VMware repository restore uses a new isolated VM; OpenStack/Safir requires separate cloud, volume and network mapping 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.
Successful, accessible recovery point
Sufficient target capacity and permissions
Naming, network and storage plan isolated from production
Test file or application data to validate
01
1. Identify the source and recovery point
Find the correct platform and source in the backup list. Check source connection and backup time as well as VM name. Record recovery point time, backup type and repository. For an incremental point, the required full and incremental chain must be accessible.
Check platform, policy and Last Backup together in Backup List. Here, ss1 is the name of an existing lab record. Enlarge ↗
Expected result
The intended recovery point for the correct source is selected.
02
2. Open the RESTORE wizard
Open RESTORE from the relevant backup record. Review source and backup details in Step One; stop if they do not match. After confirming the point, use Next to move to the target step. For this test, use the VM restore scenario rather than file/object recovery.
RESTORE → Step One: selecting a VM lists Full Backups and Incremental Backups. A full point is selected here; Next opens target selection. Enlarge ↗
Expected result
The wizard proceeds to target selection for the intended backup record.
03
3. Select a new isolated target
In Step Two, choose the approved test destination in Select Restore Location. Use the new-VM or target-resource options offered by your platform and assign a unique target name. VMware repository recovery prepares the target VM powered off and disconnected; do not assume automatic production connectivity.
Expected result
The target is separate from production and has no naming conflict.
04
4. Check disk, storage and network mappings
Check disk count, order and target capacity in the wizard’s disk mappings. For OpenStack/Safir, validate target cloud/project, volume backend, flavor and network mappings for your environment. For VMware, check vSphere resources, datastore and disk/controller layout. The test network must not conflict with production IPs or services.
Expected result
All disks map to suitable targets and test isolation is preserved.
05
5. Review Summary and start the operation
Use Summary to review the selected operations. Compare source, time, target and mappings with the test plan. If the selection could delete data, overwrite an existing resource or reach the wrong target, correct it before confirmation. Apply the final restore action only for the approved new test target.
Different Location and Summary: compare the new VM name and target mappings. Network and resource IDs shown are lab examples; isolated-target suitability must be verified separately. Restore was not submitted. Enlarge ↗
Expected result
One restore job is created and its source and target details are recorded.
06
6. Monitor results and start the target under control
Wait for completion in task/notification details. If the job fails, inspect its ID and error rather than repeatedly restore to the same target. After success, verify the target disk set. If boot is required, start the VM only under approved test conditions on an isolated network.
Expected result
The final job status is successful and the target is ready according to the test plan.
07
7. Validate data and applications and record evidence
Check test-file contents, required services and application/database access. Where appropriate, compare the file hash against the source record. Record elapsed time, recovered point, product/platform versions and outcome; do not turn these into unmeasured RPO/RTO guarantees. Complete the acceptance record and verify target identity before removing test resources.
Expected result
The backup/restore chain is validated with actual data checks and an acceptance record is created.
COMMON QUESTIONS
Does a successful restore job mean the application is ready?
Not by itself. Disk/data integrity, guest startup, services and application access must also be checked.