Replies to This Discussion

Permalink Reply by DoubleDensity on April 29, 2015 at 4:00pm

Hi Mike!

We browse the /recover/files share using its builtin automated folder layout; it sorts all backup jobs by YEAR, MONTH, DAY, TIMESTAMP and BACKUP POLICY. If you have access to the vmPRO GUI, you can quickly correlate the specific backup job you need with the containing folder; but even without it as long as you know approximately when in time you want to restore from you can identify the relevant subfolder rapidly.

Ideally you want to know the name of the VM you are looking to recover data from, and the path on disk where the files you need are located. Large volumes of files will only be encountered when you enter in to a .volume subfolder, at which point the contents of the guest VM filesystem will become visible in that location.

To recover files from a backup job, you would navigate to the corresponding job folder and select the file you wish to retrieve. From there you can immediately copy out any collection of files that you need without any interaction with the vmPRO interface.

• ▶ Reply

Permalink Reply by Mike on April 29, 2015 at 4:42pm

Thanks for the reply DD.  The challenge we are having is the sloooooow response in Windows Explorer when browsing the /recover directory (could be our AV software, etc. - looking there next).

Hypothetically, if you have 20 jobs and they all start at the exact same time, how do you know that the 'Project' folder is going to be in the 00007 time stamp folder (in your case)?  That backup job may have started first or last, with 18 jobs in between meaning you have to look in every folder until you find it.

Trying to see how everyone else is doing the restore part.

Thanks,

Mike

• ▶ Reply

Permalink Reply by DoubleDensity on April 29, 2015 at 6:15pm

Operations in /recover/files are highly sensitive to the performance and load on the target storage device, as vmPRO is querying the storage device mount point on your behalf while you are browsing it. Think of the act of browsing the vmPRO /recover share as being equivalent to actually submitting a Restore Job in NetBackup, although the vmPRO is doing it on your behalf in the background.

AV software will slow down just about everything in Windows unfortunately. Also consider monitoring the network utilization for all of the links involved on your production and backup environments, and check the disk queue throughput stats in ESX to make sure all the hosts involved are healthy and balanced.

In vSphere client I usually go to the Performance tab on my hosts and look at the Disk and Network stats during backup activity. From that data I can tell how heavily utilized the HBA and NIC interfaces are in proportion to their theoretical maximum limits. vSphere/vRealize Operations Manager can also help give more insight on these figures.

Since there are NAS storage operations occurring in the background dependent on a response from the backup storage device or DXi, the characteristics of the backup storage device play a prominent role in determining responsiveness for /recover.

For example, a higher end storage device like a DXi 6902 will provide a faster response time for /recover operations relative to a DXi 4500 or a Synology DS209.

In the same manner, operations in vmPRO /export have a response time which is dependent upon the available disk and network I/O resources which are available on the corresponding ESX hosts involved.

Hypothetically in your example scenario above, you would not be able to determine which job was which only by looking only at its folder name timestamp; you would need to expand your view to include the next directory below it as well. If you are on Windows and using Explorer, I like to use the tree view feature in the Navigation pane to help explore most efficiently. If I am on a Mac, I use the column view for a similar purpose.

• ▶ Reply

Permalink Reply by Mike on April 30, 2015 at 9:01am

Thanks for the reply and information.  We are trying to test the vmPRO software utilizing a DXi4510 but may be forced to utilize an alternate NFS share on another array if the issue is being caused by backend disk performance as you have indicated.

Thanks again.

• ▶ Reply