good explained, thanks. Andy Raibeck schrieb: > > 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) -- 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
