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
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: araibeck AT tivoli DOT com
"The only dumb question is the one that goes unasked."
"Richard L. Rhodes" <rhodesr AT firstenergycorp DOT com>@VM.MARIST.EDU> on
03/07/2001 12:36:50 AM
Please respond to rhodesr AT firstenergycorp DOT com
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
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:SAbrey AT CUA.COM DOT AU]
> Sent: 7. marts 2001 06:32
> To: ADSM-L AT VM.MARIST DOT EDU
> 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 : sabrey AT cua.com DOT au
|
