Recover individual files from a Veeam Agent image
Restoring individual files from a full system image in Veeam Agent is usually a file-level recovery from an existing entire-computer backup, not a complete rebuild. Use it when a document, photograph, configuration file, or creative project has disappeared but the endpoint is otherwise healthy. Veeam Agent runs on the protected device, while the restore is normally initiated through Veeam Backup & Replication or Veeam Cloud Connect.
A full system image is often shorthand for an image-based backup of the whole computer. Veeam normally stores it as full and incremental backup files with metadata, not as a portable ISO. To recover one file, select a restore point where it existed and use the console’s file-level restore path. An exported virtual disk or another imaging product follows a different workflow.
Preparation prevents a second incident. Confirm that the console can reach the repository, the relevant backup chain and its metadata are available, and your account has restore permissions. Record the agent, console, and repository versions before proceeding. Missing repository files or unreadable metadata can turn a simple recovery into a major incident.
The safest destination is normally a controlled staging folder rather than the original path. Restore there, compare the recovered copy with a known-good source where possible, and only then replace the missing file. Australian teams supporting staff across Sydney, Melbourne, and Brisbane should also confirm that recovered material remains within their authorised data boundary, particularly when it contains personal information covered by the Privacy Act 1988.
Understand what the full backup contains
Check the job type before anything else. An Entire Computer backup includes the selected system and data disks, subject to exclusions and snapshot settings. A file-level job captures selected paths. A backup labelled Full can still omit cache folders, temporary data, excluded volumes, and files unavailable to the snapshot. Make sure the required path falls within the captured scope.
The deleted file must exist at the chosen restore point. If its deletion happened after the latest full and incremental chain was written, that version already lacks it. Move to an earlier restore point or another backup chain. Each restore point represents a recorded disk state, not a live mirror of the endpoint.
Ordinary documents and media files are the simplest cases. Database transactions, mailboxes, and virtual machines require application-aware recovery rather than a general file restore. Windows encrypted files, cloud-placeholder files, NTFS streams, and Linux ownership or symbolic links can also affect the result, so check those requirements before relying on the recovered copy.
Prepare the console, repository and storage
Use a Veeam console workstation that can access both the backup repository and its metadata. Depending on the network design, a proxy server may be required to transfer files between the console and a remote repository. This is common for distributed offices, including NBN-connected branches whose backup data is held at a central Sydney or Melbourne data centre.
Confirm version compatibility before opening the restore wizard. The Veeam console, repository, backup chain, and agent should be supported by the same release path. Vstpirate’s software listings can help identify available agent builds and operating-system requirements, but verify the package against Veeam’s official release notes and use a valid subscription, trial, or partner-issued licence.
Reserve enough staging space for the recovered file and any temporary extraction data. Check that the destination is writable by the console or proxy service. Australian organisations buying through a local reseller should also record the quoted licence terms and GST-inclusive invoice details, while support requests should identify the exact console and repository build.
Find the correct restore point
Open the backup inventory in the Veeam console, select the protected computer, and inspect its available backups. Choose the full backup chain and restore point that existed before the file disappeared. If several jobs ran on the same day, use the precise timestamp rather than relying on the displayed date alone.
Confirm the time zone used by the console. A backup labelled 09:00 in Australian Eastern Standard Time may sit at a different UTC time during daylight saving, when parts of Australia move to Australian Eastern Daylight Time. Check the chain’s health and retain every full and incremental file needed to reconstruct the selected point.
Create a short recovery note containing the backup ID, restore-point time, agent build, console build, source path, and intended destination. Community posts can remain visible long after a product changes; the effect of post timing analysis on how audiences encounter posts is a useful reminder to check a workaround’s date and match it with the documentation for your installed build.
Run a targeted file-level restore
In the console, right-click the relevant backup and select Restore files or File-level restore. Choose the required restore point in the wizard. Do not select Instant Recovery or a complete virtual-machine restore, because both involve more infrastructure than a single-file recovery needs. Exact menu names can vary slightly between Veeam releases.
Use the backup browser to locate the file. You can usually select a folder, enter a path, or browse the backup’s file tree. This browser shows content stored in the backup rather than the endpoint’s current directory. Check the extension, modified date, and folder to avoid restoring a similarly named temporary or obsolete file.
For the destination, select a new folder or controlled staging share unless the original location is clearly safe. Make sure the console or proxy can reach a UNC network path and that the path containing spaces is quoted correctly. Restoring to a new location may not reproduce every original permission or ownership attribute, so account for that when the file returns to its intended location.
Start the restore and monitor its progress in the task or job list. After completion, compare the recovered file with another known copy, check its size and hash where available, and open it in the relevant application. If it replaces an existing file, keep the current version until validation is complete. Scan recovered media before moving it into an active project folder.
Compare the recovery routes
A single missing file should use the narrowest available method. File-level restore is quicker and less disruptive than restoring an entire computer. Backup browsing or image mounting can help when several paths must be inspected, while Instant Recovery is intended for broader operating-system or application failure and should not be the default for one document.
| Recovery method | Best suited to | Effect on production | Main limitation |
|---|---|---|---|
| File-level restore | One deleted document, image, configuration, or project file | Low; no reboot of the endpoint is required | Requires the backup chain, metadata, and repository access |
| Backup browser or supported image mount | Inspecting several folders or recovering a directory | Low, although temporary space may be needed | Feature availability depends on the console and backup format |
| Instant Recovery or full virtual-machine restore | Broad endpoint corruption or multiple failed components | High; it starts an isolated recovery environment | Excessive for a single file and more demanding on storage and licensing |
| Restore from an exported disk image | A workflow performed outside the native Agent chain | Varies with the chosen tool | The exported image and its contents must remain compatible |
If the native chain is unavailable but an exported virtual disk or image still exists, inspect that copy separately. Instant Recovery can rescue a damaged endpoint, yet it consumes more time and resources and may require dedicated virtualisation capacity. For a routine missing file, the file-level path remains the controlled choice.
Make the next recovery routine
Rehearse the workflow with a disposable file in a non-production backup. Record the exact menu path, selected backup point, destination, permission behaviour, and verification method. Schedule checks for chains with missing increments, failed repository disks, and agent services that have stopped reporting, because an apparently healthy console cannot recover data that is no longer present.
Go to the Vstpirate software directory, locate the Veeam Agent package for Windows or Linux, and check the listed version and licence details before downloading. Confirm the installer against Veeam’s official release notes, use legitimate activation credentials, and install a build supported by your existing console and repository.
Open the console, identify the backup point from before the loss, and restore the required file to a staging location first. Validate that copy against a known-good source, restore its original attributes, and replace the damaged version only when the evidence is complete. This sequence keeps a one-file recovery accurate, secure, and repeatable across Australian offices.