That's pretty gutsy, deleting filespaces, even after 120 days of inactivity.
Aren't you worried you might delete someone's archived files?

Our kinder, gentler approach is to stop mailing messages about the
filespace, after issuing three "last" warning messages.

Our not-so-kind registration requirement is to require  three separate
contacts (we send mail to all of them), one of which is the manager of the
other two.  Unfortunately, the ADSM contact field is long enough for all of
the information that we want so we have an external registry.

Jim

> ----------
> From:         Tom Bell[SMTP:tom.bell AT WAII DOT COM]
> Sent:         Thursday, May 21, 1998 3:04 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: How do you deal with...?
>
> > I'm wondering how large shops deal with the problem that when a
> filesystem
> > is deleted from a client, ADSM will not expire backups of files in that
> > filesystem.   I had expected that it should treat them just as deleted
> > files, but when I found lots of old backups of files from deleted
> > filesystems, the support center explained that the only way to destroy
> > the backups was to delete the filespace in ADSM.   This seems like an
> > administrative nightmare in a large shop with lots of clients.
>
> We have an AIX server backing up AIX, IRIX, and Solaris clients.  We
> have a mix of production and development users and we see fairly
> frequent configuration changes.  Our solution to the problem is to run a
> suite of daily cron jobs that perform the operations that we don't have
> enough administrators to do manually.  One convention we established
> that has helped is to put the Email address of the "responsible" party
> for each client in the Contact field during node registration, allowing
> our cron jobs to notify the responsible party (and CC the ADSM
> administrators) when a problem or potential problem is detected.
>
> Specifically addressing the situation you noted, we issue a "q node f=d"
> to pick up the node names and contact field, then cycle through all the
> nodes issuing a "q file <node> f=d" to pick up the filesystem name and
> days since last backup completion.  Once the days since last backup
> completion hits 3, we start generating Email.  At 120 days (if it
> hasn't been dealt with manually before then), we issue "del file"
> commands.
>
> --
> Tom Bell                                    tom.bell AT wg.waii DOT com
> Western Geophysical                         office:     (713) 689-2203
> 10001 Richmond, Room 2679                   pager:      (713) 415-0419
> Houston, TX  77042
>