--> By the time I was apprised of the situation, the activity log had already
cycled past the relevant entries.
--> The retention policy, set by the IT Director for the particular Division
is 5/1/60/90

To prevent further frustration if I was you I would perform an export of
all node's data to be on a safe side.

Zlatko Krastev
IT Consultant






Fred Johanson <fred AT MIDWAY.UCHICAGO DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
20.02.2003 04:02
Please respond to fred


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Missing files


Quoting DFrance <DFrance-TSM AT ATT DOT NET>:

> The successful backups do NOT say all files were sent during backup;
> following thoughts may help you discover the true reason for the missing
> files:
>
> - C$ on WinNT (esp. Win2K) has lots of system-protected files that get
> skipped;  they are rolled into the system state "blob", so could be all
is
> a-okay.

 What's missing seems to all be under c:\My Documents

> - if you were using the scheduler, your dsmsched.log file contains a
line for
> every file processed; search that log for the signs the files were
(ever)
> sent... to learn the date and full-path to the source.
>

I restored the TSM logs and opt to my own desktop.  The options is
unremarkable, with all the excludes coming from a nondescript CLOPTSET.
The
schedule log exists as a fragment from six weeks before the headcrash. But
the
error log shows about two weeks of "fioscan" errors on c:\My Documents.
It's
hard to say what that means without the schedule log to correlate with,
but,
still, it's suspicious.

> - if a drive failure occurs, even if just files/dirs trashed, followed
by
> INCR backup, your retention policy for deleted files may be too short.
>

The retention policy, set by the IT Director for the particular Division
is
5/1/60/90.  I have always recommended 5/2/30/60.  Nonetheless, there was
still
enough leeway to fine deleted files on the first restoration attempt.


> - with the client installed, query inclexcl might reveal the files were
> excluded?!?
>

The machine was rebuilt under it's true DNS name, as opposed to the Domain
alias it had been backed up under.  Therefore, the backups are in a TSM
limbo.

> - scan the activity log (and dsmerror.log) for messages re. the files in
> question; maybe the files were skipped (or inactivated) due to copy-mode
or
> open-file contention.
>

By the time I was apprised of the situation, the activity log had already
cycled past the relevant entries.


> I agree that the user's data might have really been on a network share,
not
> the locally-failing drive, in which case, they might still be there;
> alternatively, the possibility of slowly-dying drive causing a huge
bunch of
> files to "disappear" is not very likely to go undetected more than a day
or
> 3... but, if that did really happen, you'd better "fix" the RetainOnly
value
> (to protect for this situation).
>

I'm still waiting for the SysAdmin and the User to come up with a coherent
story about the whole thing.  If the error log is any indication, the
Sysadmin
should have had weeks to investigate what was going wrong.  All I have
heard
was ex post facto.  At which point, all I can do is cluthc at straws.

On the bright side, this may lead to a eorganization of the way we do
things.


> Hope this helps.

Thanks, Don.


>
>
> Don France
> Technical Architect -- Tivoli Certified Consultant
> Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390
> San Jose, Ca
> (408) 257-3037
> mailto:don_france AT ayett DOT net (change aye to a for replies)
>
> Professional Association of Contract Employees
> (P.A.C.E. -- www.pacepros.com)
>


Fred Johanson