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: [EMAIL PROTECTED] (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" <[EMAIL PROTECTED]> >Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> >08/12/2002 15:15 >Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > 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 ===============================================================================
