Restore of DFSR Data - SLOW

[The_yeti1]

We backup DFS on our windows 2008 r2 server using the following method.

-  It is possible to select individual DFSR folders (and files) for backup by using the following syntax:  

• Shadow Copy Components:\User Data\Distributed File System Replication\DfsrReplicatedFolders\

<ObjectName>.
Multiple streams (via NEW_STREAM) are supported for DFSR folders.

When I went to restore a single file yesterday, it took over 2 hours and 4 tapes to restore.

Since it sees DFS as "System State" and my entire System State is over 4TB (because of the DFS), I am assuming this is with it took 4 tapes and 2 hours.

My guess is that it had to "See" the entire system state, so that it could restore the 1 file. 

Can anyone confirm or deny this?  A Symantec KB link prehaps?

This is NetBackup 7.1

[RamNagalla · Accepted solution]

entire System State is over 4TB (because of the DFS), I am assuming this is with it took 4 tapes and 2 hours.

your statement probably answer this, as you have data on Tape, and tape can only read data Linear, it might did consume the lot of time to find the files.

if you have Disk STU, you could Probably check this and confirm by taking the backup into disk and doing a test restore.

[The_yeti1]

Thanks ! The search term I needed was: "Linear"

“This is because by multiplexing, segments of tape must regularly be skipped to selectively get restore data. In extreme cases, this can mean loading and positioning several different tapes for a relatively small amount of data”

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

No special action is required to restore a multiplexed backup. NetBackup finds the media and restores the requested backup. Restore performance will be impacted due to reading the data from all streams that are multiplexed together.

Restore performance:

Multiplexing backups can increase the total throughput by consolidating streams from multiple clients to a single tape, allowing the tape drive to reach and maintain it's full write speed.  Restores of multiplexed data will experience slower performance than non-multiplexed restores.  This is due to reading all of the data that is written in a given multiplex set in order to restore a single stream of data within the set.

For example, if there are 3 data streams being written at the same speed, for a given restore, there will be roughly three times the amount of data that must be read from the tape in order to restore the needed information.  This will also result in values for the "Current kilobytes read" field in the job details showing much higher than may be expected.  Again using the example of 3 data streams, each with 10GB of data, a full restore of any one of the streams actually requires reading 30GB of data from the tape.

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