Ah, I hate to be a Noodge, but I believe you were correct originally, Andy, and that Mark is actually incorrect in his definition of a Partial Incremental Backup. I think I've even proven it. (Note, Mark's right with everything else he says. Very fine summary, I'd say.) I agree with Mark that we all need to understand the issues to have a complete understanding of TSM, and a complete understanding of TSM parlance will enable us to share knowledge effectively.
I've included the text from the Admin Guide below. Please direct your attention to the statement, "For example, the server does not expire files or rebind management classes to files during a partial incremental backup." I've included, after the Admin Guide text, an example showing that what Mark defines a Partial Incremental Backup actually does expire files, and thusly is not a Partial Incremental Backup. The DF shows that / is the filesystem, that /root/* is a filespec that is not just a filespace name, satisfying Mark's definition of a Partial Incremental Backup. I touched mytempfile, inc'd it, rm'd it, and inc'd it again. /root/mytempfile was expired, proving this was not a Partial Incremental Backup. Mark states, correctly, that a incrbydate doesn't expire files. An incrbydate is a Partial Incremental Backup. Does anybody see any faults in my argument? As Mark said, this isn't about who's right and wrong, this is about understanding what is refered to by the manual as a Partial Incmremental Backup. Alex Paschal Storage Administrator Freightliner, LLC (503) 745-6850 phone/vmail >From the TSM 4.2 Admin Guide (AIX), Chapter 12, page 246, Implementing Policies for Client Data > How Tivoli Storage Manager Selects Files for Policy Operations > Incremental Backup. >Backup-archive clients can choose to back up their files using full or partial incremental >backup. A full incremental backup ensures that clients' backed-up files are always managed >according to policies. Clients should use full incremental backup whenever possible. > >If the amount of time for backup is limited, clients may sometimes need to use partial >incremental backup. A partial incremental backup should complete more quickly and require >less memory. When a client uses partial incremental backup, only files that have changed >since the last incremental backup are backed up. Attributes in the management class that >would cause a file to be backed up when doing a full incremental backup are ignored. For >example, unchanged files are not backed up even when they are assigned to a management >class that specifies absolute mode and the minimum days between backups (frequency) has >passed. > >The server also does less processing for a partial incremental backup. For example, the >server does not expire files or rebind management classes to files during a partial >incremental backup. wkstst1[/root]# df -k . Filesystem 1024-blocks Free %Used Iused %Iused Mounted on /dev/hd4 49152 29048 41% 2767 12% / wkstst1[/root]# touch mytempfile wkstst1[/root]# dsmc inc ./\* Tivoli Storage Manager Command Line Backup Client Interface - Version 4, Release 1, Level 3.0 (C) Copyright IBM Corporation, 1990, 2001, All Rights Reserved. Node Name: WKSTST1 Session established with server TSMTEST: AIX-RS/6000 Server Version 4, Release 1, Level 3.2 Server date/time: 08/12/02 10:52:09 Last access: 08/12/02 09:35:49 Incremental backup of volume './*' Normal File--> 1,954 /root/.sh_history [Sent] Normal File--> 13,073 /root/errpt.out [Sent] Normal File--> 179,586 /root/errpt_a.out [Sent] Normal File--> 0 /root/mytempfile [Sent] Successful incremental backup of '/root/*' Total number of objects inspected: 420 Total number of objects backed up: 4 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 190.15 KB Data transfer time: 0.00 sec Network data transfer rate: 94,510.08 KB/sec Aggregate data transfer rate: 47.44 KB/sec Objects compressed by: 0% Elapsed processing time: 00:00:04 wkstst1[/root]# rm mytempfile wkstst1[/root]# dsmc inc ./\* Tivoli Storage Manager Command Line Backup Client Interface - Version 4, Release 1, Level 3.0 (C) Copyright IBM Corporation, 1990, 2001, All Rights Reserved. Node Name: WKSTST1 Session established with server TSMTEST: AIX-RS/6000 Server Version 4, Release 1, Level 3.2 Server date/time: 08/12/02 10:52:24 Last access: 08/12/02 10:52:11 Incremental backup of volume './*' Normal File--> 1,986 /root/.sh_history [Sent] Expiring--> 0 /root/mytempfile [Sent] Successful incremental backup of '/root/*' Total number of objects inspected: 420 Total number of objects backed up: 1 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 1 Total number of objects failed: 0 Total number of bytes transferred: 1.97 KB Data transfer time: 0.00 sec Network data transfer rate: 59,807.05 KB/sec Aggregate data transfer rate: 0.65 KB/sec Objects compressed by: 0% Elapsed processing time: 00:00:03 -----Original Message----- From: Andy Raibeck [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 11, 2002 5:59 AM To: [EMAIL PROTECTED] Subject: Re: Incremental Backup (full/partial) Mark, I was indeed in error when I equated "Partial Incremental" with "Incremental by date". You are correct about partial incremental being against one or more files or directories, vs. the entire file system. Best regards, Andy time to do some brushing up myself 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/09/2002 21:02 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Re: Incremental Backup (full/partial) KEN HORACEK wrote: >Hi fellow listers, > >So here I am, "Reading the Fine Manual", and it sez; an Incremental Backup can either be "full" or "partial".. >How can I tell if my backup(s) are requesting a "full" or "partial" backup? > >Ken >[EMAIL PROTECTED] > > Hi Everyone, I am going to take a stab at this one. I have seen several others have as well. I do want to qualify my answer and say that when I here people refer to "full" or "partial" incremental then I give the explanation you will see below. I believe my explanation to be correct based on all of my reading of the documentation as well as the education material that IBM/Tivoli has been putting out for the last many(I think ed classes have been around for almost 10) years. Anyway, I certainly hope I am right since this is the way I have been teaching it for many years. A "full" incremental is when you issue an incremental command (command line or scheduled) that either has no filespecs or the filespec is an exact string of a filespace. The following are all considered "full" incremental: tsm> i tsm> i c: tsm> i c: d: or on a unix box tsm> i tsm> i /home tsm> i /home /opt This assumes that c:, d:, /home, /opt are all filespaces. A "partial" incremental is when you qualify the backup using a filespec that is not just a filespace name. The following are all considered "partial" incremental: tsm> i c:\mydir\* tsm> i c:\mydir\* d:\tmp\file or on a unix box tsm> i /home/* tsm> i /home /opt Both of these commands still process the include/exclude list in the same way. However, for the partial it will only backup the files based on the filespec, i.e. some include statements will not apply. The real big difference between the two is that the "full" incremental will update the value "Last Incr Date" (LID) that you see for the filespace when you do a "q filespace". This is a very important date a couple of things key off of this date. One it is used when the "-incrbydate" option is specified(more on that later) and it is also used when your are doing a Point In Time(PIT) restore. 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. The next item there seems to be a great deal of confusion about what the "-incrbydate" option really does. Please refer to my post on 8/8/02, the subject was "incremental and incremental -incrbydate" . There was one response that gave a completely erroneous answer, but I hope my answer will clarify the differences between "incremental and incremental -incrbydate". I won't reiterate everything that I covered in that post, but I do want to speak to what some of the people posted in this thread. There were a couple of post that implied that a "incremental -incrbydate" was in fact a partial backup. I think that is somewhat correct but misleading. A partial backup is as I stated above, however what my references above and an "incremental -incrbydate" have in common is that neither will update the LID. The differences between the two are much greater, remember the "-incrbydate" option changes the way incremental decides what files will be backed up, it only compares the files data modified time stamp to the LID and if newer back it up. But more significant is what it does not do: * Will not recognize any deleted files, i.e. no files expire. * Will not rebind any files if management classes have changed. * Ignores the copygroups frequency settings. A "partial" incremental does effectively all the same processing as a "full" it just does it to a subset of the files in a filespace as defined by the filespec when the command was issued. BTW, for those of you who pull a lot of info directly from the TSM DB, the LID can be found in the table "filespaces" and the attribute is "BACKUP_END", as you can see it is actual the time stamp of when the "full" incremental has completed. I apologize for such a long post, I just hate to see confusion about important concepts that TSM is based upon. I good understanding of the basic concepts and terminology goes a long way. -- 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 ============================================================================ ===