File level Restoring using Avamar

— ny_wk

A file-level restore using Avamar lets a system administrator pull back individual files or folders from a full VMware image backup without recovering the entire virtual machine. This guide walks through the complete workflow in the Avamar Administrator console: installing the client, browsing an image backup, performing a granular (file-level) restore, and verifying that the recovered data is intact.

Dell EMC Avamar is a deduplicating backup product that is most often paired with the Avamar Image Proxy to protect VMware vSphere virtual machines at the image level. The power of file-level restore using Avamar is that the same image backup you took for full-VM disaster recovery can also be mounted and browsed so you can cherry-pick a single deleted spreadsheet, log file, or configuration folder. This article uses the classic Avamar 7.x Administrator GUI workflow and then notes the modern Dell PowerProtect equivalent at the end.

The problem: recovering one file from a whole-VM backup

Image-level backups are efficient because Avamar snapshots and deduplicates the entire virtual disk in one pass. The challenge is that a user rarely loses an entire machine — they delete one folder, corrupt one database export, or overwrite one document. Restoring the full image just to retrieve a 2 MB file would be slow, wasteful, and disruptive.

The solution is granular level recovery (GLR). Avamar can present the contents of an image backup as a browsable file system, let you select exactly the files and folders you need, and push them back to the original location or an alternate destination over the network. You get the storage efficiency of image backups with the convenience of file-level restore.

Prerequisites before you start a file-level restore using Avamar

Confirm the following before you launch the console, because a missing prerequisite is the most common reason a granular restore fails:

• A successful image backup of the VM exists. In the Avamar calendar, only dates highlighted in amber/orange represent days where the backup completed successfully — those are the only valid restore points.
• VMware tools are installed and running inside the target guest, and the VM is reachable on the network.
• Credentials with write access to the destination machine (a local administrator or a domain account that can write to the target folder).
• The Avamar Administrator console is installed on your management workstation, along with its required Java runtime.
• An available image proxy registered with the Avamar server to mount the backup for browsing.

Installing the Avamar Administrator console

The legacy Avamar 7.x console is a Java-based desktop application. On a 64-bit Windows management host, install the components in this order:

1. Open the Windows (64-bit) downloads folder on your Avamar server's web interface or installation media.
2. Install the bundled Java Runtime Environment first — the console will not launch without a compatible JRE. The 7.1.x installer historically shipped with a Java 7 JRE (for example jre-7u76-windows-x64.exe).
3. Install the Avamar Administrator package next, for example AvamarConsoleMultiple-windows-x86_64-7.1.2.21.exe. The “Multiple” build lets one console connect to several Avamar servers.
4. Launch Avamar Administrator from the Start menu.

Security note on legacy versions: Java 7 and Avamar 7.1 are long past end of life and contain unpatched vulnerabilities. Use these versions only on an isolated, internal management workstation that is never exposed to the internet, and plan to migrate. On current Dell PowerProtect / Avamar releases the desktop console is largely replaced by the browser-based Avamar Web UI / PowerProtect Data Manager UI, which needs no local Java. The recovery concepts below are identical — only the launcher differs.

Step-by-step: file-level restore using Avamar

With the console installed and the prerequisites met, follow these steps to perform the granular recovery.

1. Log on. Open Avamar Administrator, select your Avamar server, and click Log On with an administrator account.
2. Open Backup & Restore. Click the Backup & Restore tab and wait for the domain tree to fully populate — large environments can take a moment.
3. Locate the virtual machine. In the upper-left pane, browse through the vCenter (VC) hierarchy and select the cluster that hosts the VM. In the lower-left pane, select the specific VM whose files you want to recover.
4. Switch to the Restore tab. In the right-hand pane, click the Restore tab to list that VM's recovery points.
5. Pick a valid backup date. Choose the date you want to restore from. Only dates shown in amber are selectable — those are days a backup succeeded. Pick the most recent good point before the data loss occurred.
6. Confirm proxy selection. When prompted, accept OK for automatic proxy selection so Avamar assigns an available image proxy to mount the backup. Choose a specific proxy manually only if you have a reason to.
7. Open the granular browse view. Click the Browse for Granular Restore icon (the folder-style icon). Avamar mounts the image and presents its file system so you can expand directories.
8. Select the files or folders. Expand the tree and tick exactly the files and folders you need. Selecting only what you need keeps the restore fast and avoids overwriting good data.
9. Start the restore. Right-click the selection and choose Restore Now.

Choosing the destination and encryption settings

The Restore Options window controls where the data lands and how it travels. Configure it carefully — this is where most accidental overwrites happen.

