ADSM-L

Re: Sub-File Backup - Number of Delta File Backups

2002-08-20 14:17:38
Subject: Re: Sub-File Backup - Number of Delta File Backups
From: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 20 Aug 2002 14:16:05 -0400
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


 Forum:   ADSM.ORG - ADSM / TSM Mailing List Archive
 Date:      May 28, 11:41
 From:      Rushforth, Tim <TRushfor AT CITY.WINNIPEG.MB DOT CA>

The IBM Redbook - TSM 3.7.3 & 4.1 Technical guide - states "delta file
backup can occur up to 20 times before a new base file backup occurs again."

Can anyone confirm if this is still true?

I'm running 4.2.1.20 client on W2K, 4.2.0.0 Server on W2K.

I've setup a separate schedule to backup my outlook pst file using sub-file
backup. I'm tracking the amount of data sent every day.  I'm up to what
appears to be delta version 26.  Each delta version gets a little bigger (My
PST is 200 MB, first subfile was 7 MB, I'm now at 40 MB).  The base file in
my client cache directory has a modified date of April 24, 2002 - the first
day I started this.


My PST file was backed up 4 times outside of this special schedule so I
cannot confirm how much data was sent those 4 times (Outlook was left open,
PST was modified and backed up as part of regular schedule).  But if a new
base file backup had occurred then I'm assuming the modified date of the
base file in my client cache directory should have changed.  Also the delta
files after a new base backup should have reverted back to a smaller amount
of changed data - all of mine show a minor growth each day.

On another note, is there anyway to determine the space savings using
subfile backup?

Thanks,

Tim Rushforth
City of Winnipeg

<Prev in Thread] Current Thread [Next in Thread>