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 <ki...@dqentertainment.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 > ki...@dqentertainment.com > Mobile :+918019002843 > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Roger Deschner > Sent: Tuesday, June 10, 2014 10:29 AM > To: ADSM-L@VM.MARIST.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 rog...@uic.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 >
