This guide covers agent-based file/folder workflows; it does not establish full-server image, Bare Metal, System State or database-consistency acceptance. A UI option or catalog entry does not guarantee end-to-end data recovery.
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 limits: the Windows win file agent returned a network connection error. The Linux orc79.localdomain agent appeared responsive but the Clients file tree and SUMMARY remained empty. Historical catalogs opened for both platforms. Selecting a Windows fileserver Full point returned Critical components could not be loaded; file selection and the target screen could not be verified. Linux Full points were listed; the target flow was not executed. No new policy, backup or restore was submitted.
Master and agent releases, source server and filesystem
Selected paths, read permissions and repository capacity
Consistency, retention and test recovery target
File/hash, metadata and application acceptance criteria
01
1. Find the correct server and file job
Open Home → Backups → Backup List. Match the windows_file type and source server/policy identity. Compare Last Backup with the appropriate time before the incident. A Not Yet Backup job is not a usable file point; do not substitute a disk image or database job for the file catalog.
Match the Windows file job with its source and Last Backup date. Appearing in this list does not establish verified contents. Enlarge ↗
Expected result
Source, job type and requested time match.
02
2. Check the recovery point and chain
Open Action → Restore for the job. In RESTORE POINTS LIST, inspect the Full point and any dependent incremental point by date, method and size. Repository data and the required chain must be accessible. A tiny size, old date or visible catalog entry does not prove content integrity.
Expected result
The point and required data chain are identified.
03
3. Explicitly select scope in the file tree
Open the point and wait for the file tree under POINT PATHS / Search file. Explicitly select only the test file/folder; record full paths and file count. Empty selection is not a safe zero-file operation: the inspected submission code can collect all loaded file nodes when selection is empty. Stop if the tree fails or scope is unclear.
fileserver Full points are visible; the selected point returned Critical components could not be loaded. The file tree, selection and target form were not verified; Restore was not submitted. Enlarge ↗
Expected result
The selected file list is explicit and limited.
04
4. Prepare a different test destination
After Next, inspect the installed release’s target form. The inspected pageTwoFile template offers Original Location and Different Location. For the initial test, prepare an absolute path separate from the source folder, such as C:\EraRestoreTest, under Different Location → Restore Path. This field alone does not establish a different server/agent. Verify the target filesystem and free space.
Expected result
The target path is separate from the source with sufficient capacity.
05
5. Review collisions and the final summary
Recheck point identity, selected paths, destination and file count. Validate overwrite/rename/skip behavior for existing names in the relevant release; do not assume an option that the UI does not expose. Original Location may affect existing data. Execute the final Restore only after scope and collision behavior are approved.
Expected result
Final scope and effects on existing data are understood.
06
6. Verify the task and file contents
In an approved test, inspect task results and actual destination files together. Compare names, sizes and SHA-256 values with the recorded samples. Check reports for skipped/locked files and partial failures. A success message alone does not establish that every file was recovered correctly.
Expected result
Task results and file contents support the same acceptance result.
07
7. Accept permissions and application access
Open files as the expected user; compare NTFS ACL, owner, timestamps and required special metadata. ACL/EFS/ADS recovery was not validated in this inspection; a content hash match does not guarantee these features. Record results, releases, backup ID and target path.
Expected result
Content, metadata and user access are documented separately.
COMMON QUESTIONS
Does a file backup provide full-server recovery?
No. OS boot, application installation, System State and Bare Metal require separate scope and acceptance. File contents and permissions/metadata must also be verified separately.