Are the mounts coming from the NEXTSTGP of the slow disk? If so, I wonder if 
the algorithm is to restore from non-dedupe storage first. Would possibly make 
sense if both were disk, but...

STEPHEN STACKWICK | Senior Consultant | 301.518.6352 (m) | Stephen.Stackwick AT 
icfi DOT com | icfi.com
ICF INTERNATIONAL | 410 E. Pratt Street Suite 2214, Baltimore, MD 21202 | 
410.539.1135 (o)


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Prather, Wanda
> Sent: Monday, June 17, 2013 9:45 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Another VE mystery - restoring from tape - but shouldn't be
> 
> TSM 6.2.3
> Backup done with TSM VE 6.4.0.0 and TSM client 6.4.0.0.
> 
> VMCTLMC points to a dedicated sequential pool on fast disk.  That pool has no
> NEXTSTGPOOL defined.
> 
> VMMC points backup data to a deduplicated sequential pool on fast disk
> storage.
> After the server dedups it there, it migrates to a slower NAS-based 
> deduplicated
> storage pool on disk.
> When that slower pool fills, data migrates out to tape.
> DEDUPREQUIRESBACKUP set to YES.
> (No client-side dedup used.)
> 
> We have done full VM restores through the plug-in and file-level restores
> through the recovery agent in the past, including testing restores from tape,
> with no problems.
> 
> Now one of the customer's VM datastores has met with an unfortunate accident
> in a dark alley.
> We need to restore 7 full VM's.
> 
> From the dsmc command line, restore vm victim1  datastore=newhealthyone
> starts up OK, but was calling for a zillion tape mounts, and therefore was
> restoring at the rate of about 4GB per 24 hours.
> 
> So, we did MOVE NODEDATA DCNAME FILESPACE=victim1 to bring the data
> from the tape back to the sequential disk pool.
> Cranked up again, same result - requesting a zillion tape mounts.
> 
> So riddle me this:
> If the control information is on disk, and the filespace is back on disk, 
> what are
> the tape mounts going after?
> 
> (FWIW, tried upgrading VE to 6.4.0.1 and data mover to 6.4.0.4, no 
> difference.)
> Signed, Confused by VE.  Again.
> 
> Wanda Prather  |  Senior Technical Specialist  | Wanda.Prather AT icfi DOT 
> com  |
> www.icfi.com ICF International  | 401 E. Pratt St, Suite 2214, Baltimore, MD
> 21202 | 410.539.1135 (o)