File Restore from vSphere API Backup very slow (system reads whole image file)

[SvenKessler]

Hello,

we have a vmware Fileserver based on Windows 2008 32 bit with a 1,5 TB Data share. We backup this server with Netbackup 7.0.1, Backup Method "Mapped full VM backup" with block level incremental. There is a full backup each weekend and a incremental each day.

When we try to restore a single file (for example a word file) it sometimes takes more than 12 hours. I can see in the activity monitor under "Current kilobytes read" that the backup process reads the whole backup image byte for byte. It seems so that the restore process doesn't know where the file is located in the complete vmware image file. Is this by design, or is this a error with our system? Is there a better way for doing backups without waiting 12 hours and more for an single restore file?

Best regards

Sven

[Douglas_Snyder]

Sven,

Do you mean that your VMDK file is 1.5 TB?

[SvenKessler]

Hello,

yes, our VMDK File is about 1,6 TB. 

Best regards

Sven

[Marianne]

What is the Fragment Size of your Storage Unit?

Have a look at this extract from Admin Guide:

Fragmenting multiplexed tape backups can expedite restores. Fragments allow NetBackup to skip to the specific fragment before searching for a file. Generally, NetBackup starts at the beginning of the multiplexed backup and reads tar headers until it finds the file.

[SvenKessler]

Thank you for showing me the right direction. We have actually the default fragment size which seems to be around 1 GB. What fragment size is a "good practise" for LTO 4 Tapes?

Best regards

Sven

[Andy_Welburn · Accepted solution]

Are you sure it's not 1Tb? (1048576 Megabytes)

From the Planning & Performance Guide (p148):

"...
The fragment size affects where tape markers are placed and how many tape
markers are used. (The default fragment size is 1 terabyte for tape storage units
and 512 GB for disk.) As a rule, a larger fragment size results in faster backups,
but may result in slower restores when recovering a small number of individual
files.
The "Reduce fragment size to" setting on the Storage Unit dialog limits the largest
fragment size of the image. By limiting the size of the fragment, the size of the
largest read during restore is minimized, reducing restore time. The fragment
size is especially important when restoring a small number of individual files
rather than entire directories or file systems.
For many sites, a fragment size of approximately 10 GB results in good
performance for backup and restore.
..."

http://www.symantec.com/business/support/index?page=content&id=TECH62317

It follows up with a few considerations.

[SvenKessler]

Hello,

i'm sorrry. Of course i meant 1 TB. I'll try 10 GB as new value and will test a restore after our new full backup this weekend.

Is the fragment setting also valid for vmware backups with option mapped full vm? Does netbackup know in which fragment it has to search for file level based restores? Or does netbackup only know where to search for whole vmdk restores?

Best regards

Sven