BEFORE YOU BEGIN
Check before you begin
Sangfor VM Policy and restore templates exist. The inspected restore screen selects Original Location; Different Location is disabled. This does not establish target overwrite/new-VM behavior or end-to-end acceptance for every release.
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.
Some lab screenshots are withheld pending privacy review. Follow the documented steps and use your own environment values.
Lab inspection: Sangfor LAB-CONNECTION was registered; Clients was empty with 0 Machines Selected. Historical catalog records existed; JOBJOB / T1_Restore had no restore point in the current date range. The target form was not live-validated; no policy/backup/restore was submitted.
- Hypervisor/management release and source host/cluster
- Source access, VM identity and all disks
- Repository, quota and data-path components
- Boot/network prerequisites and controlled acceptance plan
011. Define Sangfor topology and test source
Record Sangfor management/cluster release, node, VM identity and storage layout. Choose one small VM for the first test; validate API access and data-path compatibility against the installed release.
Expected resultPlatform and test VM scope are recorded.
022. Verify source access and repository
Check the approved connection record, account privileges, network and required component releases. Prepare repository capacity and data-path access. Keep password/token secret values out of policy names and screenshots.
Expected resultSource and repository prerequisites are ready.
033. Prepare the Sangfor draft in Attribute
Open Home → Policies → VM Policy → Create Policy. Select Sangfor as Policy Type, the correct Server, a unique Policy Name and Storage. If Server is empty, do not substitute another platform’s host; complete source registration and compatibility preparation.
Sangfor Attribute draft: LAB-CONNECTION, demo policy name and BackupDisk. SOURCE is the connection account identifier; the draft was not saved.
Expected resultAn unsaved draft is prepared for the correct platform.
044. Map one VM and all disks
If Clients inventory loads, select the test VM by identity and check the machine count in Summary. Record boot/data disks, firmware, attachment and passthrough/excluded-disk conditions. An empty list, error or single-disk result does not establish whole-VM protection.
SANGFOR Clients: There is no vm on the relevant server and 0 Machines Selected. The cause of the empty inventory was not verified; backup was not started.
Expected resultThe VM and required disk set are identified.
055. Assess consistency, method and retention
Compare Advanced Settings with the backend/guest and release. A crash-consistent copy is not application-consistent database acceptance. Do not infer support from visible snapshot/incremental options; method, dependent chain and retention require technical acceptance.
Expected resultMethod and consistency scope are explicit.
066. Plan an approved Full test and catalog review
Set an approved test window and capacity-appropriate retention in Schedules. Do not use Create Policy or Start Now before validating source/VM selection. In an approved test for the matching release/method, compare task, repository output and catalog time.
Expected resultActual output matches the catalog record.
077. Complete restore acceptance separately
With Sangfor offering only Original Location, avoid testing against a live source; separately approve the isolated lab target and effects on existing data.
Expected resultBackup ID, release, disk scope, test file/hash and guest acceptance are documented.
COMMON QUESTIONS
Does this screen establish end-to-end restore support?
No. Source/backend, target behavior and isolated data acceptance require separate validation in the installed release.