Kevin,
Have you verified that the MODE parameter of the copygoup is not set
to Absolute?
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Kinder, Kevin P
Sent: Tuesday, January 29, 2008 11:44 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] TSM performing full backups where incremental
specified
Richard, and others,
Thanks for the on- and off-line responses. I have followed up the
suggestions made, but so far no success.
Richard,
I checked to make sure that nothing was strange with the filespaces. I
actually did an incremental from the command line, then followed it up
immediately with another, and sure enough almost all the files backed up
twice. DSMC Q FI shows just one occurrence of each defined filespace, so
I don't think anything is happening to them between backups. In this
case, it would have had to have happened in about one minute.
Q BACKUP on the client shows multiple instances of each file -- one
active, the rest inactive. I don't see anything on the details of each
file that indicates a change. Last access date, file size, all appear
identical. I chose several operating system files that I know have not
changed since the last server upgrade (more than a year ago) and they
still back up when using INCREMENTAL by itself.
The number of files backed up is just a few dozen short of the number
inspected - a difference which is attributable to those files that were
open (such as log files) and could not be backed up. Obviously, with
full backups running each night, my tape count in increasing
dramatically.
I have run traces, and have a call open with IBM. It has been open for
20 days. They are stumped as well, and have no idea what to do. So, I
was trying this avenue again in the hope that someone else may have seen
this.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Richard Sims
Sent: Monday, January 28, 2008 5:43 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] TSM performing full backups where incremental
specified
Kevin -
Heck of a problem you have there. I don't do z/OS or Netware, so
unlikely that I'll have an answer, but some thoughts...
This is too obvious, but: The filespaces involved are not in some way
being renamed or deleted in between the mass incrementals? That would
cause a full backup. Seems very unlikely to me, but one thing I would
consider. Does a 'dsmc q fi' show a singular instance of the suspect
file system? Here I'm thinking of some oddity causing the server to
believe that the file system is different each time. But, tape
consumption would cause this to stand out.
In the backup log, does the number of objects backed up equal the number
inspected? If a substantive difference, I would look into the
exceptions to see what's the basis of their immunity. Also, perform a
'dsmc q ba -detail -ina _______' on one of the files and see if all
versions look the same, or there is some different which might incite
the backup. And, if you don't see a bunch of versions, it may be
possible that some mutation to the policies is causing obliteration of
what was backed up the last time.
As a last resort, I would run a client trace of your partial versus
unqualified incrementals and see if any functional differences stand out
in causing the mass backups. If nothing apparent, give TSM Support a
call.
wacky stuff I can think of, Richard Sims
IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason
therefore recommends that you do not send any confidential or sensitive
information to us via electronic mail, including social security numbers,
account numbers, or personal identification numbers. Delivery, and or timely
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends
that you do not send time sensitive
or action-oriented messages to us via electronic mail.
This message is intended for the addressee only and may contain privileged or
confidential information. Unless you are the intended recipient, you may not
use, copy or disclose to anyone any information contained in this message. If
you have received this message in error, please notify the author by replying
to this message and then kindly delete the message. Thank you.
