Andy Raibeck wrote:

Mark,

We've been discussing this internally amongst ourselves, and the client
and server books are definitely out of sync. We will look into getting
them corrected, and updating this forum with the final answer.

Just to clarify a couple of points:

- When incremental-by-date is used to back up a file system, the last
backup date for the file space IS updated.

- In an earlier post on this thread, you said, "All PIT restores a
relative to the previous LID, i.e. if the LID is 8/8/02 4:00 and you do a
PIT restore specifying a pitdate and pittime of 8/8/02 8:00 it will roll
back to the previous LID of 8/8/02 4:00." I'm not sure I really understand
what you are getting at. When doing a point-in-time restore, if a backup
version meets the point-in-time criteria, then it will be restored
regardless of what method was used to back it up. PIT restore keys off the
date/time the backup version was created, not when the file system was
backed up. So if the LID was 08/08/2002 04:00, but at 06:00 someone
subsequently backed up some additional files, then a PIT restore using
date/time criteria of, say, 08/08/2002 07:00 would restore the backup
versions created at 06:00. The volume's LID isn't really relevant.

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.eyebm DOT com (change eye to i to reply)

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




"Mark D. Rodriguez" <mark AT MDRCONSULT DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08/12/2002 15:15
Please respond to "ADSM: Dist Stor Manager"


       To:     ADSM-L AT VM.MARIST DOT EDU
       cc:
       Subject:        Re: Incremental Backup (full/partial)

Andy,

You made two points and I will answer each one separately.

1) I stand corrected (well actually I am sitting) on the "incremental
-incrbydate" is updating the the LID feild in the "q files" command.  I
am not sure whether that was the case in the past, but that doesn't
really matter.  I am glad that you pointed that out because it is
important to know when the LID gets updated since that is the TS that
the next "i -incrbydate" is going to use.  Also, remember that if you do
the other type of "partial incremental", i.e. "i /filespace/filespec"
you do not get the LID updated.  This effects which files will be
deteced if you use the "-incrbydate" option later.  Try the following:
do an "incremental  /filespace", the lid will be X and command completed
at X
do an "incremental /filespace/filespec". the command completed at Y and
the LID will still be X
then copy file1 into /filespace with a TS older than X, i.e. cp -p
then copy file2 into /filespace with a TS newer than X and older than Y
then copy file3 into /filespace with a TS newer than Y
now do a incremental -incrbydate, file1 will not be backed up, but file2
and file3 will since they are newer then the LID X

This proves that the "-incrbydate" keys off of the LID which is updated
by an "i" or "i -incrbydate" without using a filespec that is not an
exact filespace name.

But now I will ask the question, does anybody really use the
"-incrbydate" option?  I have been doing this for many years and I have
yet to use this option anywhere but in the classroom!

2) I will admit my explanation of the PIT restore was not as clear as it
could be.  And I will not attempt to rewrite the documentation in this
note.  The point I was refering to in regards to PIT restores is
releative to the files that were removed from your system.  The main
difference between a PIT restore and a todate/totime restore is the PIT
restore will not restore files that were removed from the system prior
to the PIT.  Since we only track deletion of files when a "full
incremental" occurs we will roll backward in time to the previous "full
incremental" TS in order to determine what files were and were not there
at the time.  This becomes critical if the client storage is limited,
since we may restore many more files then needed.  Effectively what
happens is we restore all files that where present at the PIT.  The
trouble spot is for files that were deleted after the previous "full
incremental" and before the PIT, in that case we will restore the file.
There is one othe gotcha, do not make the PIT the exact same TS as the
"full incremental" since it will roll backward to the previous one and
you won't get what you were expecting.

I do use PIT restores quite regularly.  The key for these to be
effective is to have regular "full incremental" backups, at least daily.
Also, there are some policy requirements for this that are well
documented in the manual.

BTW, in the "Using the Backup-Archive Client" manual in chapter three
there is a section that describes "Partial Incremental" as having 2
types one is "-incrbydate" and the other they refer to as "Incremental
backup of selective files and directories", anyway just another
explanation of what we have discussed.

--
Regards,
Mark D. Rodriguez
President MDR Consulting, Inc.

===============================================================================
MDR Consulting
The very best in Technical Training and Consulting.
IBM Advanced Business Partner
SAIR Linux and GNU Authorized Center for Education
IBM Certified Advanced Technical Expert, CATE
AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux
Red Hat Certified Engineer, RHCE
===============================================================================