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
>
|
