Tim and Wanda,
Agreed with Tim. If you have a management policy that says retain "x"
versions of a file and you are using subfile backup, then the most that
will ever exist on the server should be x+1; I have worked out several
scenarios on paper and the worse case should be that the oldest version of
the file is dependent on a base file, so that base file is retained by the
server.
I think there was an error in the Redbook statement that 20 subfile
backups would be taken before a new base file was automatically used. The
original code had a specification of resending a base file if 20 epochs
had passed since the last base file was taken. An epoch was described as
an instance of a backup operation, be it a selective backup of a single
file, or a incremental backup of the entire file system. So, the original
rule was that if 20 of these epochs had passed, take a new backup of the
base file. There were a number of reasons for using this concept of an
epoch; it guaranteed you weren't doing something bad during the same epoch
(e.g., send a file to the server which isn't committed because there was a
tape mount, then turn around and try to base a delta from something which
doesn't have a committed base file), it safeguarded against possible
de-sycnronization between the client and server, and the epoch also was
used to help to predict when storage costs would exceed the cost of
sending a new base file (the number 20 came from research in this area -
it was believed after 20 epochs it was probably more cost effective to
send a new base file).
It turned out that the epoch didn't adequately solve the first two
problems. We found more elegant solutions in creating an affinity between
base file in client cache to the transactions on the server and a
bullet-proof method of making sure the base file on the client cache was
in synch with what the server had stored as a base file. In short, as we
found better solutions for these problems we moved away from the concept
of the epoch. The epoch counting was never appeared in any GA version of
the product.
Today the client code will send a new base file in these cases:
- if the last time the detla was taken, the ratio of delta:base is > .40
- digital signature of base is incorrect or doesn't match signature on
server
- base entry on client cache is dirty, i.e., never committed on the server
- size of base file falls < 1024
- file is excluded from subfile backup processing, i..e, exclude.subfile
- file is encrypted by Windows efs
Also, system objects never use subfile processing.
Hope this information helps.
- Jim Smith
TSM Client Development
Hmmm, that doesn't make any sense to me. I just checked my backup table
and
see similar results. If TSM has only taken 1 base file backup, then
shouldn't there be only 1 extra version? My management class for this
server is keeping 30 days worth of backups (unlimited versions). But I've
got a heck of a lot of files older than 30 days. Plus I'm pretty sure
I've
only done 1 base file backup. Back to support ...!
The only reason I'm looking at sub-file backup is for space savings!
Support did not mention when TSM takes a new base file - only that it
doesn't use the 20 limit (this really didn't make any sense anyways - why
send a new base file if you don't need to?).
I assume TSM still follows the other methods documented in the Red Book or
other papers:
- if delta file exceeds 60% of base
- if digital signature of reference file in cache does not match signature
on server
- if digital signature or reference file do not exist in the client cache
Of course since these are not officially documented anywhere they could
have
changed by now (or in the future)!
I'll keep you posted on anything I found out on this.
Thanks,
Tim
-----Original Message-----
From: Prather, Wanda [mailto:Wanda.Prather AT JHUAPL DOT EDU]
Sent: August 20, 2002 1:16 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Sub-File Backup - Number of Delta File Backups
Tim,
I'm seeing the same results as you.
If I run the backup table for a client and look for backups of specific
files, I sometimes see more than 20 "versions" of the same file, even
though
I should only have 6. I concluded that it must be caused by the subfile
backup - even if you tell TSM to keep only 6 versions, it can't expire
the
base version, no matter what, until a new base is taken.
And I'm not sure you can guarantee a space savings on the server because
of
this.
I'm using it to reduce the amount of data transmitted per DAY, which was a
big issue with me due to having 450 clients on 1 TSM server.
That was pretty easy to document using the accounting records, as we get
pretty consistent numbers from day to day.
Implementing subfile backup dropped my total daily load by 25-30% (and I'm
pretty sure the biggest chunk was those .pst files).
Did they mention to you when how TSM DOES decide to take a new base file
now?
Wanda
-----Original Message-----
From: Rushforth, Tim [mailto:TRushfor AT CITY.WINNIPEG.MB DOT CA]
Sent: Tuesday, August 20, 2002 11:55 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Sub-File Backup - Number of Delta File Backups
I've just received the following from TSM Support:
Hello,
After going through the code and confirming with development, the
reference
made in the Redbook is invalid. The original prototype for subfile backup
had the limitation of 20 subfile backups before a new full ("base") backup
was taken, but when subfile backup was implemented for general release,
the
20-subfile backup limit was removed. The behavior the customer is seeing
is
correct. The information in the redbook must have been based on the
prototype description, which is now obsolete. This is a case that
demonstrates why Support does not officially support information
documented
in Redbooks, as the information contained in them can be incorrect or out
of
date. TSM does not have a limit for the number of subfiles that can be
sent
prior to a new base file being backed-up. . Regards,
- - - -
ADSM/TSM Support Team
|
