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:storman AT US.IBM DOT COM]
Sent: Sunday, August 11, 2002 5:59 AM
To: ADSM-L AT VM.MARIST DOT EDU
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: 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/09/2002 21:02
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
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
>khoracek AT incsystem DOT com
>
>
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
============================================================================
===
|
