There is the problem of the disappearing file systems...
     We've had some clients have file systems disappear out of ADSM's sight  
     one night (thus all the active files associated with it were deleted),  
     then the next day it showed back up to adsm and every file was backed  
     up.
      
     You are probably correct in that something smells really bad...  
      
     check into it a little more


______________________________ Reply Separator _________________________________
Subject: Re: Expire problem?
Author:  Rene.Lambelet (Rene.Lambelet AT nestle DOT com) at unix,mime
Date:    6/30/98 7:26 AM


Hello,
      
I think this is ok, as adsm seems to only examine objects where something  
can be deleted.
      
This morning I had:  55'518 obj. examined, 24'087 backup obj. deleted,  
30'793 obj, deleted
      
Regards,
      
René Lambelet - *3543 - *A581  
Nestec SA - 55, Av. Nestlé - CH-1800 Vevey
Tel: ++41/21/924'35'43 / Fax: ++41/21/924'45'89  
E-Mail: rene.lambelet AT nestle DOT com
      
      
      
> -----Original Message-----
> From: Gene Mangum [SMTP:gmangum AT UMICH DOT EDU]  
> Sent: Tuesday, June 30, 1998 12:08 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Expire problem?
>  
> I just upgraded my server to 3.1.1.3 yesterday.   Every night, I have a  
> set of scripts which process the days backups as follows:
>  
>    - force migration of disk stg pools to tape  
>    - backup stg pools
>    - backup DB (2 copies - 1 offsite, 1 onsite)  
>    - expire inventory
>  
> Since last night was the first run under v3, I watched closely.   It went  
> OK for the most part, but when expiration started, it seemed to be
> expiring too much, so I cancelled it and locked all nodes (in case I have  
> to back out).   When I cancelled it, the numbers were: examined-6465,
> deleted-6389.   This seems like ALOT!  
>  
> Can anyone explain what might be happening?   Thanks for any help.  
>  
> --
> Gene Mangum
> University of Michigan Medical Center