-----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Hans Christian Riksheim Sent: Tuesday, June 10, 2014 8:47 AM To: [email protected] 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 <[email protected]> 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 > [email protected] > Mobile :+918019002843 > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf > Of Roger Deschner > Sent: Tuesday, June 10, 2014 10:29 AM > To: [email protected] > 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 [email protected] > ======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 >
