-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Hans Christian Riksheim
Sent: Tuesday, June 10, 2014 8:47 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Restoration Issue in TSM 5.5...

My advice is to not use the GUI. Until IBM eventually decides to make a working 
GUI there should be a big red warning stating that if you are going to restore 
more than a few files the CLI must be used. (And not even then can the GUI be 
trusted [1] )

I experienced the same as you. Used the GUI when restoring a few million files 
and the TSM-server started an endless task of mounting and dismounting volumes. 
However with the CLI it worked fine after a period of NQR processing. Not sure 
why the different behavior(I did not tick the "Disable NQR restore in the GUI".)


[1] http://www-01.ibm.com/support/docview.wss?uid=swg21162784

Regards,

Hans Chr.




On Tue, Jun 10, 2014 at 7:36 AM, Kiran <kiran AT dqentertainment DOT com> wrote:

> Hi Roger ,Thank you for the response .This is Linux Client with GPFS 
> as file system.
>
> WE have more than 2 millions of folders in the file system.
>
>
> Regards,
> Kiran M
> DQ ENTERTAINMENT (INT) LTD
> kiran AT dqentertainment DOT com
> Mobile :+918019002843
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Roger Deschner
> Sent: Tuesday, June 10, 2014 10:29 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Restoration Issue in TSM 5.5...
>
> Is the client Windows? If so, you should have been using the DIRMC 
> technique to back up Windows directory objects to an online storage 
> pool.
>
> But, now that you are restoring, it's too late for that. Halt the 
> restore, and run MOVE NODEDATA to an online DISK or FILE storage pool.
> It can be a temporary online storage pool just for this restore. Then 
> run your restore, and it will go fast. When this restore is done, let 
> it migrate back to tape.
>
> BACKGROUND: Windows directory objects are too large to fit in the TSM 
> database, so they are written to the storage pools along with the 
> data, and eventually migrated to tape. When restoring, TSM has to 
> restore all the directory objects first, which may only be a few bytes 
> per tape, so it's going to mount tapes over and over restoring only a 
> very small amount of data each time, until it rebuilds the entire 
> directory tree so it can start restoring actual data. OTOH, Unix (AIX, 
> Solaris, Linux,
> MacOSX...) directory objects are a lot smaller, and fit in the TSM 
> database itself, so you won't experience this problem with Unix clients.
>
> The workaround has always been to use DIRMC to direct Windows 
> directory objects to a different Management Class that is stored 
> online. They're not that large, so you can afford to keep them online. 
> (Search the ADSM-L archives for DIRMC and you'll find lots of 
> information about it.)
>
> But if you are stuck with this problem, and you are doing a restore, 
> the only immediate workaround to get your restore to finish in a 
> reasonable amount of time is MOVE NODEDATA to an online storage pool. 
> This applies to all releases of TSM, Server v5.5 or later.
>
> Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT 
> edu
> ======I have not lost my mind -- it is backed up on tape 
> somewhere.=====
>
>
> On Tue, 10 Jun 2014, Kiran wrote:
>
> >Hi, We are using TSM Server and client 5.5 .5 . We are facing slow 
> >restoration issue.
> >
> >
> >
> >Our restore size is 4TB.
> >
> >
> >
> >Usually whenever we perform restore (dsm restore) or with GUI BA 
> >Client it should display the following
> >
> >
> >
> >ANR1182I Removable volume 000519L2 is required for a restore request 
> >from session 553
> >
> >
> >
> >But restore session is mounting all tapes with creating directory 
> >structure instead of data along with the directories.
> >
> >
> >
> >Please help.
> >
> >
> >
> >
> >
> >Regards,
> >
> >
> >
> >Kiran
> >
> >Disclaimer: http://www.dqentertainment.com/e-mail_disclaimer.html
> >
>
> Disclaimer: http://www.dqentertainment.com/e-mail_disclaimer.html
>