ADSM-L

Re: [ADSM-L] Backing up unavailable file systems causes objects to become inactive.

2007-09-26 14:05:04
Subject: Re: [ADSM-L] Backing up unavailable file systems causes objects to become inactive.
From: Bob Levad <blevad AT WINNEBAGOIND DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 26 Sep 2007 13:02:35 -0500
Thanks, we did some checking as to TSM's behavior if a file system drops
during a backup.  It correctly sees that files that should exist no longer
do and puts up an error.  We were concerned that our window of vulnerability
might extend past the running of the preschedulecmd.  Again, thanks for
pointing us in the right direction.

I'd still like to see an option that would force a prompt if a TSM process
felt the need to expire all files in a file system.

Bob.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Robert Clark
Sent: Friday, September 21, 2007 11:04 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Backing up unavailable file systems causes objects to
become inactive.

Write a script in your language of choice that compares the mount list with
a list of crucial filesystems like "/etc/ filesystems_crucial_to_backup"

Launch this script from the preschedulecmd, and if it returns a non- zero
code, the backup won't run.

For extra surety, you can look for files that should always be found on a
mounted filesystem, or look for files you've written to the underlying mount
point that you hope you never see.

[RC]

On Sep 21, 2007, at 2:22 PM, Bob Levad wrote:

> Greetings,
>
> I know this is "working as designed", but I was hoping someone might
> have a work-a-round.
>
> Several times over the last 10 or so years, we have had file systems
> on servers cause problems and become unavailable, either through
> inadvertent dismounts or hardware issues.  If we don't catch this
> quickly, TSM's behavior in these cases leaves something to be desired.
> TSM will assume that we have thrown away our data and will happily
> inactivate all of it's backed up objects.  When we discover the
> problem, we are faced with backing up the data again (unless it was a
> true disk failure) and even if it is a recovery scenario, we need to
> do a point in time restore, as all active data has been inactivated
> (also followed by another complete backup).
>
> What I'm looking for is ideas as to what I could do to automatically
> cancel any active backup job if a file system becomes unavailable for
> whatever
> reason.   Perhaps in some future version of TSM, a flag could be
> added for
> each domain statement to fail the backup and keep the previously
> stored data unless something explicit was entered to confirm the
> intent to expire.
>
> Thanks for listening...Any thoughts?
>
> Bob Levad
> Winnebago Industries, Inc.
>
>
>
> This electronic transmission and any documents accompanying this
> electronic transmission contain confidential information belonging to
> the sender.  This information may be legally privileged.  The
> information is intended only for the use of the individual or entity
> named above.  If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution, or the taking of
> any action in reliance on or regarding the contents of this
> electronically transmitted information is strictly prohibited.

This electronic transmission and any documents accompanying this electronic 
transmission contain confidential information belonging to the sender.  This 
information may be legally privileged.  The information is intended only for 
the use of the individual or entity named above.  If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or the taking of any action in reliance on or regarding the contents of this 
electronically transmitted information is strictly prohibited.