ADSM-L

Re: Really strange - unable to restore directories...

2004-04-30 13:40:59
Subject: Re: Really strange - unable to restore directories...
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 30 Apr 2004 11:34:53 -0600
If you do QUERY SESSION from an admin console, what is that state for the
client session? My guess is probably "run" if the server is busy rounding
up the data.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.



David McClelland <David.McClelland AT REUTERS DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/30/2004 10:02
Please respond to
"ADSM: Dist Stor Manager"


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Really strange - unable to restore directories...






Hi gang,

This is causing some people some real pain :o( I need some help,
thoughts, ideas etc.

Server - Win2K 5.1.6.2
Client - Win2KAS 5.1.6.7

On this client, there is a *big* SAN filesystem, storing lots of user
profiles - for example, the profile root has around 7,500 username
directories, and each of which has lots of children directories within
them. Or rather 'had' until yesterday afternoon, when the directory
appears to have been emptied (although because of the nature of the app,
some of the data was subsequently rewritten). Since then, a TSM backup
has run and has done its best to expire most of the objects - I
cancelled this 'backup' when the first restore appeared to fail with the
below.

Upon attempting to restore (point in time to a couple of days ago) from
any of the user directories downwards (e.g.
\\myclient\g$\users\profiles\user.name\ ) all I get is "ANS1247I Waiting
for files from server". The client sits there, apparently waiting, and
although the session is still visible on the TSM server, there's no
traffic between client and server. The server doesn't seem to be doing
*anything* at all - it is a server dedicated to this client, and is
otherwise, as far as I can tell, fully functional. I've left the client
'waiting' for a good long while with no response whatsoever.

Now, if I try to restore a file from within one of those directories,
the restore is instantaneous (large diskpool and caching enabled) and
successful. It's parent directories are created (although not *restored*
- at least the NTFS permissions aren't as they should be had they been
properly restored).

I've tried different levels of client (well, 4.2.0.0 which happened to
be on there - I'm going to try 5.2.2 when I've sent this note), I've
tried restoring to local disk, and I've tried the restore on the TSM
server itself (-virtualnodename is my friend here), all with the same
(non) results. I've stop started TSM and the rebooted the TSM server.
Before I attempt a restore, I do a 'show locks' and there are none
there, but after a (failed) attempt at restoring, I see from a show
locks some locks hanging around.

I can perform a 'query backup' from the client of a user directory, and
all seems fine - I've checked the management class to which the
directory objects are sent, and they should all still exist according to
the directory retention policy (vere - nolimit, verd - nolimit, retextra
- 366, retonly - 366). They're even stored in the same primary storage
pool (disk) as the files are.

That's everything that I can think of to check for now - can anyone shed
any light on this, or think of some ideas, checks etc.

Your help is much appreciated - I promise I'll be there for you one day!

Rgds,

David McClelland


--------------------------------------------------------------- -
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

<Prev in Thread] Current Thread [Next in Thread>