1. Choose the location. Select Restore to original location only if you are sure you want to overwrite the live copies. To be safe, pick Restore to a different location and recover into a staging folder, then copy the files where they belong after you verify them.
2. Set the encryption method. For an in-network restore where TLS is not configured between the proxy and the target, set Encryption Method to None so the job is not blocked by a mismatched cipher. If your environment mandates in-flight encryption, choose the method your Avamar server is configured for instead.
3. Browse for the destination. Click Browse next to the destination field and expand the path to the target machine and share.
4. Enter credentials. Provide a username and password that has write access to the target VM. A wrong or under-privileged account is the number-one cause of a failed granular restore.
5. Select the destination folder where the files should be written.
6. Click OK to launch the restore job, then click Close to return to the console. The job now runs in the background.

Monitoring the restore job to completion

A restore is not done when you click Close — it is done when the job reports success. Track it from the Activity monitor:

• Open the Activity window (Activity Monitor) in Avamar Administrator.
• Find your Restore job by VM name and timestamp.
• Watch the status move from Running to Completed. A status of Completed with exceptions means some items were skipped — open the job log to see which files and why.
• If the job sits in Queued, an image proxy is likely busy or offline — confirm a proxy is registered and idle.

Common pitfalls during a file-level restore using Avamar

These are the failures sysadmins hit most often, and how to avoid them:

• Picking a non-amber date. Dates without the amber highlight have no successful backup and cannot be restored from. Always confirm the calendar color.
• Overwriting good data. Restoring to the original location replaces current files silently. Default to an alternate/staging location and copy back only what you verified.
• Insufficient destination credentials. The account must be able to write to the exact target folder. Local admin on the target, or a domain account with explicit NTFS write rights, avoids “access denied” failures.
• Encryption mismatch. If proxy-to-target TLS is not set up, leaving encryption on can stall the job. Use None for trusted internal restores unless policy requires otherwise.
• No available proxy. Granular restore needs an image proxy to mount the backup. If none is free, the job queues indefinitely.
• Locked or in-use files. Files held open by a running application may be skipped. Stop the relevant service or restore to a staging path.
• Path or filename length limits. Very deep Windows paths can exceed limits and silently skip — restore to a short staging path first.

Verification: confirming the restore actually worked

Never close the ticket on the strength of a “Completed” status alone. Verify the data:

1. Open the Activity log for the job and confirm the number of files restored matches what you selected, with zero unexpected exceptions.
2. Log in to the destination VM and navigate to the restore folder.
3. Confirm the files exist with the expected names, sizes, and modified dates.
4. Open or checksum a sample. Open a document, run a database export, or compare a hash. On Windows you can verify integrity with certutil -hashfile "C:\restore\report.xlsx" SHA256 and compare against a known-good value.
5. Move from staging to production only after the sample checks pass, then re-confirm permissions on the final location.

The modern equivalent: Avamar in PowerProtect Data Manager

Avamar continues as a deduplication engine, but Dell now manages backup and recovery through PowerProtect Data Manager (PPDM) with backups landing on a PowerProtect DD (formerly Data Domain) appliance. The file-level restore concept is unchanged — you still browse an image backup and select individual files — but you do it from a modern browser UI instead of the Java console:

• Sign in to the PowerProtect Data Manager web UI (no local Java client).
• Go to Restore → Assets, select the protected VM, and choose File Level Restore.
• Browse the mounted image, select files/folders, choose original or alternate destination, supply credentials, and run.

If you are still on Avamar 7.x, the steps in this guide remain valid, but treat the legacy Java console and JRE 7 as a security risk and schedule an upgrade to a supported PowerProtect release.

Key Takeaways

• File-level restore using Avamar recovers individual files from a full VMware image backup via granular level recovery — no full-VM restore needed.
• Only amber-highlighted dates are valid recovery points; they mark successful backups.
• A free image proxy and an account with write access to the destination are mandatory — their absence causes most failures.
• Default to restoring into a staging/alternate location, then verify before copying to production to avoid overwriting good data.
• The legacy Java console (and JRE 7) is end of life; the same workflow now lives in PowerProtect Data Manager's browser UI.

Frequently Asked Questions

What is file-level restore in Avamar?

File-level restore (granular level recovery) lets you mount a VMware image backup as a browsable file system and recover specific files or folders, rather than restoring the entire virtual machine. It combines the storage efficiency of image backups with the convenience of single-file recovery.

Why are some backup dates greyed out in Avamar?

Dates that are not highlighted in amber have no successful backup associated with them, so you cannot restore from them. Always pick an amber date — the most recent good one before the data was lost.

Can I restore Avamar files to a different machine?

Yes. In the Restore Options window choose Restore to a different location, browse to the alternate server and folder, and supply credentials with write access to that target. This is the safest approach because it avoids overwriting live data.

Is the Avamar Java console still required?

Not on current releases. Modern Dell PowerProtect Data Manager and Avamar versions use a browser-based web UI for restores, so no local Java client is needed. The legacy Java console and JRE 7 are end of life and should only run on isolated internal hosts pending an upgrade.

For more sysadmin and DevOps walkthroughs, subscribe to @explorenystream on YouTube.