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
begin:vcard n:Unold;Bernhard tel;work:+49 7071/29-80130 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] fn:Bernhard Unold end:vcard
