ADSM-L

Re: [ADSM-L] Orphaned filespaces

2007-04-05 07:27:45
Subject: Re: [ADSM-L] Orphaned filespaces
From: Ian Smith <ian.smith AT OUCS.OX.AC DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 5 Apr 2007 12:27:24 +0100
Bill,

We too have this problem - the task of identifying 'old' or 'dead'
data is made considerably more difficult by the null start and end
dates on filespaces.

We get round this by querying the latest backup date of any object in
each client filespace foreach node from the backups table - as below:

select filespace_name, max(backup_date) from backups -
where node_name='NODENAME' group by filespace_name

However, the backups table is the largest table in our view of the
TSM DB and the queries take a corresponding amount of time to run -
so run this at a 'quiet' time on your server.

Regards
Ian Smith
Oxford University Computing Services


On Wednesday 04 Apr 2007 4:28 pm, Bill Kelly wrote:
> An important little caveat to using the backup_start and/or backup_end
> columns in the filespaces table: these values are only updated when a
> "full incremental" backup is run.  From what I can tell, that means
> when:
>
> 1) a client schedule with action=incremental runs, or
> 2) in the GUI, "Actions/Backup Domain" is clicked, or
> 3) a command line "dsmc incremental" is run (not a selective one,
> either - no paths can be specified)
>
> We have a bunch of people who don't like/don't want to run scheduled
> backups (don't ask me...we're a university), and who just do occasional
> backups of C: drives and such via the GUI.  These people's filespaces
> *always* show null backup_start and backup_end dates.  Richard, I
> suspect this is what's happening occasionally at your site.
>
> These null date fields are a real pain for me; there's no good way to
> determine whether such filespaces have been 'abandoned' (e.g., old PC
> goes away, new PC comes in and filespace name changes) or not.
>
> -Bill
>
> Bill Kelly
> Auburn University OIT
> 334-844-9917
>
> >>> Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT COM> 4/4/2007 9:36 AM >>>
>
> I've come at orphaned filespaces from a little different angle.
> What I do is get a list of filespaces that have not
> been backed up in some number of days.  This helps for when
> filesystems
> on nodes get removed and the filespace with active files just sits in
> tsm .
> . . forever.
>
> This sql produces a list of filespaces that have not been backed up in
> 7
> days.
>
> (note_1:  The check for '%ZZRT%' excludes retired nodes - we rename
> retired
> nodes to
> a "zzrt_" prefix so they can be easily identified.)
>
> (note_2:  run from within a ksh script on aix)
>
> dsmadmc -se=$tsm -id=$adminid -password=$adminpwd -tab -noc <<EOD
>   select -
>       node_name, -
>       filespace_name, -
>       filespace_id, -
>       unicode_filespace, -
>       cast((current_timestamp-backup_end)days   as decimal(5,0)) -
>    from -
>       filespaces -
>    where -
>         node_name not like '%ZZRT%' -
>     and cast((current_timestamp-backup_end)days  as decimal(5,0)) \> 7
> -
>    order by node_name, -
>           filespace_id
> EOD
>
>
>
> I also run this . . .a variation of the above.  It attempts to find
> filespaces that have never been backed up.  Same notes from above
> apply.
> I'm not sure where/how these come about, but we seem to get a few.
>
>
> dsmadmc -se=$tsm -id=$adminid -password=$adminpwd  -tab -noc <<EOD
>   select -
>       node_name, -
>       filespace_name, -
>       filespace_id, -
>       unicode_filespace, -
>       backup_start, -
>       backup_end -
>    from -
>       filespaces -
>    where -
>         node_name not like '%ZZRT%' -
>     and ( backup_start is null -
>      or backup_end is null )  -
>    order by node_name, -
>           filespace_id
> EOD
>
>
> -----------------------------------------
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
> the reader of this message is not the intended recipient or an
> agent responsible for delivering it to the intended recipient, you
> are hereby notified that you have received this document in error
> and that any review, dissemination, distribution, or copying of
> this message is strictly prohibited. If you have received this
> communication in error, please notify us immediately, and delete
> the original message.