commvault stub recovery overload is it an issue

[myuserid7]

Hi,
Hope someone can clarify the stub creation and retrival process in commvault to me.
I understand that with data aging policies, commvault can move data from primary storage to secondary storage leaving stubs on the primary storage.
when a stub is double clicked for retrieval, commvault extracts it from secondary storage.

Now if many stub files were accessed all at the same time can that bring commvault down to a hault ? Is that a very cpu intensive operation ?

appricate any info.

 

[mybackupfailed]

I wouldn't worry about CPU but would about restore throughput. Accessing a stub will open up a pipeline to the secondary storage media (media agent) and restore the files. Push commvault on this question to get an estimate of data migrator stub recovery throughput.

 

[birky]

never seen it cause a resource issue but, could be possible I suppose.

Would take a heck of a lot of simultaneous recalls though.

 

[dall]

Hi, normal day-to-day recalls are fine but we had a situation using volume shadow copy to bring back a very large directory whereby the persistant copy kept hanging and recreating itself. It then hung the VSC restore and we ended up disabling Data Migrator and performing normal restores.

 

[BkpAdmin]

What version of Galaxy are you running? v6.1 recovery is much faster with a high amount of files then v5.9.

Other than OpLocks (see MSKB

http://support.microsoft.com/default.aspx?scid=kb;en-us;296264)

your recalls are dependent upon your hardware/network speed.

 

[myuserid7]

In my testing I have experienced very slow stub recovery times. ie: double click a file and have to wait a noticeable time for the file open up.

In our case the commserver and the 2-node cluster (which hosts the files) are all in the same rack on a private network switch. Which is why I had assumed the stub recovery times would be a lot quicker.

I was informed about OpLocks in windows by Commvault which should make the process faster. I still have to try that out and will report my findings.

 

[BkpAdmin]

chances are its oplocks - before making the changes to oplocks it would take about 45seconds to open the file after the changes it was down to almost 12-15secs.

As you can see in the log below the file was placed back into the cache directory in 8secs (Galaxy Recovery Time) - however there was 30sec delay before the OS placed the file back on the disk (OS recovery time.



2428 9e8 11/26 14:46:02 ### RecallThread:New filesystem request

2428 9e8 11/26 14:46:02 ### RecallThread: BlockSize : [1196]

2428 9e8 11/26 14:46:02 ### RecallThread: Start Seq : [46]

2428 9e8 11/26 14:46:02 ### RecallThread: End Seq : [47]

2428 9e8 11/26 14:46:02 ### RecallThread: Num Requests : [0]

2428 9e8 11/26 14:46:02 ### RecallThread: Max Requests : [-1]

2428 9e8 11/26 14:46:02 ### RecallThread:Starting thread to handle new requests

2428 ca8 11/26 14:46:02 ### recallAllFiles:** Restoring file **

2428 ca8 11/26 14:46:02 ### recallAllFiles:File name :\Test\Recall123.ppt

2428 ca8 11/26 14:46:02 ### recallAllFiles:Sequence :47

2428 ca8 11/26 14:46:02 ### recallAllFiles:ReparseDat:1:2398:2:49:40382680?R:\partage\Copy of Présentation Kaizen temps de course EB.ppt

2428 ca8 11/26 14:46:02 ### recallAllFiles:Reparse :1:2398:2:49:40382680

2428 ca8 11/26 14:46:02 ### recallAllFilesroc Name :System

2428 ca8 11/26 14:46:02 ### recallAllFiles:RestoreCnt:0

2428 ca8 11/26 14:46:02 ### recallGalaxyFile() - Source path : [1:2398:2:49:40382680]

2428 ca8 11/26 14:46:03 ### recallGalaxyFile() - Jobid : [1073741871]

2428 ca8 11/26 14:46:06 ### recallGalaxyFile() - Job completed. Status SUCCESS.

2428 ca8 11/26 14:46:06 ### recallAllFilesest :\gxhsmcache

2428 ca8 11/26 14:46:06 ### recallAllFiles:Restore :\gxhsmcache\Test\Recall123.ppt

2428 ca8 11/26 14:46:44 ### recallAllFiles:Size Copy :22222


Before making any changes to oplocks you may want to consult MS.

 

[mybackupfailed]

dall writes:

"Hi, normal day-to-day recalls are fine but we had a situation using volume shadow copy to bring back a very large directory whereby the persistant copy kept hanging and recreating itself. It then hung the VSC restore and we ended up disabling Data Migrator and performing normal restores."


This sounds different than a typical recall that others are talking about. You should probably ask Commvault if this is supported.

 

[dall]

I have asked them and am still waiting on a reply - no something I want to test out again in a hurry.