Hi Bernhard,
A policy domain may have many management classes, each with different file
retention criteria. Within a given directory, it is possible to have some
files bound to one management class, other files bound to another
management class, still other files bound to a third management class, etc.
Maybe one class says to keep files for 14 days, another says to keep files
for 180 days, and the third management class says to keep files for 365
days. Also, you may add files to the directory over time, and set your
INCLUDE processing to bind them to different management classes.
Directories are bound to the management class with the longest RETONLY
setting so that, after you delete the directory (and its files and
subdirectories) from the client machine, you can at least recover the most
recent backup copy and the directory in which that file resided.
TSM has no way of knowing that you intend to keep *all* files on a
particular machine, now and forever, for only 14 days, so it can not decide
to use a management class for directories with a smaller RETONLY setting.
But if *you* know you intend to keep all files on a particular machine for
only 14 days (like in the example you gave), you can do a couple of things:
1) Use the DIRMC option to bind directories to the same management class
that your files use.
2) Create a new policy domain to which the machine's node will belong that
has only the one management class with the 14-day criterion.
Regarding your questions about what is in a directory and what is stored
for a directory: in older file systems like like the DOS FAT file system,
directories were indeed nothing more than just a mechanism for organizing
how files are stored withing the file system. But for other file systems
like on UNIX and NetWare, and newer Windows file systems like NTFS,
directories now have attributes (like security, ownership, etc.) associated
with them that files stored withing those directories can inherit. So it is
important that TSM be able to back up and restore the attributes for the
directories as well.
In answer to some of your specific questions that may not have been covered
above:
Q: What can I do with the directory if the files belonging to it are
expired?
A: Techincally you could restore the directory itself, although that would
most likely be of little practical use. But other than that, there is
nothing more you can really do with it.
Q: What is the state or content of the directory restored PIT to day 1
(from the example below)?
A: Whatever the state or content was at the time it was backed up. (I am
not trying to be "flip" here, but I am not sure what the point of this
question is.)
Q: Is it possible to restore MyFile.txt to the version of day 1 if the
directory backup belonging to it is expired?
A: Yes, with the exception that you can not restore that version with the
PIT restore feature from the GUI.
Regards,
Andy
Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
e-mail: [EMAIL PROTECTED]
"The only dumb question is the one that goes unasked."
Bernhard Unold <[EMAIL PROTECTED]>@VM.MARIST.EDU> on
03/08/2001 02:17:33 AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Point-In-Time Restore
Hello, Andy
I understand your arguments, but want to know the benefits of the method
to store the directory not in the same manner as the files. For Example
from a certain computer we do a archive, we want to keep for 14 days.
But the directories are kept for 365 days. So storage is wasted on tape
and in the db. For special purpose we have a mgmtclass without any
limits. Now some clients store their directories there at incremental
backup. No good idea!!
What is stored for a directory entry? What can i do with the directory,
if the files belonging to it are expired? In your example: What is the
state or content of the directory restored PIT to day 1? Is it possible
to restore Myfile to the version of day 1 if the directory backup
belonging to it is expired?
My idea is to store the directories together with the files. This would
solve a lot of problems.
Best regard
Bernhard Unold
Andy Raibeck schrieb:
>
> For those of you who remember ADSM Versions 2 or earlier, our
> backup-archive GUI used to obtain a list of *all* backup versions before
> displaying the restore tree. Because the list of all backup versions can
> grow extremely large (i.e. millions of files), this presented two problem
> areas: memory shortages on the client machine (to retain the list of
files
> in memory) and performance (because it takes a looooong time to build the
> list).
>
> Starting with Version 3, we took a different approach to how we get file
> backup information. Rather than try to obtain a list of all backup
versions
> initially, we only obtain a list of the objects that you can immediately
> see on the screen. For example, when you crack open (click on the + sign)
> the "File level" in the restore tree, we just show the available
> filespaces, so that is the only information we get from the server. When
> you click on one of the file spaces, we get a list of files that are in
the
> root directory of that filespace, which is then displayed on the
right-hand
> side of the GUI. When you crack open the filespace, we get a list of
> available directories directly beneath that filespace. When you click on
a
> directory, we get the list of files immediately under that directory. And
> so on and so forth.
>
> Because we are only getting lists of files for what you can see on the
> screen, the list is much smaller, so the GUI performance is vastly
> improved.
>
> The problem you are seeing with PIT restores via the GUI is in order to
see
> the files, you first need to be able to see the directories (so you can
> click on them to see the files or crack them open to view their
> subdirectories). But if there are no directories that were backed up
prior
> to your PIT specification, then there is no directory that can be
> displayed. Thus if there is no displayed directory, there is nothing for
> you to click on or crack open.
>
> The command line interface does not rely on the ability to display
> directories before it can display its files and subdirectories, so this
is
> why it does not have the problem.
>
> Directories are bound to the management class (within the policy domain)
> that has the highest "Retain only version" (RETONLY) setting, without
> regard to the number of versions that are kept. If two management classes
> have the same RETONLY setting, then you can not predict which class will
be
> used.
>
> If the management class with the largest RETONLY setting maintains only 1
> version, this will still be the class to which directories are bound.
Call
> this management class CLASS1 On the other hand, you might have files that
> are bound to another management class, say, CLASS2, with a lower RETONLY
> setting but maintains, say, 10 versions if the file exists (number of
> versions when file is deleted is not pertinent here).
>
> So here is a scenario:
>
> Day 1: File C:\MyDir\MyFile.txt is backed up. MyDir is bound to CLASS1
and
> MyFile.txt is bound to CLASS2.
>
> Day2: File C:\MyDir\MyFile.txt is changed. The MyDir directory is also
> changed. When the backup runs, MyDir will be backed up. Because only 1
> version is kept, the version that was created on Day 1 is deleted.
> MyFile.txt is also backed up and bound to CLASS2. There are now 2
versions
> of MyFile.txt.
>
> Now you need to do a PIT restore back to Day 1. However, since there is
> only one backup version of MyDir, created on Day 2, it will not be
> displayed in the GUI when you PIT criteria specifies Day 1.
>
> The key for PIT restores from the GUI, then, is to ensure that each
> directory has a backup version that is at least as old as the oldest file
> or subdirectory contained within that directory.
>
> I don't think there is any great way to ensure that you can *always* do a
> PIT restore from the GUI unless you have a management class for
directories
> that basically keeps all versions of directory backups forever (NOLIMIT).
> Depending on how often your directories change, this could potentially
> impact the size of our TSM database.
>
> The best compromise would be to establish a term of service with your
users
> that states how far back you will support PIT restores via the GUI. Then
> you can create a managment class for your directories with
> VEREXISTS=NOLIMIT, VERDELETED=NOLIMIT, and RETEXTRA=ndays,
> where 'ndays' is the number of days to which you will guarantee PIT
> restores via the GUI. For example, if you want to be able to go back up
to
> 30 days, then set RETEXTRA=30. Beyond 30 days, you will need to use the
> CLI.
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Tivoli Systems
> Tivoli Storage Manager Client Development
> e-mail: [EMAIL PROTECTED]
> "The only dumb question is the one that goes unasked."
>
> "Richard L. Rhodes" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on
> 03/07/2001 12:36:50 AM
>
> Please respond to [EMAIL PROTECTED]
>
> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: Point-In-Time Restore
>
> This brings up lots of questions:
>
> 1) How do you "keep enough directories" to enable PIT for the gui?
> 2) How would you not have enough directories to enable PIT if you
> have enough file versions to do PIT?
> 2) What does the cmd line client do differently than the gui?
>
> In other words, I'm not sure what exactly IBM is saying is wrong and
> what I should do to prevent it.
>
> Any clarification is appreciated!
>
> Rick
>
> On 7 Mar 2001, at 7:31, Æbelø Kaj-Flemming wrote:
>
> > Hi.
> > Some month ago I ran into the same problem. Called Tivoli support for
> help.
> > They told:
> > working as designed. You will have to use the command line interface to
> > restore.
> >
> > ---------CUT---------------
> > Hello,
> > This issue has already been discussed with development. There are 2
> > methods for enabling PIT restores. The first method is to keep enough
> > versions of directories to enable the PIT restore in the GUI. The
> > second is to use the command line for PIT restores. The decision to
> > enable PIT restores from the GUI is up to administration. Enabling
PIT
> > restores from the GUI can mean increased resource costs. Enabling PIT
> > restores from the GUI require extra versions of directories, these
> > extra versions require more disk space and more entries in the
database
> > to keep track of the entries. The DIRMC option is discussed earlier
> > in Chapter 11 Managing Client Data Using Policies. Development is
> > aware that GUI PIT restores can appear inconsistent. APAR IC25961 and
> > IC24733 were opened and closed SUG (suggestion). In both cases the
> > issue was acknowledged and stated to be working as designed. I hope
> > that this helps to clarify the situation.
> > Regards,
> > Level 2 Tucson
> >
> > ---------CUT---------------
> >
> > Kaj
> >
> >
> > -----Original Message-----
> > From: Steven Abrey [mailto:[EMAIL PROTECTED]]
> > Sent: 7. marts 2001 06:32
> > To: [EMAIL PROTECTED]
> > Subject: Point-In-Time Restore
> >
> >
> > Hi,
> > I have been trying to do a Point In Time Restore from the
Backup/Restore
> > Gui, but I only get a fraction of the files that should exist. I am
> > running 3.7.3 TSM server with the 3.1.07 Backup/Restore gui tool.
> > Sometimes, whole directory's don't exist and normally only the files
that
> > have been backed up within the last week or so, show up.
> >
> > Any Help will be most appreciated
> >
> > Steven Abrey
> > Network Support Analyst
> > Credit Union Australia
> > Phone : 07 - 3365 0231
> > Fax : 07 - 3365 0295
> > Email : [EMAIL PROTECTED]
--
Mit freundlichen Grüßen
Bernhard Unold
(See attached file: Bernhard.Unold.vcf)
=?iso-8859-1?Q?Bernhard.Unold.vcf?=
