Patricia,
I am not familiar with the problem, but there is an APAR for the 4.2
client, IC31314, that may apply. Here is the description from the APAR
text:
========================================
Files may be expired because an OS automounter unmounts a
filesystem before TSM has processed it.
-
During a backup, TSM processes a filesystem in two stages.
During a backup, TSM processes a filesystem in two stages.
-
In the first stage, the TSM client compares what files are on
In the first stage, the TSM client compares what files are on
client filesystems to the files on the TSM server.
-
In the second stage, TSM processes each filesystem to
In the second stage, TSM processes each filesystem to
send changed/new files to the TSM server.
-
The automount option of the TSM client will mount a
The automount option of the TSM client will mount a
filesystem for the first stage. If the customer has
multiple filesystems, some filesystems that have
completed the first stage may need to wait for the
second stage. The OS automounter may unmount a
filesystem due to inactivity before the second stage
has begun processing the filesystem. TSM may expire
files on filesystesms that were unmounted before the
second stage.
-
The TSM client needs to verify that the filesystem is
The TSM client needs to verify that the filesystem is
still available before beginning the second stage.
-
Workaround:
Workaround:
The customer can increase the idle time allowed by the
OS automounter. The customer can also process each
automounted filesystem independently. This will help
to ensure that the second stage begins as soon as the
first stage has ended.
========================================
I would recommend that you contact IBM support about this problem so that
you can either verify that this is the problem, or else continue to
diagnose the trouble.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Patricia Max <pam AT tdo-serv.lanl DOT gov>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/09/2002 15:11
Please respond to Patricia Max
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: adsm/tivoli on redhat linux 7.1
One of my users lost 6 months of work because the adsm backups
(version 3) was not working correctly on his linux redhat 7.1
system but not giving any errors. Since that happened, I
have discovered at least 3 other systems, configured exactly
the same way, that are not working correctly.
What I have observed is
1. install backup software and initially back up system - everything
works.
2. next backup - directory in /home gets marked inactive.
3. never backed up again.
Similarities - all machines are set up as follows
/boot
/
/home
And under /home is a machine_name directory. For example if the machine
is yyy, then there is /home/yyy/ and /home/yyy/user. All machines run NIS
and
automount. In /etc/auto.master are the lines
/misc /etc/auto.misc --timeout=60
/n yp:auto.map -rw,intr
And in the master auto.map file is the line
yyy options yyy:/home/yyy
and then the user's home dir in /etc/passwd is /n/yyy
I set this up on solaris, hpux, irix, redhat6.2 and everything
works fine. Now on 7.1 (a supposedly supported system), the
client machine backs up the filesystem once and then marks it
inactive and never backs it up again. Hence 6 months of work
down the tubes.
The only difference I can find on my 7.1 machines is an extra line
in /etc/mtab that looks like
/home/yyy /n/yyy none rw,bind 0 0
Is this the culprit? Is adsm/tivoli unable to deal with this?
Or have I missed something? If this really is a bug, how do I
get a fix?
Thanks in advance
Patricia Max
Los Alamos National Laboratory
|
