Hi Chuck,
The issue you speak of has always been in ADSM/TSM. The product didn't
examine and back up one file at a time. Rather, files would be grouped
into transactions based on TXNGROUPMAX and TXNBYTELIMIT settings. If,
during the processing of a transaction, one of the files targeted for that
transaction was deleted between the time it was targeted and the time TSM
started to process it, you could see the same problem you attribute to
current versions of TSM. The larger the transaction, the bigger window of
opportunity to see this condition, especially for active file systems.
Starting with TSM 3.7, the product moved to a multithreaded, multisession
producer/consumer model for backup. Producer threads would scan the file
systems and queue up transactions to be processed (backed up) by consumer
threads. With this model, I suppose it is possible that the "window of
opportunity" I spoke of above is increased somewhat since transactions can
be queued up further in advance of the backup. But it isn't as if we've
changed the product so that TSM makes one pass to examine files, then a
second pass to back them up.
Regarding TSM failing to back files up when it should not, if I understand
correctly, you are saying that TSM should have backed up the file as soon
as it was identified, but because of the delay, the file was deleted so
TSM missed its opportunity. I'm not sure this is a failing on TSM's part
as such, because if the file system is *that* volatile, then even if TSM
worked in the manner you desire, it still might have missed the file if
the scan started a second or two later, i.e. if the file was there at
01:30:06 but not there at 01:30:8, then whether TSM backs this file up --
be it version 2.x, or 5.x -- is really a hit or miss proposition,
depending on the point in time that TSM reaches that spot in the file
system. The only difference is that in version 2.x, this situation was not
brought to your attention. Thus I don't see this as a failure in TSM, but
that with earlier versions you had a "what you don't know doesn't hurt
you" situation.
I don't think there is anything wrong with the suggestion to exclude these
volatile files/directories, but like any advice of this kind, one needs to
consider its applicability in one's environment.
Having said all of that, I am not trying to be dismissive of your
concerns. while I haven't seen very many complaints about this behavior, I
don't discount that in your environment it is annoying. But if we were,
hypothetically, to move to a "scan it/back it up" model, we'd be taking a
major step backwards in performance. But if you want to get closer to that
model, try setting RESOURCEUTILIZATION to 1 and see if it makes a
difference. You can also try MEMORYEFFICIENTBACKUP YES to see if that
helps slow the scan down a bit.
5.2 includes open file support for Windows 2000 and XP, which I think will
eliminate this issue entirely for you (on those Windows platforms).
I'm not sure that any of this is a real help; if you require a more
comprehensive solution, then please consider opening a requirement and/or
pursuing through your IBM representative.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED]
Internet e-mail: [EMAIL PROTECTED]
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Chuck Mattern <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
06/27/2003 09:24
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: DSMC Exit Code Question
Hi Andy,
I agree that TSM should report a failure when a file identified as a
candidate for backup is not able to be backed up. What I have a problem
with is that in ADSM v2.x and v3.x the files were backed up as they were
identified. Once we went to ADSM v4.x and now TSM v5x it seems to have
adopted the dump methodology whereby it will examine a large number of
files (I'm truly not sure if it's hitting a directory at a time, a
filesystem at a time or a certain number of files) then come back to back
them up later. Since I don't have the opportunity to quiesce my
filesystems I'm guaranteed to have a large number of failures and invest a
good amount of my engineers time in investigating a situation that never
should have occurred. Essentially my complaint is not that TSM reports
failures, my complaint is that TSM fails to backup files when it should
not. Like ADSM2, ADSM3, tar, pax, afio et al, it should take the file
when
it is identified, not wait until it's programmatically convenient.
Advising users to simply exclude any files or filesystems where some of
the
files tend to turnover rapidly is not realistic in a large environment of
diverse server configurations managed by a lean staff.
Regards,
Chuck
Andrew Raibeck
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
OM> cc:
Sent by: "ADSM: Subject: Re: DSMC Exit
Code Question
Dist Stor
Manager"
<[EMAIL PROTECTED]
.edu>
06/27/2003 01:19
AM
Please respond to
"ADSM: Dist Stor
Manager"
There is no way to modify TSM behavior as you describe. In fact, your
statement about excluding the files is exactly one of the reasons why TSM
behaves as it does: so you can evaluate the reasons for the missed files,
and take the necessary actions. We feel that it is better to flag the
backup with an RC 4 and let you decide that you don't need backups for the
particular files, than to flag the backup with an RC 0, only to discover
after it is too late that you really needed the backups (in which case,
you'd probably be asking why TSM didn't warn you that it couldn't back up
the files).
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED]
Internet e-mail: [EMAIL PROTECTED]
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Andy Carlson <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
06/26/2003 13:08
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: DSMC Exit Code Question
I had an intersting question posed to me today and I don't have an
answer. This person is checking the return code on the dsmc command to
determine if the backup needs to be looked at or not. What he is coming
across is files that are in the directory when the directory is scanned,
but gone when the backup tries to back the file up. We did figure out
we could probably exclude the files, but what we would like is for TSM
not to give a non-zero return code what a file is not found. Thanks for
any input into this matter.
Andy Carlson |\ _,,,---,,_
Senior Technical Specialist ZZZzz /,`.-'`' -. ;-;;,_
BJC Health Care |,4- ) )-,_. ,\ ( `'-'
St. Louis, Missouri '---''(_/--' `-'\_)
Cat Pics: http://andyc.dyndns.org/animal.html
